It may surprise some that the first step of designing is not designing at all, but rather asking questions.
The pressure to start designing as soon as possible is almost always in effect. Mature software designers, developers, and management staff know that research time is a necessary part of the process. In fact, it is the way to kick off the process. However, there are situations when even seasoned professionals forget the importance of this first step. They get caught up in the fervor to get the product out the door and succumb to the pressure of cutting corners by skimping on research that is required to establish a solid informational foundation to start building our software. It is essential to start off by getting answers to several key questions.
These questions are as follows:
Who is going to use this software or site?
What tasks does the user wish to accomplish?
What does the maker of the software or site wish to accomplish? (Not always the same as the preceding question)
What technology will be used? (Are there any limitations to consider?)
Why would the public use your software or site over another?
What is the content needed to support the user in accomplishing their goals?
If we are redesigning an existing site or application, we will likely find it valuable to seek answers to these additional questions:
What existing features or complexities are hampering or otherwise negatively affecting the user experience?
What additional features would the user or publisher find helpful in the next version of the product?
Finding the answers to this list of questions may require the application of several research techniques. Our research efforts can take the form of competitive analysis to ensure our product has the right features or of simply interviewing those who know who the expected end users will be.
Some of the most commonly used and effective research techniques are mentioned as follows (see Chapter 4, Research Techniques for more details):
Card sorting
Focus groups
User surveys
Stakeholder interviews
Design tenets
Personas and user profiles
Contextual inquiry
Heuristic evaluations
Competitive analysis
The quality and quantity of research we complete will have a significant impact on how successfully we give the user what they need. It will also influence the amount of time it takes to complete our designs.
To illustrate how constant an issue this is, I have included the following two graphics, which I created about 12 or 13 years ago. Though they were aimed at addressing the issues I was facing with a specific team, it's still relevant and worth explaining to any team or client you will work with:
This first chart shows how the process should work. Most, if not all of the research, has been completed up front, that is, before the design work begins. It means a fairly predictable design cycle. The designer knows all of the problems he or she needs to solve. The review of the 1st DESIGN ROUND usually yields some needed refinements, but not more than that. Time estimates are met, and everyone is happy.
This second graphic shows how things can go wrong and how due dates slip. It's been my experience that some clients or stakeholders just cannot bring themselves to think through all of the requirements and features needed to start a project. We ask them all the necessary questions and they will give some of the details. However, they are just unable to formulate answers to the questions we are asking without seeing our initial round of designs first. Once they see our attempt to wrangle the ambiguity into submission with some sketches or wireframes, they become a veritable fount of information.
When our research attempts yield very little, we are likely to involve the decision maker in the creation of some sketching sessions. So, make these sketches quick, make them messy, but make sure the client is involved in the process. If we attempt to complete a formal round of designs with incomplete information, we are likely to realize that we've just wasted our time.
There is so much that needs to be considered when designing software. When someone is late to introduce new requirements or features in the process, it can feel like the whole thing needs to be thrown out and started over. We can spare ourselves some of the agony by ensuring that the research has been thoroughly pursued and documented. Then, we present the results to the client and team to get their approval and buy in. Ensuring everyone is on the same page from the start will hopefully limit the number of surprises and changes that come in later. And, when they do, it will be with the understanding that these requests are altering the existing expectations. This way, scheduling changes can be discussed as a natural consequence.
Some designers may find agile development methodologies to be difficult to work with while designing larger comprehensive solutions. Agile is an iterative development methodology that attempts to get a development team to produce faster by reducing the amount of documentation and other overhead, historically gathered before development could begin. It is a reaction to the old waterfall methodology, which traditionally had the product mostly or entirely designed and thought out before going into production. This method required a lot of discussion and documentation that slowed production down significantly. Though the waterfall methodology is still in use, it has lost favor due to its slower pace of delivery.
With smaller projects, there shouldn't be too much of a problem getting our research figured out at the start. However, larger and more complex projects can be a challenge. Designing in an agile environment generally requires getting a good head start to get our research and design deliverables completed before the development team needs it. The farther ahead we are, the more time we will have to vet and optimize our work before delivering it to the development team.
To summarize, the quality and quantity of our research will have a direct and relational impact on the quality of the solution we create. Rushing to design a solution without key details, such as who our audience is or what features they might need, will mean a lot of guesswork that may or may not succeed. I always like to think of it as if you want it bad, you get it bad.
Regardless of the methodology we are working with, it is essential that we include research time into our development and design plan.