In an earlier post, I talked about how UX fits into the development process and ways we could be adapting and improving collaboration. I feel like there is a lot that UX has brought to product development as our field has matured and there is a lot about solid UX principles that we can and should be leveraging in our design process and methodologies.
In this post, I’ll be focusing exclusively on the Planning and Analysis stages of the Software Development Life Cycle (SDLC):
Requirements Gathering (today)
The first phase in most project usually involves gathering requirements. This phase can have a tendency to be very rigid, for example: business analysts conduct stakeholder interviews to get the very detailed answers they need in order to write their business/functional requirements documents. That might be an overly reductionist view of what often happens, but regardless of who begins gathering requirements, what I often see is the following pattern of questions:
We will sometimes get hung up on labels, but whether you call them scenarios or journey maps, or user flows; what I’m referring to here is the situation in which someone is engaging with your product.
Kim Goodwin had a great conversation with Jared Spool on scenario-driven design here. It’s only 30 minutes and well worth listening to, but here is the transcript if you prefer the written word.
Why should you care about scenarios?
Moore’s Law is still holding and as technology is rapidly advancing, we cannot accurately predict how tomorrow will solve today’s problems. Therefore, it is unrealistic to expect everything we build today to work for tomorrow’s users.
This is where I feel like scenarios can give us an edge in our design: by increasing the time to obsolescence.
If we design for features first (without considering the scenario), then we’ve really only addressed the symptom of the user’s true problem. That means all someone else has to do is actually solve the problem and their product will be superior, even if we have the better features. Users don’t want features, they want solutions to their problems.
How do we consistently create UX strategy? Tough question.
Part of the problem is in the fuzziness of the term “strategy” itself. Many people blur it with detailed planning. Others consider strategy to be in-depth investigation, such as market research or competitor comparisons. Or, it gets conflated with vision or ambition.
None of these is strategy.
Strategy is about uncovering the key challenges in a situation and devising a way of coordinating effort to overcome them for a desired outcome. It’s an interlocking set of choices that aligns activity and shows causality: if we do this, then we expect to see that.
Analysis and planning, while necessary inputs and outputs in the strategy creation process, are not the core of strategy. You can’t analyze your way to strategy: the answers don’t magically emerge from data. And detailed roadmaps don’t provide the rationale for the activity they organize. Strategy does. It connects analysis and planning with an intentional logic that guides decision making.
I talk a fair bit about designing for the “best experience” and supporting fluffy concepts like “flow“, but only a lucky few of us live in a world where we can actually do that. For the rest of us, there are always limitations–both human (e.g. office politics, leadership mandates, etc.) and system (e.g. time or business constraints)–that prevent us from being able to actually create those experiences.
So that means you have to do one of two things:
Design only what you can realistically build right now
Design the best experience and then scale that back to something that viable
Getting feedback from users is a critical part of designing the user experience for a product. But gathering feedback can be a daunting task. What is the best format? What questions do I ask? How do I translate what they are saying into something usable? Here is my guide to making user feedback more successful, I call them the 5 W’s: