Meeting users where they are
Design together with engagement paths
Silicon Valley works to make products as quickly as possible so that the market can decide. Capitalism is the constraint that provides feedback as to whether a solution is viable. In this technology positivist approach towards product design, technology is at the center. Product-market fit is something that happens over time, through experimentation, if it happens at all.
Many products are just slowly abandoned by users over time. Or the inverse happens and the business behind a product fails, forcing the product to abandon its users. If you build it they will come is a poor excuse for a product strategy. For a product to be successful in the world it must meet its users where they are.
“If you build it they will come” is a poor excuse for a product strategy.
Where to start
Indi Young describes how users start along the path to discovering a technology solution. For people in the world to become a user of your product, they have to connect their own context with the product context. In Look at It Another Way, Indi gives an example of someone shopping for a bike example:
The people who designed the bike talk about what the bike can do, but the rider wants to find out what she can do.
While subtle, this extra work put on the customer adds up. Starting from a user’s point-of-view can eliminate work both for the user and the business. We’ve had great success in using an approach that helps balance the equation from what engages users to what maintains the business—engagement paths.
Engagement paths — a short introduction
Engagement paths add more context and flexibility than a user-journey map. They incorporate the business goals and objectives that are important to make a product successful. Stepping through the paths that users take to achieve their goals helps teams get on the same page.
Start from who you are making this product or service for and then sketch out an engagement path with your team. Think about what they’re doing already to identify their motivations and needs. From there you can continue down the path to see if your product aligns with their model of the world. Finally, assess what business goal is satisfied by their engagement.
A shift in point-of-view
I decided to study computer science to become an engineer because I enjoyed how engineering made science and math concrete. Making something proved the models I was learning and gave them relevance. The real world served as an important constraint and helped refine my understanding of theories I learned in math and physics class. I could go out and test the implementations I had made immediately.
The fights you have when you’re trying to build a compiler or interpret a robot’s sensors are largely about creating an accurate model to facilitate the desired functionality. Collaboration in this context is about pushing back on the assumptions of your peers. You make a better model together as a group. And “better” is proven quickly. It either works or it doesn’t.
When you program, you take the point-of-view of the machine.
— Ellen Ullman “Life in Code”
Just like you can’t make good software without a solid model, you can’t make something useful just by running validation tests. There’s no compiler for design. You have to start with understanding people. Everybody says this, but very rarely do teams embrace this approach because stepping away from code feels like a risk to a company’s bottom line. When you start with understanding people you ensure that your model bridges to how they see the world. Instead of merely just building out from the point-of-view of the machine, you start with the point-of-view of a user.
In my career I went from designing and building user interfaces to design research and strategy. Instead of just making something and then waiting to see if it stuck, I decided to switch the order of operations. I don’t write production code anymore for a living. I’m having different fights now.
In a technology positivist approach towards interface design, the technology is at the center. It’s expensive to make software or hardware so instead we start with approximations of the final product.
We argue and fight about those artifacts for a while until we decide enough is enough and it’s time for implementation. Then new fights emerge where we argue about how closely the implementation matches the artifacts that we had already agreed upon, that were promised. And in all of this we’re miles from the important fights, the good fights — meeting users where they are.
Even if that doesn’t match your design process exactly, you’re probably still saving the good fights for the end. Instead of build, measure, and then learn, where finally you can gauge users’ engagement with your product — start with engagement. Come to Mule February 22nd to learn about how to use engagement paths to collaborate with your team.
