I love a challenge, and the diversity of the challenges I face on a regular basis is one reason I really enjoy my work. My latest challenge has had less to do with writing code and more to do with taking ideas from conception, through research and evaluation, to a basic project plan. I’ve been involved in the early stages of concept development before, but never with this many ideas at once or with this much stake in the outcome. So, I’m taking this opportunity to learn and hopefully improve our process along the way by diving into user experience design.
There is an awful lot of documentation on the internet about user experience design. I’ve read through a bit of it, and through reading I came to understand the basic gist of things like stories, personas, and wireframes. Until yesterday, though, I still felt like I wasn’t getting the big picture — how do all of these things fit together and eventually lead to an informed project plan? Thanks to a great Thursday afternoon discussion with Shawn Crowley over at Atomic Object, I’m starting to see how I can apply the process of UX design to my project. Instead of sharing particular methods first, I’d like to talk about general application of the process to my project and how I envision it will provide value for me, my fellow developers and designers, and the project stakeholders.
Shawn did a really great job of walking me through the process Atomic Object is employing in user experience design, and that has helped form in my mind an idea of what the process is intended to achieve — the big picture that was missing from online materials. Apart from any concrete deliverables, their aim is to:
- Identify stakeholder goals & motivations
- Identify & understand target audiences
- Identify activities involved in achieving stakeholder & user goals
- Assemble a high-level release plan for estimation & evaluation
- Add detail to tasks for the first release to support development planning
- Execute development & other design activities to implement release plan
Concrete deliverables from the process will relate to one or more of the abstract goals above. Each step builds on the previous, introducing new information and keeping the process grounded in facts.
I’m going to start at step one by asking myself a simple question, “How do I identify stakeholder goals and motivations?” One of the methods Shawn and I talked about was a pair interview with a stakeholder: one person asks questions while the other person writes down facts to be reviewed later. But, I already have answers to a lot of the questions I’d ask and I don’t want to waste someone’s time asking them questions I already know the answers to. Instead, I’ll probably start by writing down facts I already know and review them with the stakeholder in a brief conversation. Not that I wouldn’t like to interview them, but it wouldn’t add a lot of value for either of us at this point. I’ll tackle each goal in a similar way, identifying methods and deliverables that have value to me and to my stakeholders, up to the point where I’ve achieved my goal of providing an actionable, loosely estimated release plan.
The process of user experience design is not one for robots. The decision to include or exclude specific techniques or artifacts is entirely up to you, and should be based on the value that they will provide you, your stakeholders, or others involved in your process. Ask yourself and your stakeholders how a particular method or deliverable helps you achieve your goals before blindly writing a detailed process flow or creating a wonderful functioning prototype. For me and my stakeholders, things like high-level stories, reasonable personas derived from past user labs, wireframes (rough, sketchy mockups), and context scenarios are going to be of primary importance because they are useful in communicating our vision. Other artifacts, like content inventories and prototypes, aren’t as valuable to us at this point because we’re still trying to determine the value of our ideas.
At each step I’ll be using the results of the previous steps to inform decisions about prioritization, keep product features and functions on target, and squash disagreements not based on facts. I’m really eager to see where this leads because it appears it will help answer questions I’ve been asking myself and my teammates about communicating project ideas and keeping a cohesive vision across functional teams.
Again, I have to thank Shawn Crowley and Atomic Object for giving me the opportunity to learn from their experience. I’m looking forward to continued conversations as I begin to put user experience design principles into practice, and I’ll do my best to keep sharing what I learn.