Designing your next UI change
Based on a talk given by Matthew Paul Thomas at a Launchpad developer meeting, 30 June 2011.
Here are some ideas on how to make visible Launchpad changes efficiently. By efficiently I mean changing the interface in a way that:
- is quick for people to learn
- is quick for people to use
- minimizes the probability that you, or someone else, will have to change the same code again in a few weeks or months.
Define the problem
Often, the problem you want to solve — or the new feature you want to implement — seems obvious. But sometimes, a bug gets reported in a way that assumes a particular solution. One common sign of this is that the summary or description uses the word “should”.
Most problems have multiple possible solutions. And the person who discovered or reported the problem won’t necessarily think of the best possible solution.
This isn’t just because that bug reporter usually isn't a designer. And it isn’t just because they are reporting a bug in the heat of the moment without thinking in detail about it. It's also because they probably aren’t considering other problems or constraints on the same part of the interface. But you should.
So whenever you see the word “should”, or any other way that a bug report assumes a particular solution, I suggest first rewriting the bug report to concentrate on the actual problem.
Second, I suggest searching open bug reports to find other problems in the same area of the interface, and to find the same problem in other areas of the interface.
Looking for related bugs like this has several benefits:
- Even if those other problems are only Medium or Low importance, you may be able to solve at least some of those other problems at the same time, with much less effort than if you left it for later.
- Understanding the other problems can help you design a solution that works for all of them, even if you don't implement all of it right now.
- You might realize that the best result overall is to solve a particular problem, or solve it in a particular way, that makes it impossible to solve another problem. So you'll have to decide which one to fix, and Won’t-Fix the other one, but the reporter will still appreciate it more because you can explain to them exactly why it's being Won’t-Fix-ed.
Design multiple solutions
Any design solution you might think of is like landing, blindfolded, somewhere on a mountain range. User testing and polishing might lead you to the top of the nearest peak. But that might be a low peak.
So, design multiple possible solutions to the problem you’re solving. Thinking of multiple solutions makes it much more likely that you’ll find the highest peak, the best possible design.
One way to do this is for each person in a group to sketch a couple of designs, before the group meets to discuss everyone’s designs. Research is divided on this, but there is some evidence that brainstorming individually produces more ideas than brainstorming as a group.
To help me think of multiple solutions to a design problem, I follow four steps:
Try removing something.
Try merging things.
Try rewording something.
If all else fails, try adding something.
Choose a solution
User testing is one way of choosing from the solutions you’ve come up with. But there are two other things to consider.
First, you need to consider edge cases that might not come up in any testing. What happens if someone loses their Internet connection after the page is loaded? If the design deals with a collection of items, what happens when there are 500 items? What happens when there are zero items? What happens if the thing you’re dealing with is private? What happens if someone does this thing by mistake? What happens if someone logs out in a different page, then tries to do something in this page?
Second, there are many heuristics you can use to decide between solutions, regardless of whether you have enough time for user testing. For example:
Fewer pages/overlays is better
- … except for something dangerous.
Fewer words is better
- … except if it’s something complicated, or seldom encountered, that needs explaining.
Fewer controls is better
- … except if you’re hiding complex behavior in a radio menu, or in a checkbox’s unchecked state — try radio buttons instead.
Less repetition is better
- … except if efficiency requires showing the same control for multiple items.
Direct manipulation is better
- … except where that prevents efficient batch changes.
Elements lined up is better.
Consider a team listing. How to apply these heuristics here?
- Fewer words is better: Do we really need to say the members are “results”?
- Fewer words is better: This is the entire list, so the batch navigation is clutter.
- Fewer pages/overlays is better, and direct manipulation is better: Instead of an overlay for editing the details, let people click on the details directly in the table to change them.
- Fewer controls is better: Maybe expiry is uncommon enough that the table is simpler on average without the “Expires” column.
- Less repetition is better: “Approved” is the typical state, so maybe spell out only the other states.
Second example: source package information.
- Elements lined up is better: The two subheadings should be lined up with each other.
- Elements lined up is better: Three of the five basic name-value pairs are “just the package defaults”. They could be presented in a single column.
- Fewer words is better: With those three elements together, the footnote could be much shorter and act as a heading for them.
- Elements lined up is better: The red cross icons are scattered messily (and it’s not obvious what they do here, anyway).
- Fewer controls is better: “Show upstream links” doesn’t need an icon.
Third example: the list of suggestions when reporting a bug.
- Fewer words is better: A bug report that was marked Invalid in 2009 probably isn’t the bug I’m reporting.
- Fewer words is better: Seeing the bug number doesn’t help me tell whether this report is about the bug I’m reporting. It could be hidden in the expanded section.
- Less repetition is better: Repeating “view this bug” is monotonous (and not good for screenreaders); the bug number itself could link to that instead.
- Elements lined up is better: “view this bug” wobbles from report to report.
Perform the solution
Changing something in Launchpad should involve more than just implementing it.
While implementing it, consider if people will need help to use it. If so, implement the help at the same time. This may be:
- permanent help, in written or video format, on help.launchpad.net
- temporary in-context help, that appears around the feature itself (maybe just for a few weeks)
- temporary links to the permanent help, shown to relevant people when they next visit any page in Launchpad.
When the change lands, if it is interesting, announce it to the world. Besides helping people understand the change, it also helps people get a sense that Launchpad is improving.
Finally, in the following days and weeks, test whether it’s working. Is it having the effect you wanted? If it was intended to make something easier, have task completion rates gone up? If it was intended to reduce mistakes, have those mistakes actually reduced? If there’s a big effect, make a graph and publish that too.
“Fewer words is better” and “Fewer controls is better” are analogous to Edward Tufte’s principle of maximizing the data-ink ratio, and that principle applies to Launchpad too. For example, in Launchpad’s presentation of bug comments, changing “Jane Smith wrote 5 hours ago:” to “Jane Smith, 5 hours ago:” would be an improvement. But removing most of the borders around each bug comment would also be an improvement, even though it doesn’t involve text or controls. —mpt
In addition to 'should' I propose 'please', 'do', 'don't', 'add', 'change', 'remove', 'move' - imperatives - as red-flag words in bug reports. Even if filed by developers, such things *at best* age rapidly and lose context and thus comprehensability amazingly fast. --lifeless