The User Experience Transformation: Finding the “Why” Behind Features
So, you want to build a new feature. Excellent. Now, tell me why.
Rocket, like thousands of software companies, has historically had a wonderfully engineering-driven culture. We make products for engineers, by engineers, and we’ve got a pretty great track record of figuring out how to build features well for our customers.
There’s an important detail there — for our customers. People don’t often say, “I want a widget called ‘a’ that does ‘b.’” That’s a feature. What they say instead is, “I want to be able to do ‘x,’ because….” That’s the “why.”
As Director of User Experience, leading design and information development for the z Systems Business Unit, translating “why” to “what” is what my team does all day. We spend time sketching, iterating, prototyping, and testing all the possible ways that a person’s “why” statement could be expressed and solved in interfaces, workflows, micro-interactions, and assistive content.
Toyota famously used a problem-solving technique for root-cause analysis called the “Five Whys.” The strategy is exactly as it suggests. If you dig deep and ask “why” five times, you’ll likely get much closer to understanding the real problem than if you simply accepted the first answer. Other technology companies use a framework called “Jobs to Be Done.” This reflects the notion that users hire a product to perform a specific service for what they really want to accomplish. Agile, an iterative software development methodology practiced by every product team at Rocket, uses “user stories” to scope work to end goals from the user’s perspective.
All of these methods work to change the conversation inside of engineering organizations from “how can we build feature ‘x’ the fastest” to “why does this matter to our end users and therefore what solution is best for our customers’ long term success?” For example, “put a chart on this screen” (a feature) might get you very different results than, “I want to be able to give my CIO quick visibility into my organization’s systems, because he doesn’t have time to spend more than three minutes in this product. He is also colorblind and dislikes my DIY PowerPoint reports because they don’t represent real-time information.” Ultimately, reframing the question helps us to ensure that we’re doing what’s right for our users, avoid limiting our thinking with short-term fixes, and build higher quality products in the process.
In his December 2019 letter Andy Youniss outlined our new Chapter 4 vision of Legacy Powers Legendary. We’ve got a 30-year legacy of powerful product features built by engineers, for engineers. We plan on being around for the next 30 years, too. So, in building the legendary experiences of tomorrow, we’re digging a little deeper and changing the conversation to be even more customer-centric and a little more design-led. This arms us with the “why” to better understand how we can find the right long-term solutions to the problems that matter most.
Feel free to continue asking us for features. We’ll probably follow up by asking you why.