UX for Devs Manifesto

UX for Devs Manifesto Design from the outside in. Make time for research. Keep your hands off the keyboard. Try many things. Keep none of them. Test designs with people. When all else fails, code. Details make or break it.

 

If you're scratching your head at or intrigued by some of these, that's a good sign. If you're feeling a bit indignant, that's even better. If you totally agree--awesome! So lemme splain.

Who's This For?

Well, like the name says, it's for devs. Why is it for devs?  Well, hopefully, if you're a designer, all of this is old hat to you, and you know this and a lot more.  If you're a dev fortunate enough to work with UX designers, then probably this is something you're familiar with already, and you can relax a bit, let your UX folks take the lead, and work with them to make the design effort successful.  But mainly, this is for the vast majority of devs who aren't also designers and don't have the luxury to work with them.

Why?

We are several years into a significant transformation of the software industry. The change is from a technology-centric view of software to a human-centric view of software. The change is all around us, and if you can't see it, I probably can't help you. ;) So rather than beat the "why UX is important" drum more, I'm going to assume you already know that it is and move on to explaining the manifesto. I'm also assuming the principle that you, a dev, will take some time to at least read a book or two on UX and Design. You don't need to become a profressional, but just learning and trying to practice some of the fundamentals will help you make software that your clients and bosses appreciate a lot more (and that means good things for you, right?).  And if you have UX folks on staff, this will only help you to collaborate with them more effectively.  Without further ado...

Let's Put Some Meat on the Bones

1. Design from the outside in. - This means you don't start your software project thinking about the database, or even the object model. You don't start worrying about how to optimize relationships or transfer data objects efficiently over the wire. You don't just throw forms over database tables and say "done!".  On the contrary, you start by thinking about your software from the outside, i.e., from the perspective of the people who will be using what you make. Put yourself in their shoes as you go throughout design and development--try to forget (compartmentalize) your knowledge of all the inner workings and see what you're making from the outside 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 starting to design or critique a design.

2. Make time for research. - Do some research before you start designing. Don't be satisfied with a business requirements doc, nor with a basic interview with a stakeholder. Don’t just throw together a survey and count that as research. Learn about the people who will be using your software. If you can, meet them, observe their work--even for a short time, talk to them about their pain points, look for ways that you could make their lives better with the software you may be building.  Look at what others have done, find 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 that research in a way that helps you think from the outside in (e.g., personas, stories, storyboards).

3. Keep your hands off the keyboard. - Resist the urge to start typing code from the get go. Don't even start drawing up diagrams. Stay away from the computer! Start with paper and pen, or a whiteboard if you're with colleagues. Grab those personas and stories, come up with narratives from your users' perspectives (this means you don't start from people sitting in front of your software, as if they rolled out of bed and directly in front of your interface--you start from a real-world context where they might need to use your software). Block the narratives out where you might have interactions with software (make storyboards).  THEN start sketching UIs to fill in the empty boxes on your storyboards.

4. Try many things. Keep none of them. - In your sketching, sketch many (like more than three) alternatives--especially if this is a core activity. Sketch out the obvious one you already have in your head, then do another, completely different one--even if it seems stupid or incredibly difficult to implement. Putting yourself in your users' shoes, how would they like to do that activity? What is the easiest, most delightful way it could be done? Do two more alternatives. Once you have several alternatives, look for what's good in them (get colleagues involved in this if you can). Don't keep any one of them--combine the good from all of them into new alternatives that synthesize the good from the many.  Create higher fidelity design (or two) from them that validates the design in terms of your target devices (resolution, interaction capabilities, etc.), but don't code it yet or worry about styling--use a wireframing or prototyping tool (even the ones that are simply stencils on paper).

5. Test designs with people. - Get your best designs in front of people--ideally the people who will be using the software, but at least someone not involved in the design process. Ask them to do what your narratives describe--don't tell them how to do it; just give them the goal and ask them how they'd do it. You can do this with paper, print outs of your design, or if you have an interactive prototype, with the prototype.

6. When all else fails, code. - Only write code if you can't try your designs without it, or if coding will actually help you validate more quickly than other choices. Avoid at all costs writing productional code in the design process; certainly do not write unit tests for a prototype. The goal of a prototype should not be with a view to how you can reuse/port the code at the end of it. The goal of the prototype is to test out a design idea (or test technical feasibility). Only code enough to test the idea and no more.

7. Details make or break it. - After you've done all this, THEN you start thinking about how you can design the internals of the software and implementing it to make your UI design a reality, doing your best not to compromise good UX for expediency. The little details--like how you handle unexpected exceptions, input validation & helps, alignment and spacing, judicious use of color, and making a user do something that you could do for them--these all add up to make or break a great experience with the software you're making.

What Do You Think?

This manifesto touches the surfaces of key aspects in changing the way devs can approach making software. Some of you are already doing bits and pieces; some are doing most. Some might have a more intensive process for a few of the steps, especially if you're working with UX folks already. I'm trying to keep the manifesto lightweight enough to remember and be fairly practicable in most dev environments. I'm trying to keep it fairly process agnostic--only prescribing a high level ordering based on known Design best practices. There are MANY particular design processes, and even more software dev processes. Hopefully you can find a way to adapt some or all of these into whatever process you work in--it can only help make you more successful, and it's only as time intensive as it needs to be in order to solve the problem at hand.

So what do you think?  Does it work? Are there points you would remove? Points you would add? Embellish? Simplify?  Let me know! This is just the first draft, an attempt to codify a simple set of best practices for devs who care about UX.

--

Want to discuss? Feel free to comment here, tweet @ambroselittle, or connect on Google+ or LinkedIn.

 

Update (2 July 2012) - Got feedback saying this was the UX designer's job, so I added the section titles and the section "Who's This For?" to clarify the intended audience.

Update (19 September 20120) – Francis Rowland pointed out that I can’t count (that there was a mismatch in the top/bottom numbering).  And “when all else fails” is hyberbole—amended to add the bit about coding if it helps validate idea more quickly—suggestion from Adrian Howard. Also, added warning against just doing a survey as research (via Adrian).   Thanks, y’all!