Answering questions in UI design
As usual when I’m stuck for a good topic to blog about, I revert back to my old pet peeve - the poor usability design in bug tracking software, namely the Zilla :-). I recently came across a great paper on information graphics and UI design by Bret Victor. He says
A well-designed information graphic can almost compel the viewer to ask and answer questions, make comparisons, and draw conclusions.
His analysis of user interfaces focuses on what questions a user might ask in a given context. For example when looking at books at Amazon, the immediate questions are something like whether the book actually fits my needs, and how good the book is. Neither of these questions is well answered by the amazon search interface and Bret shows how to improve Amazon’s interface by answering the questions the user is asking.
Let’s revisit Bugzilla for a moment. What questions does a user have when entering the system? I’ll give some examples of questions I ask every day:
- What are the bugs I am currently working on?
- What are the most recent bugs entered into the system?
- What milestone are we working on currently and how close are we to completion?
- What are other people working on/what has recently been completed?
I’m sure there are several others. Bugzilla offers a very complex search interface that will allow you to answer pretty much any of these queries. But it forces you to construct these queries painstakingly by hand and then save them as reports for running later. All of this lets you be exceptionally generic about what you do with bugzilla, and lets bugzilla gets away with providing very little domain-specific value. But the value provided by a bugtracking system is that it has to be more than a thin shell over a database. It has to answer the questions in the bugtracking domain, such as the ones outlined above.
I think Bugzilla’s opening screen should give me a birds eye view and answer 80% of my questions with one glance. JIRA does a passable job at this. Many other bugtrackers open up at least with a milestone view so you can see at a glance where you stand. Bugzilla prefers to pretend that all of these things are simply specific cases of something very generic: search.
From an implementation standpoint this may very well be true. But when we create complex systems we need to realize that the internal representation of the system is not necessarily the best external representation. For example I have almost never felt the need for my bugtracker to have a search any more complex than what I do on google (just type keywords, perhaps with some ANDs or ORs thrown in, at most). But I have always felt the need to get information delivered to me in a domain-specific manner. So please, stop showing me a web frontend to your database, and start answering domain specific questions.
I think the bigger issue here is that we as developers lean towards more elegant solutions. And elegant solutions tend to be generic simply because getting down to the details requires a lot of, well, detailed work. Implementing a generic search interface to a database is easy, and it doesn’t require domain specific knowledge. But to truly understand the needs of the user one must dive deep into the domain and figure out which questions really need to be answered. That’s when things get a little bit less elegant and less generic in the implementation, and the user experience really starts to shine.
No Comments Yet