When do you need to design a UI?
Via Ian Cartwright an interview with “Lean software gurus” Mary and Tom Poppendieck. All is going well until Mary says this:
When do you really need to design a user interface? Oftentimes it drives the whole design, but in fact you don’t really need it until you’re about to do your first alpha test. Before that you can be designing the business layer and you can actually put testing in below the user interface and you can be designing all of the other business logic; you can get that done with any kind of interface and in fact you ca drive testing with a automated interface, and then just before you go to alpha testing you decide what you want for your user interface. Then you take it off and at that point in time you figure it out. But up until that point in time you don’t need that.
This jars with my experience of building compelling customer experiences. There is a good reason why the user interface should drive the whole design because that is how the software is manifest. To the people whose lives are to be touched by the software, the users, the consumers, the interface is the software. To leave the UI till last presents a huge risk of building software that is functionally rich but has a UI modelled around the features; the underlying data and logic rather than how the user wants to work.
Starting with the UI is an excellent way of capturing and communicating requirements. And bakes in usability into the design. You want this feature and that feature? Great. But will they be coherent and usable to the user? Drawing out a UI on paper – paper prototyping- is far more efficient that making assumptions about requirements on a list. Afterall, isn’t this what the manufacturing industry that the Poppendiecks take thier inspiration from? Don’t the car manufacturers start with CAD and move onto clay models? Ergonomists have a hand in the design of car interiors, using anthropometrics to build in comfort and work out lines of sight. The engineers don’t build the engine and the bodywork and then make decisions about how the car will look. These things are designed from the start. And so should it be with software.
When do you really need to design a user interface? It should be the first thing that you do.
I agree 100%. great post. Many hours are wasted when the BL doesn’t expose the correct data that UI features end up needing. Design upfront cures a world of later pain
All is going well until Marc says this:
“When do you really need to design a user interface? It should be the first thing that you do.”
The true first thing to do is assess whether the users have a need for the interface in the first place. There’s no need to do the leg work of designing the tool if we realize later down the road that what the users really need is something different from what the stakeholders imagined. So, I’d say the first thing to do is go talk to and observe those users. Designing the interface can be the second thing. 😉
Josh,
Surely part of the first process you suggest includes the second you suggest? Mocking up the ui as part of the discussion with the stakeholder allows them to concrete their thoughts. Why should they be different processes?
I think you are using a different definition of ‘design’ to that in the interview. As a developer I think of design as ‘software design’. The objects, behaviour, relationships and the code that implements it. Not about the visual design. The UI can (and usually should) be designed without too much coupling to the software design. Otherwise when one of them needs to change it will forcibly ripple into the other one and that’s not generally a good thing.
Agree with Steve. Draw up the wireframe on the whiteboard as part of the reqs session and snap it with the digicam. The functionalist can go off and do their little thing with Rational and we get our IxD. Agile, agile!
Mary still has much to learn from her master:
((
Toyota itself keeps pushing ahead. Under its system, an engineer appointed to lead a new project has a huge budget and near absolute authority over the project. Toyota’s chief engineers consider it their responsibility to begin a design (or a redesign) by going out and seeing for themselves — the term within Toyota is genchi genbutsu — what customers want in a car or a truck and how any current versions come up short. This quest can sometimes seem Arthurian, with chief engineers leading lonely and gallant expeditions in an attempt to figure out how to beat the competition. Most extreme, perhaps, was the task Yuji Yokoya set for himself when he was asked to redesign the Sienna minivan. He decided he would drive the Sienna (and other minivans) in every American state, every Canadian province and most of Mexico. Yokoya at one point decided to visit a tiny and remote Canadian town, Rankin Inlet, in Nunavut, near the Arctic Circle. He flew there in a small plane, borrowed a minivan from a Rankin Inlet taxi driver and drove around for a few minutes (there were very few roads). The point of all this to and fro, Jeff Liker says, was to test different vans — on ice, in wind, on highways and city streets — and make Toyota’s superior. Curiously, even when his three-year, 53,000-mile journey was finished, Yokoya could not stop. One person at Toyota told me he bumped into him at a hotel in the middle of Death Valley, Calif., after the new Sienna came out in 2004. Apparently, Yokoya wanted to see how his redesigned van was handling in the desert.
When I spoke not long ago with the Tundra’s chief engineer, Yuichiro Obu, and its project manager, Mark Schrage, both of whom work in Ann Arbor, they characterized their research for the Tundra as quite unlike what was done for the Sienna. For starters, designing a full-size pickup truck for the American worker is more complex than designing a van for a soccer mom. The way a farmer uses a truck is different from the way a construction worker does; preferences in Texas (for two-wheel drive) differ from those in Montana (for four-wheel drive). Truck drivers have diverse needs in terms of horsepower and torque, since they carry different payloads on different terrain. They also have variable needs when it comes to cab size (seating between two and five people) and fuel economy (depending on the length of a commute). In August 2002, Obu and his team began visiting different regions of the U.S.; they went to logging camps, horse farms, factories and construction sites to meet with truck owners. By asking them face to face about their needs, Obu and Schrage sought to understand preferences for towing capacity and power; by silently observing them at work, they learned things about the ideal placement of the gear shifter, for instance, or that the door handle and radio knobs should be extra large, because pickup owners often wear work gloves all day. When the team discerned that the pickup has now evolved into a kind of mobile office for many contractors, the engineers sought to create a space for a laptop and hanging files next to the driver. Finally, they made archaeological visits to truck graveyards in Michigan, where they poked around the rusting hulks of pickups and saw what parts had lasted. With so many retired trucks in one place, they also gained a better sense of how trucks had evolved over the past 30 years — becoming larger, more varied, more luxurious — and where they might go next.
))
— http://www.nytimes.com/2007/02/18/magazine/18Toyota.t.html?pagewanted=4&ei=5088&en=27f821c931ad585b&ex=1329454800&partner=rssnyt&emc=rss