DesigningYourNextUIChange

Not logged in - Log In / Register

Designing your next UI change

Based on a talk given by Matthew Paul Thomas at a Launchpad developer meeting, 30 June 2011.

Contents

  1. Designing your next UI change
    1. Define the problem
    2. Design multiple solutions
    3. Choose a solution
      1. Three examples
    4. Perform the solution
  2. Discussion

Here are some ideas on how to make visible Launchpad changes efficiently. By efficiently I mean changing the interface in a way that:

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.

mass-bugs.png

⇄

mass-buildds.png

Looking for related bugs like this has several benefits:

  1. 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.
  2. 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.
  3. 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

mountainscape.jpg

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:

  1. Try removing something.

  2. Try merging things.

  3. Try rewording something.

  4. 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:

Three examples

team-members.png

Consider a team listing. How to apply these heuristics here?

package-info.png

Second example: source package information.

bug-suggestions.png

Third example: the list of suggestions when reporting a bug.

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:

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.

Discussion

“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

DesigningYourNextUIChange (last edited 2011-07-12 20:49:27 by lifeless)