Article summary
If you or your organization is ready to invest thousands of dollars on building a piece of software, you hopefully already have a good idea of who your users are and how they will interact with your product. You could be a subject matter expert, or your company may be a leader in the field that your project is targeted towards, putting you in a great position to provide background on what the software ought to do and how it should be used. What you’re looking for is a top-notch team ready to hit the ground running and build your software.
In a previous post, I discussed how Atomic Object engages with our clients in a phase of Research, Design, and Planning (RDP) at the beginning of each project to help define and refine a software product. If you’re well-prepared and grounded in your field, it could be difficult to see how this work could be worthwhile for your project, and skipping RDP may seem like a great way to save some money towards feature development. However, just a bit of time up front can pay off in a big way during the build phase of your product. Here are several ways an RDP phase can benefit a project.
1. RDP helps discover new and greater opportunities for your product.
As a software designer, I have great respect for my clients’ insight into their industry and their users’ goals, and I leverage that insight wherever possible throughout a project. However, some of the greatest “aha” moments come when, together with our clients, we get out of our own offices to do activities like user observation, user interviews, and early prototype validation. Observing the problems that people encounter in their own environment, and the ways in which they solve them, yields insight and reveals opportunities that can’t be uncovered any other way, and can make a good idea even more marketable.
2. RDP helps increase consensus and buy-in within your organization.
One key deliverable that comes out of an RDP phase is a set of user personas and a number of context scenarios that tell the story of how users will engage with your product. As much as possible, these are based on in-context user observation. Depending on the scope of your project and your organization’s needs, these scenarios might be delivered in the form of a set of storyboards, or a presentation deck, accompanied by lightweight wireframes and user workflows. These artifacts help capture the work done in RDP and articulate a vision for the product that will be built.
The context scenarios and wireframes serve as a reference throughout the project as the team works to design and develop each individual feature. They help product owners and product teams transfer knowledge and build consensus about the product that’s being built. However, they also make a great communications tool for our clients to use within their own organizations. The sketches and storyboards, coupled with the wireframes, distill a complex problem into key interactions that are easy to describe and understand, which can help product owners as they seek to build support and create buy-in with other key stakeholders within an organization.
3. RDP can help create excitement and ownership within the target user base.
Users who get to engage with a concept early in the software development process through interviews, prototype validation, and similar activities can often become passionate advocates for your project later on, when you’re getting ready to release. People who are involved with a project early on — even in a very small way — can feel a sense of ownership and pride that they were able to contribute. They want to see you succeed, and they’ll become your ambassadors within their own sphere of influence.
4. RDP provides validation before you spend a ton of money on a concept.
If you’re ready to embark on a several-months-long software project, your organization is probably already convinced of the value the project will bring, and has validated the need that it will serve. However, this doesn’t obviate the benefit of an RDP phase. During RDP, as we work with you to validate the user needs you’re looking to solve, we’ll also be validating different ways to solve those needs. Some questions we might look to answer include:
- What features will be most critical to your users?
- What are some different ways we could implement those features, and which implementation is the best?
- In what ways can your product provide value, beyond those already identified?
Approached in this way, the time and budget spent on research and validation at the start of the project will uncover answers about the best opportunities to address, and having a good understanding up front about what to build and the best way to build it will save on both opportunity and monetary costs in the long run.
5. RDP helps your product team build better.
A client who is a subject matter expert is a huge asset to any software team. Your expertise and insight can help guide the team’s efforts and answer many questions about features and user behaviors. However, in addition to the outside perspective, validation, and potential business opportunities that can be uncovered by engaging with potential users early in the process, seeing a problem from your users’ perspective can help a product team build empathy.
Designers and developers who have witnessed firsthand the need for your product are more passionate and engaged in delivering the best solution possible. They strive to achieve your organization’s goals and delight your users, and they’re even more motivated to solve tricky implementation issues, conserve budget wherever possible, and look for opportunities to add value because the software is connected with solving human needs.
6. RDP helps your internal team increase their own empathy and passion.
Building a software product takes significant time, energy, and money. You may feel your enthusiasm for the project flagging at different points throughout the project. During those times, it’s extra important to be able to point yourself back to the groups of users you’re looking to serve and the needs you’re looking to solve. The research and synthesis accomplished during the RDP phase will give you a solid foundation to refer back to when you start to question your own assumptions about the project, or when you simply need a reminder of why you set out to build this thing in the first place.
Conclusion
Each project is different, and each will benefit from research, design, & planning in varying ways. An RDP phase is not a generic, one-size-fits-all solution that we apply to every project; rather it’s a set of practices that we customize to each project’s needs and each organization’s goals.
As you get ready to start a new project or a new phase of an existing project, think about (and articulate to your software team) the benefits you’re especially looking to receive from the RDP phase of your project, and what questions you particularly want to answer. After that, you and your team should approach RDP ready to listen, observe, explore, and innovate, as you work together to set the foundation for creating a great piece of software.