Defining an Interaction Model: The Cornerstone of Application Design

Defining an Application’s Interaction Model

How, then, do you define an application’s interaction model? It can take months, but in the end, when stakeholders look at the model, they typically say, “Of course! I get it! It’s simple!” In this way, an interaction model is not unlike complex mathematics. You work hard to understand it—maybe for hours or even days or weeks—but then, once you finally understand how to solve a type of problem, it seems so simple that you wonder why it took so long to understand it in the first place.

At HP, defining our interaction model took us several months of very intensive work. We conducted user observations to understand how users conceptualized their goals, how they thought about objects supporting those goals, and the actions they performed on or using those objects in order to achieve their goals. On this particular project, we’re designing consumer user interfaces for mobile, tablet, and the Web, as well airline agent user interfaces for the Web and tablet. Now, I’ll tell you a little about how we crafted the interaction model for the airline agent side of the product.

When focusing on agent interactions, we recognized that each type of agent had a different primary object for which they needed to solve problems. For example, reservation agents taking calls—say to book a new flight or change an existing flight—are focused on a customer who is on the phone—or a caller who has permission to act on behalf of a customer. They need to solve problems for customers—such as booking a flight or changing a profile.

On the other hand, gate agents at an airport have a different goal, which they call closing a flight, and, thus, a different primary object on which they focus. Their supervisors measure their performance based on their ability to close flights, or get their flights away from the gate on time. Gate agents have several activities going on at the same time—all with a focus on getting a flight away from the gate on time. They need to make sure the passengers all have seats, award some upgrades, accommodate those on a waiting list either on the current or a later flight, and so on, but all of these activities are in service of closing a flight. Most of the gate agents I have observed care deeply about serving their customers—even if we don’t recognize it—but their continued employment depends on their getting flights away from the gate on time.

So, the primary object for a reservation agent is a customer, but the primary object for a gate agent is a flight. The primary object for a baggage handler or lost-baggage agent is a piece of luggage. The interaction models we crafted for these different users put the object of their primary focus front and center for them. We also give agents a summary of key information about each object, permitting agents to perform actions against their primary objects.

Once we understood the object-action relationships for these users, we spent a couple of months brainstorming various ways in which we could structure the overall product to permit these object-action relationships to take place in the most efficient, delightful way. During the brainstorming process, the team explored options, produced a set of screens for each user scenario, and looked at how well the model held together across scenarios. We did not just create simple screens. Rather, we crafted some of the most complex scenarios, with some of the most complex screens, to ensure that the interaction model supported big challenges. Sometimes, we recognized early that a model didn’t work. At other times, a model looked pretty good at first, but then we found that it wasn’t scalable.

Doing this kind of design exploration is as critical a process in getting a product right as the development itself. Although a good interaction model makes us say, “Of course—that makes sense,” coming up with a model for a complex product often takes several iterations and vigorous design debate about the pros and cons of each model.

Of course, we also had a deadline by which we had to produce our designs. In the end, it was my job as leader of the organization to buy the team the time we needed to define this model, craft wireframes, and confirm through usability testing that our model in fact met the goals we set forth for the product.

The key point I made to both senior leaders and my peers was that redefining the future of travel, designing a product that differentiates itself in the marketplace based on its user experience, is no small result. To achieve true differentiation and transform the marketplace, we needed lead time to get it right. I positioned this as a black-and-white, or binary, decision: Either we had the time to get it right, or all of the effort of hundreds of engineers, product managers, and people in other disciplines would be for naught. Make no mistake though—saying this presented a risk, calculated though it was. If I and my team could not produce something inspiring, the entire team might be at risk. In the end, I weighed the risk against the projected rewards and made the decision to go big.

I also needed to ensure that some members of the team were producing short-term deliverables to keep our road map moving forward—because business always needs to move forward. We had to find a balance and received support from our adjacent disciplines, including Product Management, Engineering, and Program Management.

However, pushing back on schedules meant that the end result had to be the creation of truly inspiring, marketable artifacts. It is my belief that the job of a UX team is to produce great work. If we produce average work, there’s really no reason to have a UX team on board. The end result had to make reluctant supporters nod their heads in support—and it did. Thus, my peers gained some significant trust from other organizations through this effort.

If we can show how an interaction model can result in breakthrough solutions, we can build the right level of support for having User Experience at the center of the strategic dialogue. This is especially the case when you’re working on consumer products—given the great examples of design in the marketplace today. But enterprise users in the IT world are also users of consumer products such as tablets and cool applications on their smartphones and on the Web. The consumerization of IT is a genuine trend that businesses need to embrace to remain competitive. Almost all of us are consumers of cool products today. People’s expectations have changed. (Just do a Web search on the “consumerization of IT.”) Figure 3 shows just one of the 110 pages that our Interaction Model document comprised. (It’s not important that you be able to read the callouts; the illustration is conceptual in nature.)

I’d like to show you more, including how we’ve tangibly instantiated this model into a set of screens, but because our product is still in development, I cannot for now. Suffice it to say that the Interaction Model document itself must market your organization’s capabilities.

Defining an Interaction Model to Meet UX Goals

Knowing whether an interaction model works requires not only usability testing, but also a very seasoned designer—one who can recognize when a model will not scale and predict what challenges users would encounter with the model. In the end, for the travel product at HP, I and my most senior design lead made the final decisions about the interaction model. Only later did our less experienced designers internalize it. But once they did, it provided a framework for their ongoing design efforts.

You cannot create an interaction model without first understanding the user experience goals for a product—allowing a team to measure the success of the model and the individual design decisions you’ve made within the model. In the case of the travel product that my team and I are designing, we established metrics around the following goals:

• discoverability—Can users quickly find the model’s primary object and understand how to perform the actions they care about? Can they use the system successfully the first time?
• learnability—How long does it take for users to internalize how to use the system competently? Even consumer products often have a slight learning curve today. For example, my company just gave me a new smartphone, and it took me a bit of exploration to understand how to use all of its cool features—not to mention how to avoid draining the battery in three hours.
• user efficiency and productivity—Once users are competent using the system, how easy is it for them to perform common or repetitive tasks? Can they perform bulk actions all at once, or do they have to perform dozens or even hundreds of separate actions?
• system response time—Once users take an action, how long does the system take to respond? In a production environment, user efficiency and system response time combine to define the total task time. Designers have a responsibility to understand the expectations and constraints on system response time and design a product that meets or exceeds those expectations.
• delight—How cool does the product feel to users? Do users like using it? How much do they like it—especially in comparison to other products? I set up a Customer Listening organization, and we’ll be systemically gathering this type of data—along with Net Promoter Score data—to drive the top five to seven product improvements each quarter.

Each organization needs to set specific targets against their metrics, but these have given us the insights we need regarding how we’re doing from the standpoint of product design. If we were measuring engagement, we would use different metrics.

Once a design team has defined an interaction model, they can—and, in my opinion, should—craft a framework that supports specific designs. A framework defines reusable design patterns and instantiates them into reusable design and development components that subsequently enable designers and developers to rapidly produce additional parts of the design. In my case, we have a team of a few designers and a few front-end developers working together to produce framework releases in a regular cadence. The framework includes all of the design patterns that multiple teams need, including title bars, accordion widgets, table formats, date pickers, and hundreds of other user interface elements.

Conclusion

Defining an interaction model is a foundational requirement for a digital system. By first defining interaction models for our products, we crafted a product vision that our peers, senior leaders, designers, stakeholders, and users could understand and rally around. When I showed our interaction model and application simulations to customers back in November, they wanted to move directly to talking about product schedules. Their question? When can I have this product? If you have any questions about creating interaction models, give me a shout!