Lead Ubuntu designer Ivanka Majic has been taking some flak for her recent blog post about redesigning buttons in Ubuntu’s window manager. And, rightly so; she opens by asking several vague questions, says analysis happened in the form of a sketch, and then reveals that Ubuntu’s window manager buttons will be redesigned. “Is it better or worse? It is quite hard to tell,” she writes.

Unfortunately, Aza Raskin was right when he Tweeted that this kind of “wishy-washy design speak” hampers the fledgling growth of design in open source. We’ve heard criticisms that user experience is just “change for change’s sake,” or that it’s all subjective opinion with no structure behind it. When user experience decisions fail to follow a design process or are described poorly, it does resemble arbitrary change for the sake of change.

However, there’s no excuse for design decisions, in open source or elsewhere, to be arbitrary. While good user experience design does involve creativity and risk-taking, it is not art: it is not left up to the particular tastes of the creator. The goal of user experience design is to solve problems and improve how people interact with technology. The path from a design problem to a solution is one that designers handle differently, but at its core should always resemble the scientific method: a deliberate process that improves and changes based on data. Hugh Beyer and Karen Holtzblatt refer to this as the contextual design process. I’d like to outline the basics of this process as they describe it in their book, Contextual Design. While many variations on this system can be formulated to adapt to various problems, it’s a solid way to approach a design task with a well-defined structure that prevents arbitrary decisions.

Step 1: Contextual Inquiry

In this step, the designer’s goal is to understand the users of the system they are designing. This can be accomplished by interviewing people in the environment they will use the product in to discover who the users are, what problems they face, and what goals they wish to accomplish.

Who are Ubuntu’s users? What kinds of tasks do they use Ubuntu’s window manager for? What do we know about their current usage of Ubuntu’s window manager? What problems are they currently facing? Why are they facing these problems? Let’s sit down with users and find out who they are and what their current experience with Ubuntu is like.

Step 2: Work Modeling

At this step, the designer analyzes what he has learned in the Contextual Inquiry stage. Now the users and their world are known, but this information is often intangible; creating data models that represent the users’ world help identify its structure, successes, and failures. In practice, the most important part of modeling this information is identifying “breakdowns” – places where users encounter problems or frustrations. At Carnegie Mellon’s HCII, we identified these on our models with big red lightening bolts: they are the key towards successful redesign, because they show where the current system is failing the user.

Now that we know Ubuntu’s users and have modeled their work, what breakdowns do they experience? Where in users’ workflow do inefficiencies and frustrations occur? What slows users down and makes their window management a poor experience?

Step 3: Work Redesign

It’s tempting in tech to jump to a technical solution to a problem, but this misses the mark. It is the user’s workflow where problems were identified, and this is the first place to look to solve them. The designer should now identify how the workflow can be improved structurally to avoid breakdowns. Shelley Evenson recommends making storyboards at this stage; drawing the user a new workflow that fixes the structural problems identified.

Now that we’ve identified how Ubuntu’s users’ workflow is impeded by the current design of the window manager, how could this workflow be improved? How could particular window management tasks be improved?

Step 4: User Environment Design

Now that the designer knows how users’ workflow can be improved, it’s time to look at the function and system that he’s designing for. At this stage the designer must decide how the parts of the system work together from users’ point of view. While a system will have a defined technical structure, what users mentally model the system to be is different and more relevant to them. How the system is presented to users should be explicit and distinct from the system’s technical structure.

From the point of view of users, what are the relevant parts of Ubuntu’s window manager and how are they related? How will users understand the various control and window functionality within the system of their Ubuntu desktop?

Step 5: Mock-up Solutions and Test Them

At this point, how users’ experience can be improved structurally has been identified. It’s time to apply that understanding to actual design solutions. This should begin as rough sketches which should be tested with users at very early (or low fidelity) stages. Some designers even begin testing when all they have are paper sketches, having a participant pretend they are using an actual system while the designer moves paper to simulate one. In this way, problems and successes are identified early. That information should guide the design as it becomes higher and higher fidelity. At each stage, user testing should refine the design, and the design should respond to this data and become more solidified at each pass.

Here’s five sketches of how Ubuntu’s window manager can be improved: time to test them with actual users. With these results, perhaps quick prototypes can be banged together in JavaScript, Flash, etc. Once we’ve done user tests with those, it should become clear which design directions are performing best.

Step 6: Ship it! But Consider your Community

The designer has now done the research, the design, the testing – it’s time to get this thing implemented and out the door. But now the designer must carefully consider their organization, community, or company. Every change to a system that people use will create pain, anger, and force users to relearn their habits. It should never be done lightly or curtly. In open source, we have the advantage of transparency. Rather than waiting until Step 6 to debut the design, we can and should be talking openly about it all along. But it’s especially at this stage, when the decision is made, that being respectful of the community is crucial.  A designer can expect that a design won’t be popular just from a screenshot, so explaining the process above – the rationale, the research, the work, the decision-making – is the way to show the design decision is far from arbitrary. A designer in open source can follow the most rigorous and careful design process imaginable, but if they blog saying “Here it is, you’re welcome,” the community has a reason to be upset.

Knowing what I do about Ubuntu users and the Ubuntu community, how can I explain the design decisions that have been made? How can I talk about the relevant points of my design research and process so the users know that this decision has been made in a sincere attempt to improve their workflow? How can I argue successfully for my design, knowing that users will be upset at having to change their work habits?

So, that’s the roughly contextual design process as Beyer and Holtzblatt describe it. Yes, this process is highly formal and structured, and few designers out of school follow it exactly to the letter. However, serious user experience designers use variations on this process for their work. The decisions they make should never be or appear arbitrary.  Designers should be constantly trying to understand users, design for those users, and determine if a design is successful through testing with users.

I hate to call out Majic in particular here, but I did want to highlight that more goes into successful user experience design than her post suggested. And indeed, this might just be a problem of communication: a rigorous design process may have been masked by sloppy language. Given that (in my opinion) Ubuntu’s user experience has been blossoming and improving by leaps and bounds over the past few years, I suspect that Majic and the rest of her team do indeed follow successful design practices. But especially in open source, designers need to carefully consider the implications of what they publish. I should know this, because I’ve said some stupid things in my blog and have been rightly called out on them. Designing in open source is a new animal, and we’re only starting to find effective ways to harness the incredible power of open source communities towards improving user experience. But if a designer makes a decision that appears arbitrary, you have every right to call them out on it. It’s not enough to design well: designers must successfully argue for their designs and the rationale behind them.