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:
What are you goals?
This is a good early question. We need to know what the client or stakeholder hopes to accomplish, since they will be the ultimate judge of our success. However, what we are missing here is the Desirability and Feasibility components of the DVF equation.
What does that look like?
It can be helpful to know early on what their expectations are, but starting here can rob you of the flexibility to find better solutions once you understand more about the problem.
Thanks, this is all I need for now. We’ll get started on this immediately.
In my experience, I would prefer an anthropologist with no prior experience in software development to conduct stakeholder interviews over a business analyst with years of experience. This trend is changing somewhat, but we need to be focusing less on the prescriptive “how” and more on the empathetic “why”. Additionally, we need to get client/stakeholder alignment on this “why” before begin codifying documentation or working on design.
Requirements Gathering (future)
- We need to strive for becoming technology partners, not “direct reports”. Stakeholders aren’t designers or developers and, while they know their business (Viability(, they can often be too close to the subject material to recognize where the experience “breaks” for their users (Desirability, Feasibility).
- If there’s any ambiguity around what the solution actually is, then asking the client how they perceive it taking shape isn’t all that helpful. I’ve run into several scenarios where the client wants a specific feature/product, but doesn’t have it mapped to any real business goals and they haven’t defined the problem that this solves for the user.
- Asking the stakeholder how they perceive the solution can also run the risk of their answer being recorded as a verbatim requirement or even cause problems by setting an expectation that that is exactly how we will build it; before we’ve even gotten to the design.
I’ve heard business analysts described as client advocates; which sounds great… on paper. I’m not in any way against the client or stakeholder having an advocate, but problem I’ve seen is when the person gathering requirements begins to feel beholden to the client or stakeholders. This can lead to requirements being written around a bad design decision, something that the UX/design team may have to fight to correct down the road.
I am in no way trying to diminish the role a business analyst plays in a project. I’m focused on the strategy,the “why”, and I need a counterpart who can dive into details about the trees–because sometimes, I’m too busy looking at the forest. I just think that there are some situations where we might be able to improve our methodology to reflect a better process design.
Discovery
There are two questions we need to know about the forest before we start gathering details on the trees:
- What are the business goals? (e.g. increase lead generation from their website)
- What solution is the client actually asking us to build? (e.g. a PPC campaign)
The goals and the solution do not necessarily always come aligned. In fact, there are many times where I’ve seen the solution someone ask for be in direct conflict with their stated goals. It’s important that our process accounts for this and allows us the ability to design something that will have the most impact on the goals.
A client asks you to build them a PPC campaign to drive more traffic to the website. You can write that down as a requirement and begin collecting details (e.g. budget, duration, keywords, etc). Or you can ask “why” until you uncover the reason behind that request: they want to increase qualified leads coming in from their site.
Increasing traffic to the site will almost certainly increase the number of leads, but the additional leads generated will be far less qualified.
Is it potentially a numbers game? Sure; that depends on the client. But the better solution would probably be to investigate user scenarios and make deliberate changes to the website–changes that increase qualified leads as a result of better meeting user needs.
Requirements gathering can and should be more than collecting tactical details on a client’s perceived solution. If I’m going to be asked to design the UX for this solution, it is far more important that I understand why they believe that is the right solution and why they believe that solves some user need.
Users don’t want 1/8 inch drill bits. They don’t even want 1/8 inch holes in their walls. What they really want is to be able to display pictures of their family members in the hallway.
I was only recently exposed to this analogy and I think it does a wonderful job of explaining why I care so much about requirements gathering as a designer. I fear that the rigid approach we sometimes take means we always designing drill bits instead of understand the scenario that would drive someone to put holes in their wall, even though that isn’t what they want to do.
Scenario-Driven Design
One of the best things we can do, if we really want to create phenomenal experiences is to shift the discovery process away from tactical requirements (at least in the beginning) and focus more on the why behind the request. I’ve written about scenario-driven design before and I think that it is critical for us, if we have any hope of creating the right solution for the user. I firmly believe that user scenarios are one of the single most important elements of discovery and should be the largest impacter of our designs. After all, if there are not any users who see the value in the product, then it won’t matter if the product lines up with business goals or not.
Current State
Whether or not they claim to be agile (see: Agile is a Culture, not a Process), many teams and organizations still have a project cycle that looks remarkably waterfall:
As soon as business goals are collected from the stakeholders, a solution begins to take shape. However, we don’t typically think of this as design, it is merely an aspect of discovery. The pitfall here, especially if you are employing a more waterfall methodology, is that the solution is being defined and the business requirements written before UX/Creative has even had a chance to understand the problem. As a result, we are potentially handing our designers requirements around what the drill should look like and how it should function, instead of exploring the root cause of that behavior in a user.
This issue is project-dependent, though; it primarily applies when you are creating something new, rather than updating something existing. For example, if a client wants you to consolidate their partner portals into one central resource, then the scenario-driven needs are much more tactical and there’s not really any problem with a requirements-first approach to discovery. In fact, that approach is preferably since there are so many moving pieces and technical challenges that need to identified.
Future State
Being project-dependent, there are also situations in which a different approach to discovery could be beneficial. Say a client wanted you to take a piece of functionality that currently only exists inside of an authenticated application and they want you to make that functionality available on their public website. It sounds fairly simple and straightforward, but there are potentially a host of issues:
- Currently, users are authenticated in an existing wep app. Do you need to authenticate users on the public site?
- What information is passed through, based on authentication, that you won’t have access to if the users are anonymous visitors to a public website?
- Is the functionality transactional? Does the website support transactions already
- Are they PCI compliant? Can they currently take any form of payment?
- What language is the original functionality built in? Can you use an API or will you need to rebuild the application?
- And most importantly, what problem is this solving for a user? What is the scenario in which a user would be compelled to engage with this new functionality? What ability do we have to create a sense of satisfaction or completion in this experience?
It’s when you have this much ambiguity in the original request that it may make sense to shift your approach to discovery. For example, a scenario-driven discovery would equally weight the user’s goals and shed light on some of the gaps in that thinking. Maybe you get all of the answers to all of the technical/business questions above, but if you don’t know the answers to that last bullet… it will incredibly difficult to create a positive experience for the user.
Whenever you are creating a new product or new functionality, I would strongly encourage you to look at a user-led discovery:
This is obviously not cookie-cutter, but the idea is that you spend time understanding and aligning both the business and user goals, then you frame the solution such that it supports the best possible design for both of those groups. Maybe you go straight from there to tactical requirements, maybe you do some low-fidelity sketches so that you have a much clearer picture of what you need to be gathering requirements on.
Design for the need, not the request
We are far removed from a “build it and they will come” approach to product design. Successful products depend on the experience solving actual problems for for actual people. When we start gathering requirements without the user, we run the risk of designing something that the user won’t be interested in.
Design doesn’t start with wireframes. Design starts at discovery.
When you have a project that is undefined or is creating something new, introduce user-centered approaches that will allow you to uncover the source of the need. Returning to our example, the user need is an emotional desire to prominently display images of those you love. That need can be solved in many more ways than a 1/2 inch drill. Challenge perceived solutions so that you can build your requirements the optimal solution for the client and the user.