|This blogger has moved!|
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers.
Come join us if you are into UX, design or photography at some level.
Visit Rift Labs
At the Design for Mobile conference last week Mike Lundy, Design Lead for the Sprint Instinct, talked about the design and development process for the phone. He had some pretty interesting things to say.
(This is my impressions and takeaway from the talk, any errors are mine, etc, etc.)
The Instinct has become the most successful device launch in Sprint history. The Instinct represented a change in the design relationship between a carrier, an OEM and application providers. More importantly, it represented a fundamental change in development tactics and design authority within the carrier.
In addition to selling well, the Instinct also got some pretty good reviews. Mike Lundy and his cohorts must have done something right.
The degree to which an operator customizes a phone before they sell it varies a great deal. Some operators do nothing, they sell phones just as they come from the manufacturer. Some customise the look with colours and icons and their own web start page. And some, like Sprint, put a lot of extra software on the phone.
The Old Approach (meddling)
Sprint has a multivendor approach where many different companies (OEM’s) deliver different parts of the phone software. In addition to the phone manufacturers own OS, there may be a dozen more applications, all with slightly different different buttons, menus, user experience.
For each feature, like music, email, navigation etc. operators have their own product managers with different budgets and objectives. This often leads to a very bureaucratic development process. Typically, product managers fight to give their service highest priority, without worrying too much how much this may affect the overall user experience of the device. They are after all measured on how well their service are doing, not everybody else's. In short: there are way too many cooks in the kitchen.
The UE team may have the task of creating a unified experience, but often not the means since the UE team does not own the overall design. Sprint used to do feature level requirements, and only bug level enforcement were possible. This means handing off a word document or a wireframe to the developers, and all you can do if you don’t like the result is file a bug report. More, when design decisions were made, there were no engineers and no visual designers in the room.
The new approach adopted for the Instinct
A small dedicated team of only 12 people (The Tiger Team). Visual lead, Design lead, some engineers, some product managers and one exec who informed externally. The team had clearly defined roles, clearly defined goals and executive backing.
Development was done in isolation from the rest of the organization. The rest of Sprint didn't know about the project, if I understood Mike correctly. The team moved out to a different building with their own security (I guess that was to keep product managers out). Samsung sent 20 or 30 developers to the Sprint site to work on the phone.
Very fast turn around. 24 hours to come up with a design suggestion to any given problem, 48 hours for the design lead to evaluate it.
With the Instinct, the design team were owners of the overall design.
Why did they do it?
Competitive pressure from the company that shall remain unnamed, the touch trend and experimentation with a new design approach.
The design was centred on habitual use, not on ease of discovery or ease of learning. "When you adopt it, it is so efficient to use that you don't want to change".
There was very little user testing or input, it was a very heuristic design process.
There were only 9 months from project start to shipment and 36 apps to redesign. 13 vendors contributed, all had apps that had to be adapted to the new UI.
The hardware/software platform was chosen before the team started their work. The hardest thing about the entire project was that the hardware was underpowered for the task, it was never designed to do what they asked it to do. To make matter worse, the various applications to be included ran 4 different systems (Native RexOS, Java, BREW and TAT.) The effect can be seen. The address book runs native code and the list scrolls very smoothly. The music player is written in Java (that runs on top of BREW in this implementation, making it very slow) and the lists doesn’t really scroll, the text jumps to simulating scrolling.
Tech enforced consistency
All existing Samsung UI code was thrown out. The design team created a a common set of UI widgets that all vendors had to adapt (framework widgets). This drove design consistency. When the vendors complained about UI shortcomings, this brought attention to exceptions.
Dedicated Visual Design support
No more “paint by numbers” for the visual designers. Visuals was included in the wireframes sent to engineers so they had pixel perfect designs in hand. Visuals were also used to improve and clarify interactions including the physics of the interactions, acceleration and deceleration formulas for gestures.
Screen real estate is at a premium on a touch screen device because everything has to be visible on the screen.
The Swiss army knife approach was rejected. All features were removed by default and every feature was interviewed again for inclusion.
For example; 70% of revenue for one music service came from a banner ad (presumably because the service has hard to use and people didn't buy music). The new design did not include the banner ad, and the music product manager was upset. 70% sounds like a lot, but on closer examination it turned out that it was 70% of very little. It would be better to improve the service so people actually bought music. The ad was not included in the new design.
The phone was going to be sold on unlimited data plans only. That meant they could remove a lot of warnings and alerts. It also reduced user anxiety over billing and reduced purchase anxiety (there is no choices to be made by the buyer. It's one package only.)
Leanings from the process
- Enforce consistency through code, not through wireframes
- Determine how to make money. Subjugate all other considerations to design.
- Use visual designers up front
- Have a clear goal
- Limit complexity
- Make the product managers work for their salary. Why should the feature they want go into the design? If they want something in the design, make them make a case for it, dig up numbers, state their case.
Here is an interview of Mike Lundy where he talks more about designing the Instinct.