(For more resources related to this topic, see here.)

The design process lays out what type of information or level of detail we should be seeking at a particular point in the project. It does not explain how to get the information we need. For this, we rely on various techniques. These are exercises or methodologies that help us ask the appropriate questions and then analyze the answers we receive. These techniques will help us obtain the information we require to ensure our design solutions are on target and offer value to the end user.

I have demonstrated the use of a few of these techniques in the example projects included in this article. However, since each project will require a slightly different approach, and because there are so many options available, it would be impractical to find an example that would adequately illustrate them all. There has been much written about these methodologies that is worth researching further. An experienced UX designer will know most of these and many other techniques, and should know when it is appropriate to employ them.

Commonly used, effective research techniques

Here is a very brief description of several methodologies aimed at helping us get the answers we seek during the research phase of a project. There are many others, and there will be many more developed as the software design industry continues to mature. I would recommend searching the Internet or other related books for more implementation details and examples of their usage.

Stakeholder interviews

Getting the project details from the primary stakeholders is likely the first thing we will need to do to get started on any project. The list of potential questions can be quite long. However, they usually roll up under one of the following primary questions:

• 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?
• What technology will be used? (Are there any limitations to consider?)
• Why would the public use your software or site over another?
• What content will be 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 features or complexities are hampering or otherwise negatively affecting the existing user experience?
• What additional features would the user or publisher find helpful in the next version of the product?

Design tenet scorecard

Design tenets are a list of the primary design attributes or qualities that are valued by the company or client we are working with. These attributes can describe the quality of interaction, visual style, tone of the text-based content, or even qualities that are a bit more technical in nature. Simply put, they can be anything that we would like to see represented in every interface we create.

Here is an example scorecard:

When there is misalignment on the vision or execution of a product or interface, it can be extremely helpful to put these tenets in the form of a scorecard. We then use this to grade the interface we have created against each design tenet. More often than not, one or more of the design tenets will have been neglected or entirely absent from the interface. Including this examination in our design reviews can help turn a general sense of dissatisfaction with a particular design solution into a focused discussion about specific attributes that need to be improved.

This example scorecard is one that I recently created and used with a client. I managed to get everyone involved with the product development in the same room to quickly brainstorm what the company’s design values were. Together, we defined seven design tenets or attributes that were desired in every interface we created. The idea being that if each of these values were adequately represented, we would have a higher likelihood of obtaining the company’s goals. We would have a higher likelihood of producing a product that successfully gave the customer what they needed.

I realize that this might seem to be of little value. After all, the tenets we have listed are all things that we should be striving for all of the time. However, each company will have a unique set of design attributes that they value above all others. There’s a very good chance that they will not match our own personal values. So, it is important to understand what they are from the start so we can deliver a solution that matches their expectations. If we don’t understand their values, we will design with our own values in mind. That doesn’t always satisfy the client.

Understanding the client’s values may also help us understand where we need to educate them regarding the possible negative effects their particular values could have on the experience.

For instance, let’s say our client says they really appreciate new cutting edge interfaces. They like inventing new ways of solving problems with their software. They also say that they like clean interfaces that are not bogged down with a lot of help content or explanations. In this scenario, we can point to a potential conflict that might arise with this combination of values. We can explain that without some sort of tutorial content for this new interface, we may find we have a lot of users who just don’t understand how the product is intended to work.

The example scorecard I have included here offered significant value during the wireframing process of the project I was working on. The project started out fine, but I started to receive requests from one team member who thought the interface should be less guided and much more freeform. His desire for less navigation and guidance conflicted with the previously documented design tenet that stated that the product should include an “obvious task flow”.

Utilizing the scorecard, I was able to pinpoint where his requests were conflicting with the design attributes established by the team. It helped explain the logic of the design decisions I had made. And, it put the onus on him to justify his request with the knowledge that it was out of alignment with the team’s prescribed values. In the end, it saved us a lot of time and effort. We were better able to focus on attributes of value and avoid going in directions that ran counter to those values.

Competitive analysis

Examining similar applications, sites, or products is a reliable way to quickly determine how much work is needed to compete in the existing marketplace. This exercise entails crawling through each product to examine and document the following:

• Product features of value
• Each product’s target market
• What they do right and where they fail
• New ideas and features that will help offer a better experience

Creating a summary of this research will help us create a plan to meet or exceed the competition. Reviewing the results of this research with the team and following up the review with a brainstorming session is a very effective way to kick-start some new ideas.

Though our ultimate plan is to create something new that completely revolutionizes the marketplace, we often have to start by getting a simple v1 product into the marketplace. This is commonly referred to as the MVP or Minimum Viable Product. This means the product contains only those features that are essential for it to function in its most basic form.

It can be easy to get caught up in the fervor to design something that beats out the competition with our initial release. There are times when this can be done. However, it is often smarter to promote a feature roadmap that plans out the evolution of our product through multiple versioned releases.

As designers, we will likely need to help define how the experience will evolve through these multiple releases. We’ll want to ensure that features are released in an order that will make sense to the user, and will always maintain the usability and integrity of the product.

Personas and user profiles

Personas are invented avatars that represent a certain segment of our end users. Using personas during the design process is a very common means of gaining an understanding of what typical customers or users look like. They do an amazing job of helping the team focus their efforts on what a particular user might need. Without them, it’s easy to unknowingly have the team examine the interface from the point of view of different users. This can cause disagreement regarding what a particular interface needs to include to appropriately serve its end user.

This is an easy trap to fall into. Several years ago, I found myself in this situation. I was presenting some new product designs with a co-worker. The product was addressing some very complex task flows that were not easy for a novice user to understand. A disagreement sprung up about how we were handling some of the details in the experience. After a couple of hours going back and forth about why the interface succeeded or failed, we finally figured out that we were thinking of two entirely different users. My teammate was looking at the designs through the eyes of an admin or expert user. I was attempting to design with the inexperienced user in mind.

Once I understood the point of view through which he was examining the interface, I was able to adequately address his concerns by showing him the admin task flow we had previously created. The user he had in mind was actually never going to see the interface we had been reviewing.

This was a costly misunderstanding that caused frustration and wasted a lot of time. Had we been using our persona’s names during our conversation, it would’ve become obvious that we were thinking about two entirely different user profiles.

Creating personas

The process of creating personas starts with researching what types of users are expected to use the application or site you are creating. A quick brainstorming session with the team should be enough to get a list and description of these user types. As we examine the potential users in our list, it’s common to find that we have many user types that are very similar. We’ll want to consolidate those down to a number that is easy to remember by creating a representative for multiple user types.

Here’s an example of what this might look like. As we can see from the following example, our list of potential users is too long to be useful. 18 different user types are far too many to remember. We really need to narrow this down to something more manageable. I can’t really give an ideal number of personas to develop. It will depend largely on the product. However, I would say it is common to have somewhere between three to six different personas.

Summary

In this article, we have covered basic concepts of research techniques that help us to obtain the information which is required to design applications and offer valuable services to the end users.

Resources for Article:

Further resources on this subject:

• Axure RP 6 Prototyping Essentials: Advanced Interactions [Article]
• Organizing your Balsamiq files [Article]
• Ten IPython essentials [Article]