(Editor’s note: This is a guest post from Daniel Ritzenthaler, Senior Product Designer at Iora Health.)
As the complexity of our product grows we can’t keep interacting with it, and its users, in the same way and expect a similar response. Seems obvious from the outside looking in. Unfortunately, from the inside, when life is hectic and things seem to be working, we tend to miss opportunities to reflect on what we could do better.
If it ain’t broke, don’t fix it.
During the early stages of a company (or an idea) we can look at the world with fresh eyes. We can talk to domain experts (or be the domain experts) without the baggage of an existing product. We don’t have previously made decisions constraining our point of view. We can more easily separate the wheat from the chaff.
Under these conditions we can look into the future and visualize what needs to exist. We can, at least a little, predict the future with a reasonable expectation of being right. After all, at this point, we’re operating in a simple system. Predictions are reasonable in simple systems.
More nuanced populations of users stabilize — each with their own agendas. Interdependencies between features of the software accumulate. Complexity grows.
Eventually, a threshold is crossed.
We’re no longer in a simple system. We’re no longer able to distinctly see cause and effect. We’re no longer able to clearly see the patterns across several different workflows for several different independently acting populations. We’re no longer able to predict the future.
We may still think we can do all of these things. We may still think we can predict the future.
But we can’t.
It’s not a lack intelligence. It’s not a lack of skill. It’s not a lack of expertise. It’s simply unreasonable to expect predictions about the future to be accurate inside a complex system.
We need to adjust.
We fly by this threshold without noticing. There isn’t a strong feedback signal when it happens. Things aren’t as easy as they used to be … but predicting the future has worked in the past. So why stop now?
We decide no adjustments need to be made.
Predictions of the future continue. Consequences become more severe. Only after several significant failures does anyone stop to consider that we just don’t know what we’re doing. That we can’t know. That we shouldn’t expect to know.
By then, though, it’s often too late.
Investing in the Future
We shouldn’t ignore the future. We just need to break our bad habits of trying to predict the future. Instead, we need to be more attentive to the present — right here and now — and spend our energy defining what about it is insufficient and how it should change.
Think progress. Not problems.
Improvements. Not solutions.
More on how to do this in a bit. But first, we need to be smart about what we improve. Improving something for the sake of improving it isn’t strategic. We should only improve something with the expectation of changing a user’s behavior.
This isn’t predicting the future. This is extrapolating. This is theory building. This is saying that if something improves, our users will stop an existing behavior or start a new behavior.
For example, in Iora Health’s software (lovingly called Chirp), physicians often write part of a patient’s medical note with the patient during their visit. Then, after business hours, they finish writing the note.
If we can reduce the time it takes to write a note, theoretically, physicians will be able to write the entire note with the patient, during the visit. They will no longer be working overtime — missing precious moments of their personal life — to write a note.
That’s a theory based on extrapolating existing behavior. Once something, or a set of things, improves enough, we should expect something else to change.
Notice how we didn’t define a problem. We didn’t specify a solution. We didn’t collect requirements. We didn’t commit to specifications.
We’re simply finding things to improve that we believe will trigger a larger behavioral change. This is how we effectively scope the work.
Also, notice how we have something tangible to compare. How valuable is it to the company for our physicians to stop writing notes in the evening?
We can debate its value. We can compare its value to other behavioral changes. This is how we effectively prioritize the work.
In short, we can invest in the future without needing to predict the future.
In practice
As great as that might sound, what’s even better is that it doesn’t require special skills to accomplish. More roles across more levels of expertise can participate. Product design and management can truly become a team activity.
Really. There’s only three things to do.
First, you need to observe how people interact with your product as realistically as possible. Don’t look for problems or solutions — just attempt to agnostically capture as many discrete activities as you can.
For example, for a physician writing a note in Chirp, he might navigate to medications to check out what they’re taking. If the scope of what I’m interested in is writing notes, checking medications would be a discrete activity within this process.
Pay attention. Shut off the analyzing part of your brain. Be quiet. Watch. Capture as many discrete activities as you can.
Second, take each discrete activity and explore what dimensions of progress makes sense. Remember, we’re not looking for a feature to make anything better. We’re trying to articulate how this activity might be better: taking less time or more time, happening more often or less often? Used under more varied circumstances or less? What should go up? What should go down? What should be amplified? What should be dampened?
For example, while writing a note, would reducing time spent checking medications be better? Probably. Writing a note can take a long time. Would checking medications less often be better? Probably not. If a physician needs to know medications, they need to know medications — don’t get in their way. Some notes don’t require checking medications. Is that variation good or bad? Should we reduce this variation? Encourage more?
Dig in. Discuss. Debate. It’s okay for progress to run along several dimensions. Be thorough.
Remember, this is still theory. The goal, for now, isn’t to be right. We’re collecting observations and attempting to find dimensions of potential progress.
A big part of this is simply giving our team the tools to ask better questions. When we talk in the abstract, it’s difficult and exhausting to ask meaningful questions. We mistakenly believe that escalating this more difficult work to people with more specialized skills or deeper experience is the way to go.
It’s not.
This typically pushes the most meaningful work further away from the user — to the people with obligations that prevent them from spending time with users. The good intentions of senior roles spending time with users deteriorate. Predictions of the future become the path of least resistance. We drift back.
Don’t do it.
Keep as much of your thinking inside your team and directly tied to observations of the user and their potential dimensions of progress. Do it together. Senior roles cramped for time: delegate.
Finally, to make sense of all these observations and their dimensions of progress, we need to find relationships between them. Specifically, which improvements could contribute to a larger behavioral change.
Intuitively, it’s easy to think and feel, for example, that writing a medical note is slow and cumbersome. That’s not a good enough reason to improve the note writing experience. There should be a handful of conceptual hooks that your team can use to understand and debate the work to be done.
- Intuition: writing medical notes takes too much time
- Compensating behavior (demonstrating the user finds the process problematic): physicians are writing notes in the evening
- Observations: eight activities seem to relate to writing notes can be improved along the dimension of time
- Expectation: once enough improvements have been made across enough activities, physicians will stop writing notes in the evening
Your team, no matter what level of experience or skill, can participate in these conversations. Ideally, much of the work to get this information is delegated to more people on your team.
Share the load. Work as a team.
Stop Trying to Predict the Future
A new feature is a conversation about the future. It’s implying that something *should* exist. Instead, we should be looking at the present and talking about how it can be better and why that matters.
When you notice you or your team’s discussions slipping into the future, stop and ask a few questions. What observations relate? What existing behaviors demonstrate disfunction? How can these observations be improved? Do we have reason to believe this improvement will help trigger a positive behavior change?
Return your attention to the present. Orient your thinking to now. How it can be better. Stop gambling. Invest.