Meet the Design Context Ladder

Several years ago, UX masters Vikram Bapat, George Engelbeck, and I developed this very useful model for progressing through product design. Meet the design context ladder. Here’s the story of how it came about plus some great ways to use it. It’s simplicity belies its power.

The Backstory

Vikram and George worked on the Microsoft Developer UX team, and I was a PM bringing them in work with the Parallel Computer Platform engineers. It sometimes takes a while to introduce anyone new to a team, but they were awesome, and the engineering teams quickly learned that.

For one project, we focused on democratizing GPGPU development. (GP GPU = General Purpose Graphical Processing Units) Today, GPGPUs are the powerful math processors that make Machine Learning possible. At the time, the developers who could program GPGPUs were very hard to find and their time was expensive, and the developers who would eventually become our users did not understand even the basics. This made it a problem in finding users to validate the designs.

In fact the debugger team had only found two (2!) qualified users in the first year. So, the team pulled us in to help. We decided to go to the GPU tech conference to look for them. We reached out to the conference owners, and they were eager to partner with us. Now it was on, and the conference was a few weeks away. Our goal: to more than double the previous year by talking to 5 users.

With our partner’s help, we had 13 sign-ups in the first hour. In the first day, we made it through 3 full design iterations. That afternoon, we called HQ and to fly in more team members for support. In the conference, we had so many qualified conversations, that we looped through 10 design iterations. We defined and validated all the major elements of the GPGPU debugging experience in under a week.

Major side lesson: If you have a hard-to-find user base, find their conference and go there. It’s a slam dunk. We’ve done this many times since, and it’s always been effective if we’re well prepared.

So, how do you prepare well when there’s so much complexity and so little time? Trying to keep so many people on the same page, know what to focus on, and track maturity of a design is difficult. We had a secret weapon: the design context ladder.

Introducing the Ladder

We first created the design context ladder to track release readiness across our organization, and it grew to be effective in so many ways. From the bottom rung to the top, we had Concept > Scenario > Experience > User Model > Interaction Model > Interface > Fit and Finish. When working on the ladder, you move up one rung at a time, validating that rung before moving on. At any step, you can get clarity and make changes the next rung up or down, but be careful about operating more than one rung away.

This ladder makes an excellent tool for framing. Our organization used this tool in the following ways:

1. Tracking progress — Understanding where we are in the process, how far we’ve come, and how far we have to go. It’s a good indicator of status, which leads to:

2. Reporting status — Our group regularly demoed to each other and leadership. Since we had several projects, each on different release cycles and timing, this ladder became a marker for us to understand the context of each team presenting. We’d say things like, “We’re currently at the Experience rung. Our Scenario is ____. These are the current things we’re trying to learn to move to the User Model rung:.”

3. Selecting study methods– The UX field has many methods to validate concepts through user research. Each of these are better for certain jobs than others, so we organized our methods and protocols by the rungs on the ladder. This was a very effective way to get a new team on the page. We’d ask, “what are you trying to learn?” and “what ladder of the rung are you in?” Based on these answers, we could quickly index to the right mechanism. It also helped us redirect UX team requests. For example, we’d hear, “we need a cognitive walk through,” and we could point to the chart and say, “actually, it would be more effective to run an open book test study here.”

4. Grounding team discussions — This also helped work through arguments based on miscommunication. A light bulb went off the first time I walked up to the whiteboard, drew the ladder and said, “Joe is trying to have discussion about the User Model layer, while other people aren’t ready to have the Concept layer finalized, yet.” This provided so much clarity that we all took a step back to have that conversation. It became regular grounding for the team from there-after to think about that, opening the door for focusing statement like: “That could be a great idea, but it’s too early to work on Fit n Finish.” Or, “Do you mean to reopen the Scenario definition?”

5. Interpreting user input — At one point, the GPGPU debugger’s Active thread indicator was a beveled circle around a right-pointing triangle. It looked like a play button for a stereo. During the study, our users kept trying to click on it. The initial reaction was to treat this as a problem with the design of the icon. So, the team started working on making it look flatter and less like a button. Then we realized: “Hey, we’re treating this as fit-n-finish level feedback, but it’s possible to interpret this as feedback at any level of the hierarchy.” In fact, at the concept level, it could be that people wanted the ability to play (and un-pause) specific GPGPU threads and watch them run through the system. Based on this, we adjusted our interviewing approach to also learn which rung of the ladder to address.

6. Making robust decisions — We eventually decided on a light rule that helped us stabilize decisions. Would take input up a rung or down a rung from our current level. However, we declared it would require significant rethinking to revisit something lower than that, and we’d generally not look for input any higher. In practice, this meant that at the Experience level, we would consider tweaks to the Scenario or User Model, too. Though Concept was essentially off limits without a major decision meeting. (Looking back on this now, dropping two or more rungs down the ladder is essentially a pivot in Lean Startup parlance.) Also, we’d avoid collecting input higher up the ladder like Interactions, Interface, and Fit n Finish. This helped us focus.

In Conclusion

This is a powerful tool for focusing conversations and building shared understanding on a team. Two of its main features are that it’s adaptable and it provides the power of context.

Adaptability

This is a powerful tool that I still use today. Some situations require different rungs, but the framework is very flexible to that. On that team, we actually had two of these, one for GUIs and another for APIs, but I always preferred this converged model (in the private of my own mind).

The Power of Terms

One key insight behind this is the general notion of terms and language. Largely, I believe that humans are good at reasoning or communicating one or two clicks below where they have terms to describe things. Beyond that, it’s just too difficult to think and certainly to communicate clearly. Models and terms like this are useful to improving the shared understanding of a team. They help make the abstract concrete enough that we can reason and discuss down a few more clicks.

I hope this helps you in your work. It enabled us to push through crazy deadlines and a lot of work in record time with everyone on the same page. I hope it helps you do epic things.

* * *

Please comment if you find this useful.  We’re all in this together.