Our UI Development Process

July 21, 2009 by Shannon Wells

Since I’ve worked in UI design/development at two very different companies, I thought I’d share my observations.    The other company where I worked is Apple, on  the iPod, and I will tell you without reservation that the UI development process here is superior to what I experienced on the iPod team.

The iPod had and has some of the world’s best industrial designers, but during my tenure, our actual user interface development was subject to approval by one person, who need not be named.   All user interface changes had to be routed through this person, and much time and effort was spent preparing for and managing these interactions, in ways that were often inefficient and always very stressful.    Other than Mister Veto Power, there were really only two or three people who (from where I stood) had any real say in the iPod UI.  Everyone else had opinions, but it was far from being designed with group input.   One can’t argue too much with the end result, but, much like sausage, you shouldn’t ask what went into it.   Then there is the question of what happens when the MVP (pun intended) no longer illuminates with his perfect vision.  It’s neither a typical nor ideal design process.


Contrast this with what we have here at Mu.  We flailed a bit with our interface design process in my first year or two that I was here.   What was not working for us was what I will call a feedback prototyping process.   People would prototype UI in code, show it to a few people, make a few changes, and keep going.  There wasn’t always communication among all the UI level engineers about things like consistency of behavior,  or look and feel.   We often bit off more than we could chew (sound familiar?), because it wasn’t clear soon enough what could be accomplished, in part because we didn’t realize we didn’t have a clear enough idea of what needed to be done and how much effort that would take. We have in the last year gradually instituted a version of Agile development with sprints and Scrum meetings.    We first come up with the list of every possible two-day or shorter task we can think up, that could potentially be required to produce the new feature set.   These tasks include UI mockups.   Then, while others work on back end layers of the code, one or more people with laptops go into a cave for a few days and emerge with a bunch of OmniGraffle slides.


OmniGraffle is now our tool of choice for designing UI.  It has saved us enough engineer-hours that the cost of the Pro license paid for itself within the first few months.  It presents well and is easy to modify during a discussion to quickly show what a proposed change might look like.  Because it’s clearly  not actual code, nobody is tempted to think “It’s almost done!  Ship it!â€?   Because it can be made to look and behave more like a real UI during a presentation, many bad ideas are discarded right away.   Sometimes, as in today’s meeting, it’s discovered that our original idea would present the new feature in too complex of a way.  It needed some newbie user features, which four of us sat and discussed the best way to implement.    This was, I thought, simply the latest of a long series of very productive UI meetings, and that is what prompted this article.


At the meeting were mainly a UI designer, our engineering manager, another engineer with more experience under the hood of our product, our Test Automation manager (who has a dotted line into Sales Engineering), our Tech Pubs manager, and myself.   Each of us has differing perspectives on UI, and a couple of us have different aesthetic sensibilities as well.   In my opinion this makes for the best team, since everyone can catch design flaws the others might miss, and come up with options others would not think of.    Bonus: we all genuinely care about the product and don’t have our sense of self-esteem tied up in whether our ideas are accepted or rejected.   The value of this alone cannot be underestimated, because it allows us to focus on the important things:


The last point is something that did not occur to me until recently.  I implemented a feature that turned out to be an excellent way to communicate what our product does to a potential customer.   I do not think anyone will be implementing features solely for use in dog and pony shows, but I do think it’s important to consider the impression you will be making on a potential customer.  A User Interface needs to explain itself somewhat, otherwise your potential clients won’t understand why they need it, no matter if you have the best sales team on the planet (I strongly suspect that we do).

We understand the importance of having buy-in from all areas of the company, including  Product Management, Sales Engineering and Marketing.   We typically have a couple of rounds of mockup draft reviews, and then have a larger, sign-off  meeting which includes people from these departments.   In more than one case, some missing but crucial feature requirements were caught in time to make sure they made it into the product.   

We have also begun sending engineers to customer sites.   We have found this absolutely invaluable for seeing for ourselves how our customers use our product, listening to their issues.  Occasionally we’ll be taken to task, but one should look at it all as good input.  If a customer is frustrated, you want to know.    I myself had a chance to clear up some issues a customer was having, even as he was (justifiably) raking the product over the coals for other things!   However, when you take that feedback and put it to good use, hearing how much people appreciate that you take their input seriously, and that they are pleased with the results, is very rewarding.

Categories: UI
1,276 Comments
Bookmark and Share