Document has now been shared with all agile coaches.

Please add comments, or change typos as soon as you see them ;)

UX DESIGN PROCESS
a draft by Jakob Nanneson
Methods to create the perfect interface in steps and with successful results.

Introduction
Ive choose to write this process in order of importance instead of using a timeline. A timeline can indeed be a great overview, but unfortunately its easy to concentrate on the wrong things, e.g. if I draw you a timeline with a daily morning meeting it would be easy to feel successful if attending all those meetings -even if the biggest value is gained through the monthly meeting that only happens once. This list will help you focus at one thing at a time. When one is routine, you can implement the next one. Im not suggesting changing everything at once.

Table of content: Introduction Methods 1. Team improvement each month 2. Sketches, lo-fi mockups and wireframes 3. Test, then listen to the feedback 4. Work together and share what youre doing 5. Really understanding the problem 6. Delivery and long term customer service 7. Collect all style elements in assets library 8. Visual design is truly important

Methods
1. Team improvement each month
There is no perfect solution, hence no way to create a perfect design process. New problems will always arise, so we need to have a process that can evolve within time. The safe way of doing this is to include improvement as a important part of the process. My experience is that once each month will be a great pace to take a bigger meeting and evaluate how the team has been working together with each other. The meeting can also be held twice a month, but we should also remember that we might need some time to each experiment before changes can be evaluated. The team should still evolve each day with individual efforts, but each month the whole team will meet and do this in an structured way. Areas to discuss: People Relationships Process Tools Agenda: 1. What was awesome last month and what can be improved? 2. Decide what changes we all will try during upcoming month.

2. Sketches, lo-fi mockups and wireframes

We want to be able to visualize many ideas, this is the main reason why we dont want to spend time creating high fidelity graphics. The goal in the first phase is to sketch in the fastest tempo possible. Methods: Use a whiteboard. Take a picture when done, and erase. Draw a new sketch with thick marker on paper or use tools like Balsamiq Mockup to draw lines and boxes on your computer, arrange the content so the flow, the navigation and structure feels good. Details doesnt matter, its even OK to use Comic Sans as a font just to make sure that nobody thinks this is the final design. In the following steps you might need to use any possible method to make sure that people can understand your sketches. You might write notations to describe parts of the sketch, you might also invest some time to make the most important part of the sketch more clear to the user by using icons or parts of existing design or from shared or private asset library. You might even want to make a quick animation.

Some might be tempted to skip the sketches and start creating a wireframe using tools like OmniGraffle or similar. Wireframes is great, but as those are much cleaner than a sketch you make with a thick marker you might be mentally blocked to destroy it with unclear design decisions. I would recommend to create the sketch with a thick, then thinner and thinner pens/markers until there is enough details to for people to get back with valueable feedback on. If youve worked in the team for a while you might not need to do much for people to get your idea. Design conventions and similarities with existing design will help your sketch become understandable. Feel free to share this knowledge to stakeholders and everyone who is eager to be in the process of designing great interface. The main aim is that sketches should be used to visualize an idea. This is not a skill to keep to yourself. If more people were able to visualize their thoughts and ideas we wouldnt spend such amount of time trying to listen and understand. We would actually see it. You might use colors and add some shadows, but be aware that the focus might be shifted when doing this. The person who give you feedback might all of a sudden make comments related to the colors and graphics, instead of the much more important decisions related to structure and navigation.

3. Test, then listen to the feedback

Each new design need to be tested and fortunately there is a lot of ways of doing this. Its also easy to oversee this step. But if people dont know how to use the final design, it will never be a success. The solution is simple though. Let people test one or many different designs and listen in on the feedback provided both personally, but also through data provided. If users are adopting a specific feature more after the design change, this is also great

data. Be sure to measure how the interface is used, but do it in an effective manner. Too much data doesnt give you more value then just enough data. Ways to collect feedback: 1. Interviews 2. Beta testers 3. Employee release Personally I really like the interviews. Its common practice that you give the user a task that they should solve. Depending of the prior knowledge you will get different results and different focus of the feedback. It strikes me how easy it is to just sit next to someone and see how they are using the interface. It might sounds trivial but during my years as a web developer and in close relation to developers at Tradedoubler I experienced loads of benefits from just sitting next to someone and see how they use the offered interface.

Big fail on user design. How real people will use Windows 8. Click to view video

Beta testers are often power users and early adopters who has a loyal relation with the Spotify brand. Depending on who will be the beta testers, feedback will vary. If the beta is public (as with first Phoenix release for Android) you might receive media attention, both good and bad. Be aware of this, but dont be afraid. My personal (and agile) point of view is that you should release early and take care of all the feedback. Be clear to the audience that the design is not final, that were trying of different alternatives, and that all features wont go into the final version. During the beta testing phase users will share screenshots and they might end up on blogs and in magazines. This is a great potential to build our brand awareness. Employee releases is a great routine to check the functionality in a bit larger group of people while releasing it in a safe environment. This might be good if you release things of high marketing value. But, you should know that this group testers is quite homogeneous, everyone is well aware of Spotify, the functionality that should exist etc. The value of releasing to this group must be complemented by other testing. On this topic I would like to suggest that some functionality could be released before they are available. Both Apple and Microsoft has been talking about their new OS long time before releasing it. They have published feature specs on the web and people are able to discuss them. Developers will be able to try a unstable beta. This is a much needed process to get input from the whole community. Spotify should also see this as an opportunity.

Methods: When testing a design on or through a website you might also use screen and sound recording tools in a very efficient way. There is tools where you can send out a link to many people and they will follow the instructions and their actions and narrate what they are doing and what they are thinking while doing it. The benefit of this is that you can involve people from a wide range of backgrounds. The fact that you will have a hard time influence their behavior might also be a benefit. Another great method is the number of three. Ive been practicing this when Im doing sketches. I try to end up with one extreme version, one easy or clean and one perfect solution. When creating the extreme versions I often find great things to put in the perfect solution. Its often something I find out is quite easy to realise and still very good to include. It can also be a totally new idea that I didnt dare to write in the more subtle versions of the design. The extreme version help me being creative. Sometimes someone will like any of the more extreme versions more than the perfect version of the design. So this is also a great way to find those bold design decisions that is really well integrated with the rest. Often I also feel the need to make a simple, and then an even simpler, version of each sketch. This will help stakeholders to find the right level of features to include.

4. Work together and share what youre doing

Knowledge sharing is the key to successful solutions. That is why we have a quick status update each day. Although this is actually a meeting without discussions the meeting itself will give people reasons to talk to each other at a later time. During this quick meeting of 10-15 minutes I (as in everyone) share what I have been doing, what Im doing next and what hold me back in the process. What might be helpful is to prepare 3 sticky notes each and put them on the wall. This will also help the team and managers to get a overview during the day without attending this meeting. The time of the meeting should be discussed in the team and might be adjusted later. There is benefits of having the meeting in the morning as a way of greet each other (and maybe eat breakfast together?). But if everyone is leaving the office at the same time each day -it will probably be a lot easier for tell people to tell what they have been doing during that same day. And, wouldnt you leave the office with a feeling of being important, if you got an insight of all great things that been done during the day. Maybe enough reason to arrive early next day? Please experiment with these meetings. But make sure that the purpose is to give a quick status that others in the team will benefit from. From this meeting questions and ideas will rise and they will be discussed LATER. This meeting is to sync between team members. Manager might not even attend. Questions and ideas that have been raised during the status meeting should be discussed with anyone interested. Even stakeholders can be invited as guests, because its important to discuss the issues with the right persons. Ask yourself what will be discussed, who should be involved and who will arrange this meeting. An

quick solution is to take this meeting right after the status meeting -but be sure to end the status meeting before start discussing current issues. Meetings are important and often hated, so I will gladly share my top suggestions for a better meeting. This list can be discussed within the team: 1. Start meeting on time, but end it 10 minutes early, e.g. 15:00-15:50. 2. Let everyone say whatever is on their mind before starting meeting. Could be anything. If someone is sad or excited you will probably notice. 3. Have an agenda that everyone agree on. Add a break or change position each 40 minutes, e.g. standing by the board, talk in smaller groups, etc. 4. Let everyone talk. Some people will need some time to collect their thoughts. Minorities, tokens and people on video link will have precedence.

5. Really understanding the problem

Design is extremely important. We want people to notice that were doing a great job. Thats why we need to prioritize things people value the most, that includes both what the stakeholders and what the colleagues in the same team think is most important. Its great if there is one dedicated person in the team who works as an expert on prioritization. This mean the person need to have a tight relation with each stakeholder, keep them updated and be clear about their expectations. This person will make sure that a developer who needs a design, get anything valuable as fast as possible, so he or she will be able to give feedback in an early stage. When we find a problem and a difficult design decision must be made, we must be sure that we understand the problem. If the problem is particularly difficult everyone involved need to meet the people who are able to describe the problem and all the different angle. We might call this a brief. Final design, colors, shades and shadows can often be added when development is close to finish. But the flow, processes and navigation might be hard to change later in the process. This is why its great to have one specific person who find out what the problem is so the team can focus on providing whats expected (and maybe a bit more than that)

6. Delivery and long term customer service

The work isnt done when sending a PSD to a developer. Its not even done when a new design has been presented and described in details. Each design will have a long life and might be adjusted and improved many times during years to come. To have an organizational structure for these things are important. Even if the main part of the team is working focused on new tasks I wouldnt mind a smaller group within the team giving great customer service to whoever of our fellow co-workers whos in need of support from a designer.

Some request might be from the the external customer support who might need help in answering questions related to design decisions. Some design related decisions might also be teached to customer service so they can give the answers directly.

Medieval helpdesk trying to help someone to start using a book instead of using paper rolls. Click to view

7. Collect all style elements in assets library

Each graphical element that is created should be saved in a assets library. This is of great help for anyone who need to know the current design guidelines. Each item in the library should be open for discussion and standards will be set in this context. This assets can be used when preparing a sketch or mockup for presentations or when we need to make some final design alternatives. You will never need to think about what a button should look like. Using this library of graphical elements you will find a way to quickly design. You will probably also find some challenges that needs to discussed.

One tool that can be used for this in Evernote. To be able to quickly grab a part of the screen and add it to a library with a optional title and tags might be a quick way to begin building this library. With a 5/mo paid subscription you will also be able to a save 1GB of files and have your images indexed for search. Actually, I wouldnt try any other tool until Id tried this one. Picks from the library might be chosen to illustrate graphical guidelines to the rest of the organization. When developers create their own libraries, or even during the work that is been done during the hack days, this might be of great help. But the greatest benefit is when doing the final design. If ever stuck, looking through the screenshots of related screens, even from other platforms, might inspire you to both to improve existing or find a related problem addressed and resolved.

8. Visual design is truly important

You hate to see this on the last place in this prioritized list huh? I would say that the visual design is extremely important, but it wont be of any value if the rest is missing. And if the other parts of this list exist, the visual design will be much more interesting and appreciated piece of work to spend time on. The value of knowing that the visual design youre currently producing will be loved both internally and by end users should be appreciated. Graphics can be great to look at for whoever interested in the area, but if it is more art than function it might never be released.

Screenshot from Dribbble

The colors, shadows, and even size and margins of a simple button can be of major importance and by testing different alternatives with support from real user experience and data, a graphic designer will constantly learn not only what looks good, he or she will also learn how to find the perfect balance between usability and whatever that looks the very best. This is accomplished by a combination UX Design principles, more specific information design, interaction design, visual design and research.

Copyright notice: Havent found the URL where this image was published.