UX Manifesto: 7 Principles for Better Software

Most developers want to do good work. Most want their work to be appreciated. At the very least, developers want their work to be valued so that they can get paid, and maybe even get references, bonuses, raises, or just continued employment. Some developers also are altruistic and want to help others and somehow make a difference—make the world better. What I am about to share with you addresses all these goals.

No, it isn't magic. It isn't a guarantee that just reading this article will make a difference; but I guarantee that if you apply the seven principles I call my user experience (UX) manifesto to your software development efforts—if you practice and hone them—you will see a difference in the software you produce, and it will be a good difference as far as your clients, stakeholders, and users are concerned.

Common Misconceptions

Before I dive into the principles, I'd like to address some common misconceptions about UX (considered as a set of practices, techniques, tools, and, further, the professionals in the space) and its applicability.

A good UX doesn't apply to all software. Most people understand the value of "good UX." Maybe 10 years ago people might not have appreciated it as much, but these days everyone has most likely had great experiences with software—be it a word processing program, some slick website, a game, or perhaps a GPS navigation program. Maybe you even like your desktop operating system.

People that believe this misconception have the impression that only developers creating software solutions for consumers need to be concerned about UX. On the contrary, it has been shown repeatedly that a good UX has a high return on investment, even for internal business solutions. And it makes sense, too: if your employees can complete their work with less fuss, less frustration, and fewer errors, they will be happier, stay longer, be more effective, and ultimately improve the bottom line.

Developers can't create a good UX. Despite the fact that everyone is not a designer, that doesn't mean developers and other non-designers can't do things to improve the UI of the solutions they create. That's what this article is all about. You may not make the most beautiful, sexiest, efficient, and error-free software, but you can "make things suck less," as I like to say. There are degrees to everything, and you can invest some time and effort in good design and make significant improvements over what you'd probably create without trying.

You may not get paid to design, but you know what looks good. Just because you're smart, can sketch UIs on a whiteboard—and even code them, doesn't make you're as effective as a trained and practiced designer. This should go without saying, but it's amazing how many people forget this in practice and believe that whatever they like and think is good is a good design. You can even learn and apply the principles in this article, and you still won't be as effective, capable, or talented as a professional designer. Even if you are quite talented, there is a lot to be said for experience and focus—if you split your energies across various roles, each will inevitably suffer.

So while you absolutely should read and apply the principles in this article, if you have or can afford professional designers, you should defer to them when it comes to the human-facing elements of your solutions. This article is not geared toward developers who have professional designers available, but rather those who do not or cannot take advantage of professional design expertise.

The Principles

Each principle is based on a significant amount of study and practice, research, and trial and error, as well as the expertise of many UX professionals. I have tried to distill the information into seven actionable principles. They aren't algorithms or patterns; on the contrary, they are meant to be adaptable but concrete enough that you don't have to do all the work to adapt them.

Also, I intentionally kept the number of principles as few as possible so that you can easily memorize and make them a part of the way you make software. They are also flexible enough to fit into virtually any process, assuming your colleagues are willing to try new things within your procedural framework, whether you're on the waterfall or Agile side of the spectrum.

The seven principles of my UX manifesto are:

1. Design from the outside in. Don't start your software project thinking about the database, or even the object model. Don't worry about how to optimize relationships or transfer data objects efficiently over the wire. Don't just throw forms over database tables and say, "Done!" (See "Antipattern: Forms Over DB" for more on that.)

Instead, start by thinking about your software from the outside (i.e., from the perspective of the people who will use what you make). Put yourself in their shoes as you go through the process of design and development. Try to forget (compartmentalize) your knowledge of the inner workings and see what you're making from the outside looking in.

Think about the most important, critical activities and optimize for them—don't make everything equally easy, which really means equally hard.

Remember that you are not (usually) the user. Say, "I am not the user," three times before designing or critiquing a design.

Check out these books on designing for people.

2. Make time for research. Conduct research before you start designing. This is very important, especially for niche, custom software that is the bread and butter of internal IT. Skipping the research step is a major reason why projects and products fail.

Often the research that is done is cast as "requirements gathering," and the results of it are thick Business Requirements Documents, Functional Requirements Documents, Use Case Scenarios, Use Case Scenario Diagrams, Business Rule Definitions, and other imposing catalogues. Frankly, these tomes are a waste of time or, at best, missing the mark when it comes to how research energies should be spent on software projects.

Don't be satisfied with a business requirements document, nor with a stakeholder interview. Perhaps you can't change a business's software development process. Maybe someone else does the requirements gathering for you. Whatever it is, the bottom line is that a large textual document containing a bunch of rules is not going to help you design great software. You'll be lucky if you end up with software that meets the business needs, let alone software that is accepted, used, or liked by those who use it. And saying "they have to use it" or "they can be trained" misses the point, too. Remember what I said about the ROI of a good UX?

The good news is that there is a better way. Even if you have such formal documents, you can do user research to augment them, and it doesn't have to be expensive or time consuming.

To do this, don't just throw together a survey and call it research. Learn about the people who will use the software. Meet them, observe their work—even for a short time. Talk to them about their pain points. Look for ways the software can make their lives better. You'll see things not captured in any requirements document. And it may be that one little thing you notice that makes all the difference in improving the users' efficiency and productivity. Even if you can't spend time with users, a brief tour of the location where people will use the software can be insightful. Take some pictures—this can help you stay in their shoes longer.

Ruth Ellison offers a good look at guerilla user and design research that you can explore. Also, look at what others have done. Find UX and UI patterns. Don't blindly copy—understand why a design works, and when it makes sense and doesn't, before you use it as inspiration.

Capture your research in a way that helps you think from the outside in (e.g., personas, stories, storyboards). Personas are good for making information about your users more relatable. Base them on the real users you meet—the real information will help make the connection and empathy stick.

Stories (a.k.a., user scenarios) are helpful, too. These are more than the generic, "as a user, I want to X" user stories that you find in Agile development. User scenarios have more realism and narrative. They focus on flow rather than individual pieces of functionality. How users transition from task to task is key to improving software usability—think more in terms of experiential flows and less in terms of bit by bit features.

In their book, Storytelling for User Experience, Whitney Quesenbery and Kevin Brooks offer the following benefits of using stories in software design:

Storyboards take user stories one step further. Read more about storyboarding in my UX Magazine article, "Storyboarding in the Software Design Process."

3. Keep your hands off the keyboard. Resist the urge to type code from the get go. Don't even create diagrams. Stay away from the computer! Start with paper and pen, or a whiteboard if you're with colleagues. Grab those personas and stories and develop narratives from users' perspectives (i.e., don't start with people sitting in front of your software, as if they just rolled out of bed and directly in front of your interface—begin with a real-world situation in which people would use the software). Sketch the narratives (make storyboards), depicting where interactions occur with the software. Then diagram UIs to fill in empty boxes on your storyboards.

4. Try many things. Keep none of them. In your sketching, create many (more than three) alternatives—especially if the storyboard depicts a core activity in the software. Sketch the obvious way (that's already in your head) to achieve an activity, then draw another, completely different one, even if it seems stupid or incredibly difficult to implement.

Put yourself in users' shoes. How would they like to accomplish an activity? What would be the easiest, most delightful way to get it done? Sketch that one, plus two more. Once you have several alternatives, look for what's good in them. Get colleagues involved if you can, or even your stakeholders. It's better to show them many alternatives, which will encourage them to say what they think is good about each of them—having multiple alternatives invites constructive criticism.

Don't keep any of them. Combine the good aspects of all sketches into new alternatives. Create a high-fidelity interface design (or two) that validates the alternatives in terms of target devices (resolution, interaction capabilities, etc.), but don't write code just yet or worry about styling. Use a wireframe or code-free rapid prototyping tool like Indigo Studio to get a better feel for the potential design.

5. Test designs on people. Get your best designs in front of people—ideally the people who will use the software, but at least someone who is not involved in the design process and is somewhat like a user. Ask the tester to do what the narratives describe. Don't tell them how to accomplish the task; just give them the goal and ask them how they'd do it. You can do this with paper, printouts of your design, or an interactive prototype created with a tool like Indigo Studio.

I can't emphasize enough how crucial this principle is. Don't wait for the software to be written in code before you test it with users. By all that is good, don't wait for user acceptance testing—that's too late. As a rule, the earlier you can test your design ideas, the cheaper it will be to change and improve them. And again, the software doesn't have to be tested by actual users. If you can't get access to them, find someone who is not biased by knowledge of the design.

6. When all else fails, code. This is a bit of an overstatement, but it's important to drive home that quickly jumping into code is usually the wrong thing to do. The exception to this rule is when it would truly be faster and more effective than a lower fidelity option. Only write code if you can't test your designs without it, or if coding will help you validate the designs more quickly than other procedures. Avoid—at all costs—writing production code in the design process; certainly do not write unit tests for a prototype. The goal of a prototype shouldn't be to reuse it for or port the code to production at the end of its temporary life—banish that idea. The prototype's goal is to test a design. If you must write code, write only enough to test the idea, and no more.

Prototyping comes before coding even in an Agile process. While Agile is better than waterfall at iteration, it's nowhere near as effective for iteration as a prototype. The reason is the same as for avoiding writing production code at the prototype stage. If you're thinking about producing production code, you introduce a ton of baggage into your prototype and inevitably get more invested in the design idea—and thus are more likely to resist changing it. You must be able to throw away a prototype without thinking twice about doing so, and rarely does coding allow you to maintain that level of non-investment.

7. Details make or break it. After you've done all this, then think about how you can design the internals of the software and implement it to make your UI design a reality, doing your best not to compromise good UX for expediency. The details—as in how you handle unexpected exceptions, input validation and helps, alignment and spacing, judicious use of color, and making a user do something that you could do for them—add up to make or break a great experience with your software.

If you skip over the details or sloppily implement the UI, then all the effort you put into making the software will have been for naught, especially if you go to the extra effort of incorporating these principles into and practicing some aspects of UX design in your process. There is a ton of low-hanging fruit you can tackle, even if you don't have a designer bone in your body. UX doesn't have to be pretty or sexy to make it effective and easier for people to process and act upon.

Dig deeper to get the details right:

Practice These Princples for Better Software

The seven principles of my UX manifesto are:

Print them out. Write them on your walls. If you internalize these principles and practice them, you can create better software. Most importantly, it will be software that is better appreciated and valued by the people who use it, and the ROI such improvements bring will be appreciated by those who pay the bills. A key aspect of these principles is minimizing costs by learning as early as possible—when it costs less to make a change—what changes are necessary to create a better UX. But there are also benefits on the user side: increased effectiveness and productivity, with the additional bonus of happier employees and all that entails for a company. These are the very goals that most business software is written to achieve.