This article is a list of references, links about design process. My future proposals are based on work and reflexions made by specialist about UX design. (bold emphasis are mine)
Design process by Nielsen
The only generalizable advice is this: rather than rely on your own best guesses , base your decisions on user research :
- Conduct field studies and task analysis before deciding what your app should do.
- Paper prototype your initial ideas before doing any detailed design — and definitely before wasting resources implementing something you’d have to change as soon as you get user feedback.
- Design iteratively , conducting many rounds of quick user testing as you refine your features.
[...] My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.
(Whatever you do, at least promise me this: Don’t just implement feature requests from « user representatives » or « business analysts. » The most common way to get usability wrong is to listen to what users say rather than actually watching what they do . Requirement specifications are always wrong . You must prototype the requirements quickly and show users something concrete to find out what they really need.)
It has long been recognized that user interfaces should be designed iteratively in almost all cases because it is virtually impossible to design a user interface that has no usability problems from the start. Even the best usability experts cannot design perfect user interfaces in a single attempt, so a usability engineering lifecycle should be built around the concept of iteration.
Iterative development of user interfaces involves steady refinement of the design based on user testing and other evaluation methods. Typically, one would complete a design and note the problems several test users have using it. These problems would then be fixed in a new iteration which should again be tested to ensure that the « fixes » did indeed solve the problems and to find any new usability problems introduced by the changed design.
And to stay humble as designer :
« The Joel Test: 12 Steps to Better Code »
specially for design :
#7 : do you have a spec ? (design must be complete before coding)
#9 : best tools (for design also)
#10 : do you have testers ?
#12 : hallway testing
A serie of article about UX, design and users :
Controlling Your Environment Makes You Happy
Figuring Out What They Expected
Affordances and Metaphors
Consistency and Other Hobgoblins
« designing for people who have better things to do »
- Users don’t read stuff
- Users can’t use the mouse
- Users can’t remember anything
« the process of designing a product »
- Invent some users
- Figure out the important activities
- Figure out the user model — how the user will expect to accomplish those activities
- Sketch out the first draft of the design
- Iterate over your design again and again, making it easier and easier until it’s well within the capabilities of your imaginary users
- Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn’t matching the user model.
« Top Five (Wrong) Reasons You Don’t Have Testers »
and specially the « 3. My customers will test the software for me. »
(and the direct link to the video : http://www.youtube.com/watch?v=Ar8lobad1aE)
Canonical has a strong design team. Their last work had an incredible impact : Ubuntu Phone OS. In their blog, they explain how they work :
And Canonical created a special website for the community to participate in the design of apps for UbuntuPhone :
It is very well organized :
- predefined rules and workflow to create proposals
- each app has
- User stories
- Functional requirements
- List of views that need a design
- there is a dedicated balsamiq website :
- design proposals have to be wireframe
- common tool for all proposals
- but their Interface Guidelines are still a work in progress
And in a very recent video hangout (http://www.youtube.com/watch?v=JLAVx91Uhmo), they explain that their current proposals are in a pseudo-wireframe : it’s not the final UI (some colors and other visual details will change).
Design process at Google
And a video about one member of the design team :
TDF should look at Apache Open Office as a very strong competitor : if LibreOffice doesn’t prove that his UI evolves correctly, some distros may switch back.
Example : « Fedora To Look At Reviving Apache OpenOffice » (http://www.phoronix.com/scan.php?page=news_item&px=MTI4ODI)
The wiki page of AOO design is clear, structured and very professional (http://wiki.openoffice.org/wiki/Apache_OpenOffice_User_Experience).
There is everything we expect from a design team of such a big project :
- precise list of datas about users/AOO
- precise list of all tasks/activities needed to cover design process
- evaluation of design proposals
Even if they seem to have a slower speed, the strong organization of design process will be visible in mid and long term : they’ll provide regular, stable, tested and good UI evolutions. And I guess those evolutions will not need modifications after their public release.
An example of simple usability test, but with tremendous feed-back : http://openthedesign.posterous.com/usability-test-gnome-character-map
The video about MS Ribbon history :
What is very interesting is the process used to do that work :
- UI goals : « the mountain where we want to go »
- Design process :
- design tenets : « the chosen path to go to the mountain »