Alignment

Assuming that the entire team is in agreement about how the project is defined and what the goals are is entirely common. But typically, people have different understandings of the project, and if left uncorrected, the teammates will each head in a different direction. Alignment ensures that the team is moving in the same direction and that the design team can get the background it needs to run in the right direction.

As a designer, you can facilitate alignment through some prep work and a workshop with the key stakeholders on your project. Get the right people in the room to define the goal of the project as a team and determine what you want the impact to be. This alone will go a long way in getting your team on the same page.

Working in Iterative Sprints

After aligning with stakeholders, our teams work in one- to three-week design sprints, concepting ideas for both the larger service experience and the individual touchpoints, building quick prototypes and testing them with actual users. This process allows us to move quickly, keeps the team aligned, and ensures our work will be usable and valuable to users. Because the process is iterative, it’s okay to be wrong—you can make corrections in the next round. It’s also alright if you don’t know everything about the users, as you can make your best guess and use your hypothesis to learn more about the users when you test your prototype. Before each sprint, make sure you clearly define the goals of the sprint, what you’re trying to achieve, and what success looks like.

Concepting

There are ample existing resources about how to run a good brainstorming meeting. Think wide, push boundaries, and generate enough ideas to provide a plentitude of concepts to work with. Diverging ensures that the team is thinking through the full breadth of what’s possible.

During concepting, bring in members from across the team and outside of design whenever possible. By preparing prompts and thought starters based on what you’re trying to accomplish during the sprint, you can facilitate the creation of a large number of diverse ideas as well as understand the underlying desires of the extended team.

Even if you haven’t been able to learn from users yet, it’s okay to start hypothesizing and generating initial ideas, as long as you identify them as hypotheses, and you’re open to them being wrong. The iterative process makes it okay to be wrong, as there are going to be opportunities to correct along the way.

Prototyping

The value of prototyping cannot be understated. Prototyping brings form to the intangible, opens up the process to enable collaboration across disciplines, and moves your project forward.

During each sprint, we review what we need to accomplish, take a look at what we know, what we need to learn, and create prototypes to answer outstanding questions. Many of the prototypes we make start out rough and scrappy. For example, pieces of paper without interfaces, but single words that represent potential features to start conversations with people about what their lives are like and what features they value. With each round of concepting, prototyping, and testing, our prototypes get more refined. We usually sketch out interfaces and load them onto a tablet to gauge initial reactions to features and interactions. For concepts that require a more unique form, we use anything from foam core models to additive printing to create objects or spaces.

Figure 5-2. We used scrap paper and a sorting exercise to figure out which features of LinkNYC were going to be valued and therefore worth building, and which features we could deprioritize

Prototypes not only set us up for testing with users; they are also great discussion points for the extended team by giving them a tangible thing to react to. It also forces us to be realistic about what’s possible from the beginning of our project and ensures that the entire team has the end goal in sight.

Testing

At its simplest, testing means taking your assumptions to the people who are meant to use your solution. Testing ensures that what you plan to build will be valuable to people, that the interactions and interfaces are usable, and that experience enables your intended idea.

Figure 5-3. Months before the hardware for the first Link was built, we were able to test interfaces with people using rough prototypes. Here you see us testing a very early version of the phone dialing interface with a tablet running a quick interactive interface, taped onto a foam core mockup of the physical structure of Link.

Most of the time, we have one-on-one conversations, either with recruited respondents or by conducting impromptu intercept interviews in the context of our solutions. For example, with the MTA we conducted testing in subway stations. We start out our user testing with a conversation about who they are, and what their lives are like to get context about their lives outside of the narrow portion we are focusing on. Next, we dive into questions about their experience relating to our project and present prototypes. The questions we ask vary greatly depending on what we’re trying to learn. We use card sorts to understand people’s values, and test interactive prototypes and gauge people’s reactions to know if it’s truly something that they’d appreciate and use if implemented. Later on in the project, we do light usability testing with interactive prototypes, first as wireframes, and then later as fully designed works like/looks like prototypes. Many times we create prototypes that aren’t actually intended to be implemented, but serve as tools to answer specific questions.

Repeat to Move Forward

Coming out of testing, you should have a better understanding of what’s resonating with users and what’s not. Test data gathered can serve as a baseline for future testing rounds and help inform business model projects. Combining this with feedback from your extended team about what’s technically and politically feasible, you can push forward. The benefit of conducting an iterative design process before development begins is to work through many of the user assumptions, kinks, and challenges early on, prior to large development teams focusing on coding. This helps to reduce the risk of developers working on code that will be thrown away.

The next challenge is to combine valuable concepts into reliable and systemic solutions. We balance the iterative process by defining interaction and visual principles and high-level specifications that will provide ongoing direction to teams.

This iterative process continues beyond implementation. After a product is launched, you will continue to learn how people are using your solution and continuously implement updates to make your product even better. Understanding which features are used most can give you a better sense of what aspects of the project the public values and can help you figure out where to focus your efforts.

This process of iterative concepting, prototyping, and testing to inform development efforts provides the insight and metrics needed to build the support, approvals, and investment for the next phase. As many assignments are not isolated features or products but rather more complex service experiences, this approach can be followed by additional teams working in parallel to build complementary touchpoints that come together to form a holistic experience comprised of many features, products, services, spaces, and cities. Once individual experiences come together, designers can use the same methods of testing and adapting to further refine the system.