Thoughts about Libre Office design process (part 2 : other projects)

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

http://www.nngroup.com/articles/top-10-application-design-mistakes/

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.)

http://www.nngroup.com/articles/iterative-design/

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.

http://www.nngroup.com/articles/paper-prototyping/

http://www.nngroup.com/articles/usability-101-introduction-to-usability/

http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

And to stay humble as designer :
http://www.nngroup.com/articles/the-myth-of-the-genius-designer/

http://www.nngroup.com/reports/paper-prototyping-training-video/

http://www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users/

http://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/

Joel Spolsky

« The Joel Test: 12 Steps to Better Code »

http://www.joelonsoftware.com/articles/fog0000000043.html
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
http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

Figuring Out What They Expected
http://www.joelonsoftware.com/uibook/chapters/fog0000000058.html

Choices
http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html

Affordances and Metaphors
http://www.joelonsoftware.com/uibook/chapters/fog0000000060.html

Consistency and Other Hobgoblins
http://www.joelonsoftware.com/uibook/chapters/fog0000000061.html

« designing for people who have better things to do »
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html
http://www.joelonsoftware.com/uibook/chapters/fog0000000064.html

  • Users don’t read stuff
  • Users can’t use the mouse
  • Users can’t remember anything

« the process of designing a product »
http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html

  • 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 »
http://www.joelonsoftware.com/articles/fog0000000067.html
and specially the « 3. My customers will test the software for me. »

 

Openerp v7

They wanted to have metrics about usability enhancements between v6.1 and v7. They created a javascript tool to record some simple values : nb. of clicks, the distance between clicks, the pixels to move and the keystrokes involved.
http://www.serpentcs.com/serpentcs-openerp-7-0-vs-6-1-usability-metrics
(and the direct link to the video : http://www.youtube.com/watch?v=Ar8lobad1aE)

Ubuntu

Canonical has a strong design team. Their last work had an incredible impact : Ubuntu Phone OS. In their blog, they explain how they work :
http://design.canonical.com/2013/01/behind-the-scenes-notes/

And Canonical created a special website for the community to participate in the design of apps for UbuntuPhone :

https://wiki.ubuntu.com/UbuntuPhone/CoreApps/

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

An excellent article about the recent design changes at Google :

http://www.theverge.com/2013/1/24/3904134/google-redesign-how-larry-page-engineered-beautiful-revolution

And a video about one member of the design team :
http://vimeo.com/29965463

Apache OpenOffice

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
  • research
  • design
  • 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.

Gnome

An example of simple usability test, but with tremendous feed-back : http://openthedesign.posterous.com/usability-test-gnome-character-map

 

Microsoft Office

The video about MS Ribbon history :
http://www.youtube.com/watch?v=Tl9kD693ie4

What is very interesting is the process used to do that work :

  • UI goals : « the mountain where we want to go »
  • Design process :

- research
- design tenets : « the chosen path to go to the mountain »
- prototypes
- evaluation

2 réflexions au sujet de « Thoughts about Libre Office design process (part 2 : other projects) »

  1. David Tardon

    > 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)

    So some random guy proposed a feature for Fedora about packaging Apache OpenOffice and media did a big splash about it. And what? The progress of the feature is still 0 %. Until there is, at least, a review request in bugzilla, there is nothing to talk about.

    (As a sidenote, I saw some other guy announcing a spec file for Fedora on the AOO devel list, which turned out to be the current libreoffice spec with a few trivial changes. If he really means to start with that, I wish him luck. He will need it.)

    1. admin Auteur de l’article

      Thanks for the info.
      It’s clear that AOO progresses slowly and that current distros use LibreOffice, but my purpose was to say that it may change in the future. Let’s wait the 4.0 release, with the LS Sidebar integrated : some friends already told me that they’ll test it only because of that change and maybe switch back. And don’t forget that OpenOffice is still more used that LibreOffice, specially on Windows.

Les commentaires sont fermés.