The beginning of every new project is exciting. But the danger of getting caught up in the excitement of a new project is overlooking the discovery stage. Too often development companies and their customers rush to wireframing and development without taking the time to fully communicate the vision and establish the foundation. Sure, UX research will extend your deadlines. Yes, it may cost a little more to include a UX designer on the team. But if you skip or skim over this part of the process, or go with your own assumptions, you may end up with serious issues later on. Ignoring these steps can ultimately cost more down the road in time spent changing scope in development, more time in development and testing, and more time spent on the phone with upset or confused users. Plus, consider the cost of your software not aligning with your users’ goals and needs. Users are quick to abandon something confusing or unhelpful, so usability always pays off.

Over our last 15 years in business, we’ve learned that investing in a discovery phase simplifies the entire process from design to launch. At Rocket Jones, we call the discovery phase “Stage 1: Explore + Imagine.”  It’s the first stage in our 4-Stage Process for building custom software. But even if you’re not interested in building custom software, these four steps will help any project you’re working on get off to a good start.

1. Review Existing Data

At Rocket Jones, this is the very first item on our list. We collect anything our customers have created while preparing for the project, or that’s related to their relevant operations. Often this includes:

• Listening to the customer and taking lots of notes in our meetings
• Vision documents
• Screenshots of their existing tools or software
• Lists of things they hate about the current process
• Envy lists of their competitor’s software
• Excel sheets of data that needs to be put in the cloud
• Project outline documents
• Hard copy forms that need to be automated
• Lists of products.

Collecting and analyzing existing data before going any farther does several things. First, it ensures complete communication. Often our customers have vast resources of information about themselves, but they may be too close to see its relevancy to us. But in order to see clearly where we need to go, we ask specifically for all the information we can get. Second, it communicates the need for software more clearly than a verbal conversation can. We absolutely value sitting down with a client and listening to what they need. But when a client says they need a tool that automates a hard copy form, we may form an incorrect assumption about that process. However, if they give us the hard copy form each employee fills out, which is then handed to a secretary who types it into an Excel sheet to calculate it, then writes the answer on another form, and then files it in a drawer, suddenly we see the need more clearly.

2. Gather Information and Conduct Interviews

Developing software can never, ever happen in a vacuum. Real, live people are part of the project, and those real, live people have opinions and habits that are important to consider. We discover those opinions by conducting stakeholder interviews. Stakeholders can vary from the C suite execs to the general manager. Anyone who is involved in the project or who will use the software needs to be on the list. These interviews are typically short, fairly informal, and sometimes they are done just by emailing a questionnaire. Interviews can be done with any or all of these people:

• IT staff
• Marketing staff
• Subject matter experts
• Sales
• Executives
• Managers
• Customer service
• Anyone else suggested by the project team

Talking to all the stakeholders does a few important things. First, it establishes the goals for the project. If our main contact is with the head of the IT department, he or she may have very different end goals than the COO, and likewise, the head of customer service. Even a 15 minute conversation with a few different people can round out our understanding of the big-picture goal for the project. Second, talking to stakeholders creates buy-in. When all the key people feel that their opinions and needs have been heard, they will be more supportive of the project. Communicating their goals and expectations for the software’s performance boosts their confidence in the end results.

3. User Experience Research

Once we have good idea of the stakeholders’ goals, it’s time to move to the end users. Depending on the type of project, sometimes there will be overlap between the stakeholders and the end users. For example, if the web application will have several administrator access accounts, those administrators may be managers that we interviewed as stakeholders. BUT, we still include them as end users and observe them in field visits. Why? Because stakeholder interviews are about communicating goals, and field visits are about observing behavior.

A field visit consists of our UX researcher visiting the user’s context (usually their place of work, for business web applications) and spending about 30 minutes observing the work flow and environment. Often the researcher will take a few photos of the work space (with permission), and an audio recorder is used as the person being observed describes the process he or she is performing. Field visits are key in developing a custom system, because ultimately, the software must work within the context. Observing the surroundings, habits, distractions, and process of the people who will use the software helps our design and development teams make informed decisions. And informed decisions lead to usable software, which leads to happier users.

4. Personas and User Stories

After we visit the customer’s workplace for field visits, all the observations and data we collected are analyzed. We identify key characteristics and group our observations accordingly. Each group of similar users becomes a persona, which is a fictional representative of the group. A persona is treated like a real person, and we give it a name, a bio, a quote, and a story.

Personas and their stories guide the development in significant ways that can be costly to skip. Designing is just a series of decisions, but decisions are better when based on data rather than assumptions. Because personas are based on actual observations and research, they guide our decision-making process. Holding each step of the project accountable to the end user makes an enormous difference in the usability of the final product. Skipping this step could mean that your software makes perfect sense to you (or the developers), but is confusing to the people who use it every day. We want to make software that delights the people who interact with it daily.

Setting a Strong Foundation

The goal of this whole process is creating useful software. “Useful” may seem like a low bar to reach for, but how often does software miss this critical mark? Think about the last time you got frustrated with software. Was it because you spent time searching for something that should have been obvious? Was it because it didn’t do what you needed it to? We’re not big fans of software like that, so that’s why we put so much effort into understanding our customer and the users. All this information gathering and analysis lays the foundation for an amazing product. And although it may seem painstaking, ultimately it saves you money and time. Whether it’s us spending less time developing and testing, or your employees being more productive, or your customers telling friends how easy your site is to use, Stage 1 is well worth the cost.

In part two of this four-part series, I’ll teach you about mental models and wireframing. Don’t miss it!