Friday, February 15, 2013

Some thoughts on design and user experience

What makes good UI design? This question has probably been asked and answered a thousand times already.

What makes good user experience?
Same as above...

As a user I have some high level requirements that are valid for mainly all user interfaces I'm exposed to. They only slightly differ for interfaces I know and use regularly and those that I use for the first time. The most important one in both cases is:

I do not want to have to bother about the user interface! I want to be able to start right off. No waste of time. What I want is intuitive usability.

For new devices or new software this mainly means that I don't need to read the documentation to perform the basic tasks it has been designed for. For things I use regularly this extends to finding more advanced options following my logic. This logic I typically built up by experience with similar tools: I expect to find the  Print option somewhere in the File menu no matter what software I use. This could be called "common agreement" or "standard" even if is not explicitly formulated anywhere. Or my logic is built by letting the task guide me. This is hard to describe. Maybe the best way is to put it this way: When it works it feels natural and effortless.

This sounds straight forward and reasonably easy. There are university courses and blogs on the topic. There is research, teaching and the relevant techniques are applied in industry on a daily basis. And yet the question remains: Why is it still going wrong so often?

I don't know for sure, but I have spent a lot of time thinking about why it goes wrong. I was never very deep into research on user interfaces. So all my thoughts here have to be viewed as just that: my thoughts - not backed up by elaborate tests, questionnaires or any other scientific method.

I come to believe that one of the problems in UI design often is a difference in how designers and users approach the topic. As I said above in my role as a user I want to get things done. But when I switch to be a designer or even engineer, for some reason I loose the focus on the task the user is interested in. In the engineers  role, I want to make all the functionality accessible and I tend to overdo it in terms of different functions put in on software or tool. I want to make things reusable, modular, sort and group things, but often I'm not guided by the task, but by technical similarities - engineering stuff you could say. In my experience sometimes the root cause for this is that the engineer or developer is simply not familiar enough with the users task to deliver good design. And sometimes the engineers just get carried away, designing a Swiss Army Knife - I call this over-engineering. In short you could say,  when it goes wrong the situation is like this:
  • User experience is top-down: You have a task -> select an appliance -> find suitable function -> use the function -> task completed!
  • Design is bottom-up: You have a bunch of functions -> you want to put as many as possible in the tool -> you need to present all of them to the user 
 No reference to the user's task in the design at all. OK, that's exaggerated ;-)
As most of the time, there is no pure black-and-white.

One very strange thing is the following observation: Users - me and you - tend to know very quickly when a tool has a bad UI design. (I'm from the Ubicomp area, so don't wonder why I use terms like "tool" or "appliance" a lot. In most cases you can replace it simply with "software". If you find this lame, read "The Design of Everyday Things" by Don Norman.) But we can also very quickly identify good design. Then, why is it so hard to design a very good interface and user experience?
  1. Design does not equal implementation. Still the design is often not addressed explicitly, but done as part of the implementation.
  2. The use is always goal driven. You want to "get something done". That's why you spent time using an appliance.  Design is often pragmatic - driven by other priorities like cost, technology constrains, time, resources in general.
  3. Sometimes systems become so complex that the goals or tasks are not obvious to the implementer but only to an experienced user. In this case you can end up with very funny results if the design is done implicitly by the implementer.....
  4. The users do not always know what is best for them. This might sound strange or even arrogant. 
This last point is very interesting as it seems to contradict partly what I said before, but in fact it does not. When you ask a user what an interface should look like, you take her out of the "task" context. She will think engineer like without the technical background knowledge of the actual engineer. You will end up with hundreds of requirements covering special cases that occur once in a lifetime. The user tends to ask for Swiss Army Knife - just in case.

So do I have a ultimate solution? No. But I can draw my personal conclusion:
  1. UI Design should be a separate development task that is explicitly addressed. (Also in terms of time and budget)
  2. The user should be integrated in the design process and contribute the expert knowledge on the task at hand. Not more!
  3. The actual design should follow the appliance idea and take into account ergonomics, cognition and efficiency.