So, you’ve finally gotten approval on the budget you need to begin that long-awaited redesign of your corporate website – exciting news! Or perhaps your about to embark on your first entrepreneurial venture and you’re considering developing a custom website or mobile application? I know how tempting it is in cases like these to want to run straight to your interactive agency or web design team and start laying out your home page and choosing colors. In this blog I hope to convince you to take a deep breath before you jump, and go through a thorough process of requirements analysis.
In my experience working with clients on numerous web and mobile design projects, I have found requirements analyses to be critical to success and I always perform them as my first step. Understanding the requirements in advance helps to ensure that business goals and user needs are met, and that the solution achieves what it was designed to accomplish. In a website redesign project, your requirements should map directly to any point of pain or frustration that users experience with the current site. The new web or mobile experience should be customized to satisfy business goals and user needs; if you do not have a good understanding of those needs at the beginning of the project, you are likely to end up with a site or application that neither achieves your goals nor delights your users.
Requirements analysis is an iterative process that begins with an initial brainstorming session and continues throughout the development cycle; your requirements document will evolve and become more useful as a driver for design and implementation decisions with each iteration. Once you’ve done your initial brainstorming and identified some high level requirements with your client, it’s useful to develop conceptual design wireframes that illustrate a potential approach. Having something concrete in your clients’ hands will make their target users’ experience more real to them and enable them to refine and clarify their requirements.
After the initial requirements have been formulated, reviewed, revised and prioritized by your clients, you should – if possible – follow up with “Wants and Needs” sessions. These sessions will allow prospective site or application users (or past users in the case of site redesigns) to validate your requirements findings and identify to what degree they’re on track with users’ needs. Bring that information back to your analysis team to develop the appropriate web strategy.
In some cases, your clients will be prepared to quickly provide application requirements and to reach a consensus on which features or functions will take priority. More often however, clients may need some guidance to tease out the requirements at the level needed to be useful to your site or application development team. Gaining consensus on requirements can be tricky in a company with multiple stakeholders. This process requires careful management of the personalities involved, and asking focused questions about the importance of each requirement.
I find that getting stakeholders to clarify their rationale for requesting a certain requirement is an excellent way to generate discussions at the group level and to determine whether or not it should be prioritized in the final design. Throughout the consensus-building phase, it is critical that all team members feel invested in owning the requirements as well as the analysis process.
One of the biggest challenges of any requirements analysis is getting the right amount of specificity from your stakeholders, so that the requirements become useful as drivers for design and implementation decisions. The most useful requirements analysis specifies in precise detail what the user should be able to accomplish on the site and provides guidance on designing site interactions.
Some requirements analysis tasks include:
- Producing various artifacts that provide different lenses on the system and its uses to elicit more detailed requirements, such as actor tables and use cases;
- Structuring requirements into categories;
- Negotiating priorities; and
- Evaluating requirements against established criteria.
So when is it time to start designing?
If you have created wireframes to elicit requirements from your client, you are well on the way to beginning the design process – even while the final requirements are being developed. Furthermore, once you develop user flows to help derive requirements, you are ready to start designing after the steps are clearly outlined.
As your site design project continues to advance, it is necessary to institute a process to manage the change or evolution of your site or application’s requirements. After all, a changing requirement can have significant impact on the project. Managing changing requirements may require that you do the following:
- Document and evaluate the change justification
- Assess the impact of the change
- Accept, reject, or defer the change
- Implement the change if approved
During the design phase, it is essential to trace the design elements back to the requirements. Tracing requirements to each feature in the design ensures that it is indeed meeting the business and user needs and prevents the development of features for features’ sake and possibly overcomplicating the experience for users.
Requirements analysis is not sexy. It is not fun. There are no TV shows about requirements analysts. But how sexy and fun is it to go back to the drawing board after you’ve built a website that isn’t meeting the needs of your customers or achieving your business goals? Trust someone who’s done it both ways – iterating through a requirements analysis document is a LOT cheaper and more fun than iterating through generations of graphic comps, and in the process you’ll develop a deeper understanding for your clients business that will pay off over and over again.