I’ve just read the most frustrating link-baiting blog post by Penelope Trunk on her theory that startups are better as single-gender entities as women are too much of a distraction (I’m assuming to the men).
Based on her personal experience, she makes a blanket statement about all startups and all women.
I have done three startups and each time it has been with a male co-founder. And each time, the fact that I am female has been a distraction to us. It has been a source of friction. When I was young, people thought my co-founder and I were a couple. (This is not surprising. The majority of male-female co-founder situations for a funded startup have a sex component.)
Guess what – I’ve done four startups now, all of them with men, and each time the fact that I am female has had nothing to do with anything. It has not been a distraction or a source of friction, or even a topic worthy of noticing by any of us. These places have all hired me for my brain, not my gender. We haven’t all broken down into chaos because having a woman around has been distracting to everyone (honestly, has she been working in a mine or something?).
I’m not too sure exactly what part of her gender she thinks has been a source of friction in her workplaces. Does she think that she was distracting the men with simmering sexual tension or does she think men can’t work with a pair of boobs in the same room?
I’m not sure where she lives, but the last time I checked it was 2011 and women and men are able to work together without “a sex component” entering the equation.
pinch/zoom is half women, which I’m really proud of – it’s unfortunately still too unusual in a male-dominated tech industry. And the fact that we’re half women has brought a wealth of experience, knowledge and perspective to the team. We have not had a single gender-related issue in the company since our inception, and I will be really surprised if gender ever becomes an issue in the future. We have all been hired for our brains, personality and experience, both men and women. Gender has about as much to do with it as preference for chocolate bars.
You know what? Most women cry at work. And most guys throw a fit.
I don’t know what kind of startups Penelope has been working at but these blanket statements are just so ridiculous it makes me want to scream (or apparently cry). Most women do not cry at work. And most guys don’t throw a fit. It sounds like she’s been working with a bunch of immature children rather than with professional adults, which is probably the issue which she is conflating with gender.
diversity is great for larger companies but a hinderance to smaller companies because startups need focus.
And guess what? I replaced myself with a male CEO. He’s a great guy, and whenever the team needs a contrary point of view, they schedule a conference call with me.
Sigh. I started a response to both of these and realized I’m responding to a troll. I will say this – diversity is vital because we all bring differing experiences, values and approaches to the same project. Diversity is not just gender, it’s our cultural differences, gender, age, experience levels, ethnic backgrounds, interests and everything else that makes us human. Startups need more middle-class white men about as much as Seattle needs more rain. The women we’ve hired (myself included) are not just here for our “contrary views”, we’re here because of the value we bring to pinch/zoom. To think we’re only here for our “contrary views” is selling everybody short – both the women and the men.
Discuss on Hacker News
women in tech women leadership gender women in mobile
We think that within three years, we will have more than half of our digital access through mobile devices. Right now, 23% of our page views are coming from mobile.
We’ve had a lot of discussions internally about the best prototyping tools to use for usability testing as well as client reviews on information architecture and visual and interaction design.
We’ve just recently launched the BBC Global iPlayer for iPad project, and wanted to be open about some of the various prototyping tools we used to get user feedback and stakeholder reviews.
For this project we experimented with:
- Keynote prototypes
- Cocoa prototypes
- iPad photo gallery
Keynote Prototype
We originally thought Keynote on iPad would be the best tool for running a prototype through usability testing. It has built-in transitions to easily jump from one “screen” to another so we could make buttons and links work, with fairly seamless animations.
We were testing both wireframes and more high fidelity visual designs within Keynote.
We found this to be fairly clunky during testing though. Unfortunately Keynote for iPad strips out any interactions it can’t play, so we lost more than half the functionality that was created in Keynote for Mac and then ported over to Keynote for iPad.
We ran the presentation in Keynote but found that Keynote would jump from play mode back into edit mode when users (and us) were least expecting it to, which led to a lot of unnecessary confusion for the users.
We also used Keynote to create some early wireframes, which has been a fairly contentious issue amongst the design team, with an even split of those for and against. It is a really fast way of wireframing, and the built-in transitions are a blessing to quickly show clients how each screen and tap leads to the next. It’s also a steep learning curve for those used to working with Omnigraffle or other wireframing tools – it means creating a whole new set of tools so adding a lot more time to each project.
Keynote seems to be a great tool for getting clients across interaction design, however I’d be reluctant to use a Keynote prototype in usability testing after some of the issues we saw in user flows.
Cocoa Prototype
We had our developer build out a cocoa prototype for testing some of the animation and navigation within the app.
We were testing a navigation structure that had an unfurling ribbon with categories, then a tap to release further subcategories, with further filtering under another menu. Sound confusing? That’s why we wanted to test if users understood the navigation structure, and would find it a useful way of navigation through dense content, or if they preferred a more curated approach.
The cocoa prototype had simple wireframes, with the navigation built out for user to tap, pull, collapse and move.
We found this was a great tool for usability testing. Users immediately understood that they were looking at the early stages of an app, and were comfortable exploring tapping, swiping and moving through the prototype.
If you have the development resources, creating a cocoa prototype is definitely a worthwhile exercise. One of the downsides of a cocoa prototype is the time it takes to make changes.
On the Keynote prototype we could make quick labeling and navigation changes between user sessions, whereas the cocoa prototype was more a learning tool – we couldn’t make quick iterative changes based on user feedback.
Photo Gallery
This was the simplest tool we used, and one of the most successful. We started using the photo gallery when we realised the limitations of our Keynote prototype.
We created different albums in the photo gallery within the iPad app, one album for each user journey. We then put a screenshot of each screen within the journey in order in the album, and had the facilitator pull up each album as he asked each task, for example “Show me what you’d to do add a program to your queue”.
The user quickly understood they needed to swipe across to get to the next screen, and most didn’t realise they were looking at the photo gallery – they believed they were navigating a real application.
The limitations of using the photo gallery was the linear nature we had to make each journey – if the user wanted to deviate from the flow that we’d created, it was a little bit clumsy to jump across to different screens.
The photo gallery is a great tool for testing content, labels and weight of content, but for testing flow a cocoa prototype is a much better tool.
HTML/CSS/Javascript
We’ve also built working prototypes in HTML, CSS and JavaScript, although we didn’t do this for the BBC project. We’ll post a follow-up on some of the other approaches we’ve taken to create mobile prototypes over the next few weeks.
Summary
The short answer is there is no “perfect” prototyping tool when it comes to mobile prototypes, it really depends on what you’re trying to test and what resources you have available.
We were most surprised how how limited we found Keynote when it came to wireframing and testing with users. Lots of designers really like Keynote for rapid prototyping but it really just didn’t suit our needs.
Cocoa is brilliant if you have access to an iOS developer. It’s a good way of getting feedback on interactions and flow, although the down side is you’ll need to be really reliant on your developer for changes – most UX, IA’s or designers can’t really make quick changes based on user feedback, it’s going to take much more planning in between tests to iterate.
Photo Gallery is good for testing design (prominence of various content, design) but it’s not a good tool to test user flow or interactions.
We’ll post more on some of the other mobile prototypes we’ve created in the coming weeks.
“From the second we turned it on, the user experience was astonishingly bad. Want to activate your phone? Take the battery out, write down a series of minuscule numbers that you find on the phone and on the SIM card, then enter them into Verizon’s barely-functional site. Once you’ve got it hooked up, navigate the opaque first time setup, if it doesn’t crash while you’re entering your information (it did – twice). Once you’re done with the setup, enjoy the apps that Verizon and Samsung think you should use: a terrible golf game, a Samsung branded Twitter client, Verizon’s half-baked navigation app.”
In a commodity market, first impressions are everything.
Gogo says “iPhones make up nearly two-thirds of the mobile devices using its inflight Wi-Fi service. Android devices make up just 12 percent, trailing even the iPod touch, which accounts for 20 percent of handheld connections.”