Monday, November 8, 2010

Free UX advice for AH

Some time ago I wrote about bad UX at Albert Heijn (jul 2010). In short my complaint was that the check out system - on approach - very much emphasized the second step of the check out process. The first and mandatory step in the process is presented very inconspicuously.

Apparently designers at Albert Heijn are aware of this issue but unfortunately they solved it by showing a big red error message if the user accidentally scans his/her bonuskaart before putting the scanner back.

IMO this is the wrong solution for the design problem (being the user has to execute two actions in a specific order). It would be better to change the visual hierarchy of the 'welcome screen' to help users execute the actions in the right order.

Or even better, make it 2 screens; the first saying 'put your scanner back', the second 'scan your card'. I think this would very much reduce confusion and nearly eliminate the need for the big red error meesage.

But the best solution would be to design the system in such a way that the 2 actions don't have to be executed in a specific order. From a user-perspective there is no logical reason why he/she has to put the scanner back before scanning their bonuskaart!

Friday, October 15, 2010

Good UX at BOL

Okay now this is an example of good UX!

Yesterday I complained about the address removal interaction at by posting a tweet (with a link to my blogpost).

And today already I got a mention from @bol_com, in which they say they understand the problem and will see what they can do about it. Now that is some excellent user experience! They actively approach me and even are willing to try and solve the problem.

Big thumbs up for!

Thursday, October 14, 2010

Bad UX at BOL

Recently I ordered a book at (Information is beautiful, recommended!). While doing so I thought why don't I change my adress (I moved some time ago). Then I ran into an example of bad design: it was impossible to remove old address directly from my account.

I can see where this is coming from; obviously an account should have at least one address, but unfortunately BOL does not allow me to remove just any address (up until one address is left). 

Apparently the first entered address cannot be removed, which is very illogical because this will almost always be an old address. To make it worse; changing my old address into my new one is not allowed because the address already exists.

So to actually remove my old address I had to first remove my new address and then change the old address into the new one (and of course all the steps above to figure this out). Cumbersome interaction!

Tuesday, September 28, 2010

Results Usability Test: Right Click

Here's a quick update on the usability test on right click functionality in Hippo CMS 7.
The results show that roughly 2/3 of the participants would like to see right click functionality in the CMS.
Many participants mentioned that right clicking would be good, but should not be the only way to reach certain actions; right clicking should be additional / redundant interaction.

I would also like to point out that I suspect the participant group to be largely developers, thus real power users. I think actual CMS users will be less technical oriented and thus have a lower 'expectancy' for right clicking in a web interface.

So a premature conclusion from this test is that users tend to be ready for right clicking in a web interface, but that it is still to early to use it as sole interaction pattern.

Note: the test is still running. So if you are a Hippo CMS user, let us know what you think about right mouse clicking in a CMS interface? Please vote on

Friday, September 24, 2010

Usability test: Right Click Functionality

A call to Hippo CMS7 authors, editors and admins! Please join in on the next usability test. This one is about right click functionality. Use the following URL to start the test:

Please don't hesitate to join in and speak up. Your opinion is much appreciated!

Note on Usabilla (the tool used for these tests): Participating is anonymous; It is not possible for me to see who has participated. If you like to get in touch personally, please state your email in a note in the test.

Tuesday, September 21, 2010

Design by Fire Café - Design in Open Source

On Monday 20 sep I attended Design by Fire Café, which is an informal gathering for (interaction) designers. Each café features a short, inspiring presentation as food for discussion. Last Monday Bojhan Somers presented "Design in Open Source". Bojhan works at User Intelligence and is UX manager for Drupal.

To start of, Bojhan named some examples of successful open source projects such as Firefox, Ubuntu and Wordpress. Despite these projects having little dedicated designers compared to the amount of developers and users, they are able to create a successful UX. According to Bojhan it is the culture within these projects which is the major success factor in creating good UX.

Side note, some nice examples of gathering / dealing with UX issues from these projects are
Planet Firefox and Ubuntu 100 Paper Cuts.

Next Bojhan went into more detail on Drupal. From a major usability test in 2007 at the University of Minnesota it was clear Drupal needed UX improvement (l
ater on more usability research followed). Drupal's UX team started the UX project to get these UX improvements into version 7. Just to make it clear: Drupal's UX team is not a full time dedicated team, its members are people who have the Drupal design role besides their everyday job. Bojhan mentioned he spent about an hour a day in his UX role. So it was a real challenge for the UX team to change the culture in the community and thus get the UX improvements realized.

UX design challenge
Here's a summary of their 'lessons learned'.
  • Their was a shift of focus in the design; traditionally Drupal focused much on the technically oriented users (site admins). Now they are focusing more on the user group who uses Drupal extensively (authors and editors).
  • The UX team formulated core UX principles; these were 4 high level principles which helped to maintain the focus in discussions instead of getting lost in details.
  • The UX team introduced an iterative design process which contained "explore", "discuss" and "design" cycles. Designers were encouraged to be as visual as possible (use visuals and mockups) in the discussions to make problems more visible and better discussable. The team also noticed the issue queue was thé tool developers worked with. So they made sure the design discussions took place IN the issue queue.
  • Developers needed to learn; developers were used to start coding right away. They had to get used to this new process with its iterations and mock-ups before coding (you know, "Plan to throw one away").
  • Designers needed to learn too: designers were used to creating a near-perfect design before 'releasing' it. But this is impossible in the open source world. Designs need to be released early and should be more about showing the line of thought (thus educating other contributors).
  • Initially there were concerns that the 'design by committee' process would be slow and result in mediocre solutions. It turned out this was not the case; 'thought leaders' (mostly designers) arose and were the ones making design decisions.
Iterative design process

All in all I think it was a really nice presentation containing valuable lessons which we can learn form at Hippo.

Friday, August 27, 2010

Usability test: Tab Management

A call to Hippo CMS7 authors, editors and admins! Please join in on the next usability test. This one is about Tab management. Use the following URL to start the test:

Please don't hesitate to join in and speak up. Your opinion is much appreciated!

Note on Usabilla (the tool I'm using for these tests): Participating is anonymous; It is not possible for me to see who has participated. If you like to get in touch personally, please state your email in a note in the test.

Thursday, August 26, 2010

Results Hippo GetTogether Usability Sidetrack

Last friday (20 aug 2010) was Hippo GetTogether. Right after lunch, while the Cool vs. Hot tech-talks were being held in the Zuilenzaal, I ran the Usability sidetrack in the Teekenzaal. About 15 people attended and gave me really valuable feedback on Hippo CMS 7.

The sidetrack consisted of two parts. First I presented a brief introduction on usability. Most of the sidetrack however was a practical workshop. In this workshop participants gave me feedback on Hippo CMS 7. For those interested; you can find the entire presentation on (yes, I know, it contains a typo).

Check out the presentation if you'd like to know a bit more on usability. Here I like to go into more detail on the workshop and the results from it. For the workshop I had prepared three exercises; “Top 10 Improvements”, “Personas” and “Today's Design”, so that I had at least enough to fill the planned time (13:30 - 15:30). But in the end I used all the planned time and about an hour extra on the first exercise only; creating a decent most-wanted improvements list.

Top 8 Improvements

I used focus group methods to create the improvements list. First I asked all participants to write down their most-wanted improvements on post-its. This could be things like frustrating interaction, bad graphical design or missing features. Then we went through these improvements one-by-one; the 'owner' explained what he/she meant, and we put all the post-its on a flip-over functionally grouping them as we went along. This resulted in approximately 20 improvements. Next we prioritized the improvements. Everyone got to make two votes by placing stickers on the flip-over: one big sticker  for the most-wanted improvement (2 points) and one small sticker for the second-most-wanted improvement (1 point).

This resulted in the following top 8 improvements*:
  1. Rich text editor (Xinha): frustrating to work with, doesn't give users true text-editing functionality they expect from Office applications they normally use like MS Word.
  2. Performance: Bad performance influences the user experience, users get frustrated, start clicking more than needed, thus creating more errors.
  3. Document presentation: bad typography, unusable alternating color coding, 'technical' design.
  4. Template creation: current way of creating document type templates is too rigid / clunky.
  5. Workflow: communication possibilities between users in the workflow are missing / too little.
  6. Dashboard: perceived as useless because presented information is not relevant to users.
  7. Tab behavior: frustrating interaction.
  8. Drag & drop: missing functionality.

* The top listing is composed of voted improvements and improvements that are mentioned more than once. All other improvements are left out of the top listing.

Hackathon input

After creating the top listing we came to the conclusion there was too little time left to pick up one of the other exercises. We then had a short brainstorm on input for the hackathon, using the top listing as a reference. We decided improvements for the Dashboard nicely fitted the hackathon goals and could be feasible within a couple of hours.

From this brainstorm the following improvements for the Dashboard arose:
  • History improvements: make the history list more relevant, show publication, show take offline show requests and their comments, don't dhow login/logout actions, allow user to hide (some) actions, and group actions per user (within a certain time frame).
  • Chat functionality in CMS: allow logged in users to chat with each other, on dashboard, but eventually across entire CMS, one-on-one chats, but optionally also one-to-many.
  • ToDo improvements: Group per action.
  • Change order of history and todo; to do is more important, so should be on the left.
Structured feedback

Another very interesting point which became clear from the usability sidetrack was a clear need for more frequent and better structured ways for Hippo clients/users to provide input/feedback like in this sidetrack. I pointed out that we're running usability tests and that I would like as many participants as possible to join in. I also mentioned that I'm very much interested in additional feedback and like to enable structured ways of exchanging this. Participants responded enthusiastically to that.

What's next?

I've discussed results from the Usability sidetrack at Hippo internally and these are the steps we're going to take:
  • The upcoming release (7.5) is already fully planned and there are little resources available to pick up additional design and development. However we can fit Tab behavior improvement within this release.
  • For the next releases we have appointed key usability improvements: Dashboard,  Rich text editor, Performance and Document presentation.
  • Also we're going to create a 'UX channel'. We want to satisfy the need of sharing thoughts and ideas on user experience (and separate these from technical discussions). We have to give it some thought on how we are going to do this, but most likely we'll be opening up a UX forum.
Well, that’s it in a nutshell. I'll keep you updated and hope to see you at the next GetTogether!

Tuesday, August 17, 2010

Hippo GetTogether Usability Sidetrack

This Friday is Hippo GetTogether. Parallel to the Cool vs. Hot tech-talks I will be running the Usability sidetrack.

The Usability sidetrack is scheduled for form 13:30 until 15:30*. In this time I will give a glimpse into how we create the friendliest CMS around.

First there will be a brief introduction on usability; what is it, what is our vision on it and how do we apply it at Hippo.

Most of the sidetrack however will be a practical workshop. In this workshop you can give us your feedback, directly to me! The feedback will be used right there and then to collectively design and evaluate new and better solutions.

Your input is valuable here! Since the workshop is based on your feedback, please bring your issues, examples, comments, etc.

* There is room and time to continue an extra hour if desired.

Wednesday, August 4, 2010

Hippo GetTogether T-shirt poll

To all Hippo GetTogether attendees; now is your chance to determine the looks of us hippotizers. We want you to choose your favorite T-shirt for the Hippo GetTogether (majority rules).

Thursday, July 22, 2010

Bad UX at Albert Heijn

Since some time Albert Heijn has introduced self-scanning of groceries. When you go into a store you can use your "bonuskaart" (customer card) to grab a scanner from a rack. Although I needed some time to get used to scanning my groceries while putting them in my cart, I like the whole concept. However there's a design flaw in the check out process which annoys me very much.

When checking out the order of things is:

  1. First put the scanner back in the rack - the system won't do anything until the scanner is replaced
  2. Then scan your bonuskaart
  3. And then the rest of the check out procedure follows.

Now look at the picture below, which is what the screen of the check-out-system looks like when you arrive at it.

Why-o-why is the instruction for the PRIMARY and MANDATORY user action - putting the scanner back - so poorly visible???

I mean, first there is a big image and huge dark blue text line explaining the SECOND instruction. And then all the way at the bottom of the screen is a small light blue hard-to-read text line which is actually the most important instruction. In fact it is the ONLY instruction needed at that point. The rest could be displayed only when a scanner is placed in the rack.

To make things worse, there is an auditory instruction every 10 seconds or so saying to "scan your bonuskaart".

Come on Albert Heijn, you can do better than this.

Thursday, July 8, 2010

Usability test: Insert / Modify Image

A call to Hippo CMS7 authors, editors and admins! Please join in on the next usability test.

This test is about inserting and editing images while editing a document. Please use the following URL to start the test:

Please don't hesitate to join in and speak up. Your opinion is much appreciated!

Note on Usabilla (the tool I'm using for these tests): Participating is anonymous; It is not possible for me to see who has participated. If you like to get in touch personally, please state your email in a note in the test.

Thursday, June 17, 2010

Results usability test: Done vs. Save and Close

To all participants: thank you!

After just 2 days I've already got a really good amount of feedback.

As can be seen in the results above there is a very strong preference for the "Save & Close" button, as opposed to the "Done" button. We'll be changing this soon.

I also received some suggestions for a "Close without save" button, which would discard changes since last opening a document. We are looking into that.

Tuesday, June 15, 2010

Usability test: Done vs. Save and Close

For those of you who don't know me; I'm Rolf van der Steen, User Experience designer at Hippo. It is my responsibility to ensure our products are easy to use and understand, and users will have a excellent experience when using them.

To achieve this I would like to ask for your help. From now on I'll be regularly posting usability tests. These are quick tests focussing on (small) parts of the user interface. The tests will take no longer than a couple of minutes to complete.

I gladly like to invite you to participate in these tests. At this moment the tests will be focussing on Hippo CMS7. Also I'm primarily interested in the opinion of actual end users.

So, are you using Hippo CMS7 as an author, editor or admin? Please don't hesitate to join in and speak up. Your opinion is much appreciated!

And to start of right away; here's the first usability test already. It is a fairly simple test asking wether you prefer a 'Done' or 'Save & Close' button for closing your document. To start the test, please use the following URL:

Note on Usabilla (the tool I'm using for these tests): Participating is anonymous; It is not possible for me to see who has participated. If you like to get in touch personally, please state your email in a note in the test.

Thursday, May 27, 2010

Designing Complex Applications

From 16 to 18 may I was in London for the training 'Designing Complex Applications'. This training is part of the Usability Week by the Norman Nielsen group.

For those interested; more information on the training:

I would like to share my two most important insights from this training.

1. Do More User Centered Design

Hippo's development process is very much technology-oriented and requirements are mostly based on internal vision only. The level of UCD should be higher. There are two key elements in this:

  • Design research (usefulness). Truly getting to know and understand our users; what is the value of our software to them, what is important to them on a deep level addressing feelings and concerns.
  • Usability testing (usability): once useful functionality has been determined and designed, we should test whether it is usable (before developing it). Note: designed means 'draft design' here; testing with paper prototypes, mockups, partial clickables etc. There are some good methods to do 'guerilla' usability testing (=fast and low cost).
Get out of the building! Do design research to make design decisions data-driven. Without it, we're just guessing. This is all about aligning the users mental model and the designers (and hopefully developer's) conceptual model to create a consistent 'system image'.

This will result in better adoption, higher customer satisfaction, higher ROI, etc (although it is difficult to put some hard numbers on this).

My goals:

  • Set up methods for design research / usability testing which fit within the Agile process: set up user group, stakeholder interviews, domain investigation
  • Deliver design artifacts: personas, use cases, mental models, sketches, wireframes, prototypes
2. Make Design Artifacts Tangible

Design is not a 'black art'; transforming data from the design research into 'bits and clicks' can be broken down into distinct tools and steps that anyone can learn and use to improve. I want to make these design artifacts more tangible (to Hippo developers, management and user group) by having it centrally available on our Confluence-wiki. This will help:

  • Communicate designs and open up design discussions internally
  • Do remote usability testing
  • Align stakeholders and end-users concerns/goals, preventing people filling in the gaps with their own different assumptions.
  • Secure design knowledge
  • Shorten design process (by means of reusing patterns from a central library)
My goals:

  • Create a 'UI-place' on Confluence and start filling it in. Note that this will be an ongoing thing (so-called 'living specifications').
  • Try-out Balsamiq, which is a wireframing/prototyping tool which integrates with Confluence.
Furthermore the training provided a lot of patterns and examples - specifically for complex (web)applications used by domain experts - which are useful to me as source of inspiration / to be in the library.

Hope this gives you some idea of what I've been up to in London and like to hear your opinion on this.