Designing for Differences: Lessons from Going Outside Silicon Valley
Having only worked at a large Silicon Valley company before Opendoor, I didn’t realize how much I took for granted. That even the language that I spoke day to day was steeped in Product-Speak. (“How do these eng stories contribute toward our KPIs? Should we take this offline so we can re-prioritize this sprint?”)
This reminded me of a story told to me by a friend who happens to be a family physician. When patients tell him they have “vertigo,” he asks them:
- Do you feel like you’re looking down from a great height?
- Do you feel lightheaded?
- Or, do you feel like the room is spinning?
He asks these questions because while “vertigo” can colloquially mean many things, the medical definition is more precise. To disambiguate, he asks questions, which helps him figure out if the patient is truly suffering from vertigo. (In case you were wondering, the feeling of looking down from a great height suggests dehydration, lightheadedness suggests pre-syncope, and the room spinning suggests true vertigo, which is an imbalance in your inner ear.)
Similarly, people who don’t make software day to day don’t have the vocabulary to describe what they want out of the software they use. Coming from a larger company, I was used to having a team of researchers translate user wants and needs for me. And because I worked with a product team every day, I lived in a bubble in which I had the luxury of assuming what we talked about and how we talked about them were commonly understood.
Introducing Sherlock
I work at Opendoor as a product designer on operational tools. We create tools that give our operators superpowers by answering questions like these:
- How do you accurately value a home sight unseen?
- How do you enable an operator to manage dozens of active renovations at a time in a 50-mile radius?
- How do you ensure the security and cleanliness of thousands of listed homes across ten cities?
This work involves working with operators every day, and because of this, I can’t assume fluency in Product-Speak with my stakeholders. I learned this the hard way during the development of Sherlock. (Sherlock is an app that operators use to assess the quality and condition of a home in person before we purchase it.) We faced many challenges while building the app and learned many hard lessons. Here’s just one of them.
Our Mistake: Expecting stakeholders to know Product-Speak.
During the product development process, I posted video recordings of prototypes on Slack and expected operators to understand it. In doing so, I made the following mistakes:
1. Not providing context
I didn’t tell the operators what problem the feature was solving and why it was important. I didn’t talk them through the set of considerations and tradeoffs I made to get to this prototype. Because I was used to only working with people fluent in Product-Speak, I thought the unspoken assumptions were obvious. Instead of understanding our different perspectives and trying to bridge the gap, I was like a doctor who expects their patients to be able to diagnose, verify, and treat their own ailments.
2. Not asking clarifying questions
Patients can use the same words to describe different conditions, or different words to describe the same condition. To help disambiguate, a doctor can ask clarifying questions to get at the true underlying issue. As a designer, I could have done that, too, but I didn’t — I didn’t show them multiple options to compare and contrast to help them think through and verbalize what they’re experiencing. What I did was show one option. I assumed that I fully understood their needs and they saw my one option as the only possible option. I had made the wrong call, but they didn’t have the product experience to push back.
3. Not meeting them where they are
Sherlock was intended for operators who were out in the field most of the time. As a result, they were looking at a video on a Slack channel on their phone while driving from one home to another. It was effectively like a doctor trying to communicate with their patients through morse code. How can they make sense of something when they’re so removed from seeing it in context?
Because of these mistakes, operator feedback would come in the form of “this looks great!” or silence. We took both of these to mean that we were on the right path, when in reality we were not. This was especially apparent for the feature I worked on in the screenshot above. We got some massive fundamental things wrong with it and we only realized it after spending weeks discussing, designing, and shipping it. Like how we can’t differentiate “vertigo” from true vertigo, how could we expect others to differentiate between good product decisions and bad?
The Lesson: Help stakeholders develop vocabulary to describe what they want.
After the first full release of the app, we made a few changes to our process. We’ve incorporated these changes to the rest of our products for operational tools as well.
1. Facilitate product discussions
We set up a weekly meeting between the product team and operations team to get feedback. During this meeting, we show multiple options for each feature, talk through the tradeoffs for each of them, then have an open discussion about which direction to pursue. Instead of taking their self-reported symptoms at face value, we take time to ask operators clarifying questions about their pain points. It’s also an opportunity for operators to teach us their operational vocabulary, how they think about their work and their thought processes.
2. Meet them where they are
At least one member of the product team (engineering, PM, design) flies out once per month to meet operators in their city in person. While they’re there, they spend time going through latest product updates and shadowing them to get a sense of what their pain points are. Like how a doctor and patient can have a more meaningful conversation face to face, we’ve found that having product discussions in situ (at a home in renovation, for example) has been tremendously helpful.
3. Build trust with small gestures
Making your stakeholders feel heard goes a long way toward them giving you candid feedback. The two things above (weekly remote check-ins, monthly in-person chats) help with this, but the little things are just as important, too. For us, that means things like answering support tickets quickly, responding to every feature suggestion, and making sure to use more human language (“screen” instead of “view”, “refreshing” instead of “re-fetching data”). With having a trusting relationship, operators feel more comfortable with giving feedback, which in turn helps us build better tools for them.
In retrospect, these lessons seem so painfully obvious that it feels pointless to write them down. At the same time, these mistakes were hard to spot because they were so fundamental. We simply thought we were misaligned because we disagreed, but it wasn’t that — it was that we weren’t even speaking the same language to begin with.
Once we recognized this, we were able to forge a more meaningful and productive relationship. Like a patient learning to translate their experience into words, a doctor learning to translate the patient’s words into hypotheses then in turn ask for more information, we learned to create a bridge between our own two worlds and speak each other’s language.
One of my favourite parts of working on operational tools is that it forces me out of the tech bubble. I get to work with and build things for people who are different from me, and it makes me realize how much is out there that I’m missing. Operators may not know about the latest APIs available as part of the iOS 12 developer beta, but they can give me the most detailed rationale of why a certain home should be valued at $250k rather than $240k.
If these design challenges sound interesting to you (and if designing for those unlike you does as well), please check out our jobs page! We’re always hiring for great designers, researchers, and writers.
If you have any questions, please feel free to contact me at billy [at] opendoor [dot] com or on Twitter (@billyroh).
