Back in April, I gave a presentation at DevNation in San Francisco about user experience for developers. My goal was to provide both Red Hat developers and our customers some information about how to approach their projects in a more user centric, design first way that will reduce re-work for developers.
Developers spend 50% of their time fixing avoidable issues. The top three reasons[1] for this are:
- Badly defined requirements
- Poor communication between customers, developers, and users
- Stakeholder politics
User experience focus can help prevent this!
My presentation introduced developers to user-centric design practices, usability testing, and visual design as ways to achieve better use of development time. The first step to doing user-centric design is understanding who your users are and what they do!
Know your users
The goal of building software is for people to use it. In order to do this successfully, we need to understand who we are building it for. For any project, whether it is a point release or a major iteration, you should be able to answer the following questions:
What do my users do daily?
If you are building something that they use in an office environment, what is their job and what does it entail? If you are building something that they will use at home, what are their hobbies and daily tasks/needs?
Understand what your users do day to day, so that you can answer the following questions in the context of their typical behaviors and activities.
When will they use my software?
Is your software something they will be using all day, every day? Once a day? Once a week? Once a month? Once a year? Know how familiar users will become with your software, so that you can understand where you should be on the scale of simplicity to complexity/flexibility. Will users remember how to use your software when they come back to it, or do they have to relearn it every time because it has been too long in between uses?
Also, will they use your solution only when they are doing certain other activities or using other systems? What dependencies and
What else might they do at the same time?
Will users likely be focusing completely on the task at hand in your application, or will they be multi-tasking when using your software? Are they in an environment where they are likely to get interrupted mid-stream, and need to come back to your software with a sense of where they were and what they were doing?
What are their main goals or tasks?
What are your users actually trying to accomplish (that might be outside of your software)? How does your solution fit into that bigger workflow? What is the urgency of their goal or tasks?
Make Personas
Once you are able to answer the questions above for your different users, build out some personas to help you visualize your user types throughout the product development process. There are many articles on building personas out there, and I’ll add my own soon for more detail on how to do this!
Doing these two steps for every project will ensure that you understand who your users are and have reference material to help you remember them throughout the design process. In my next article, we’ll talk about understanding and capturing what these users want from your product.
[1] http://socialmediatoday.com/bitpakkit/267487/roi-ux