Loath to Waste Time

newsletter #33 | 20-Feb-2018

In the tech world, as well as in other industries (like science), there is an overriding push to speed up discovery. In business, the root cause is often “get ahead of the competition.” In academia, it’s “be the first to publish this.” Speed governs most of us. Exceptions exist, like in the safety community, which is filled with careful processes like pre-flight checklists or routine maintenance. But the rest of us pretty much bow to speed. And so digital products aren’t always thought all the way through. Science experiments get published that no one can replicate. Yet, over the years, these very things accumulate polish, from repeated, randomly-driven attention. Experience accumulates as the result of a community of people. Tweaks get made. The outcome gets better and better. But this takes a random amount of years.

Real change always takes time. Some of those follow-on years of polishing could be compressed into a few months of getting more depth and breadth up front.

How do you help stakeholders become more aware of this ubiquitous fear of time? First, you can try to identify what they are struggling with.

Struggle 1: Startups (or innovation teams) don’t have the money.

Struggle 2: Big companies can’t get past convention. (This is the way things are done here. Or, following processes because they are the processes.)

Struggle 3: A person in the power structure does not see the value. (Research does not make progress on the things we need now. We can’t put resources toward something that doesn’t immediately translate to a prototype. Or, we are afraid to find out that we’ll need to make drastic changes, or pivot, based on what we learn.)

Struggle 1
If you see your stakeholders in Struggle 1, then it’s time to get them better connected to the people providing the money. Those investors do not want to waste their money, and having a conversation with them about the risk of making guesses generally leads to agreement. The kind of problem space research I describe to them has a time/money trade-off. If the study is being done by an internal team, it won’t cost more than the price of transcription and participant stipends, but since that internal team is always under-staffed and over-tasked, it will take many months. If the study is being done by an external team, it will be finished in 8–12 weeks, but cost may be $50-$75k. Price out the cost of failure because of guessing at the wrong direction, and compare. (Also compare this cost to the marketing budget.) Do this in collaboration with investors and stakeholders. They will take strong interest.

Struggle 2
Struggle 2 is more insidious. It’s hard to identify if your team is just producing what should be produced, and it’s embarrassing to realize it, so no one wants to discuss it. I have heard of teams producing so much research that it piles up in layers, and when it comes time to make prototypes, they are not drawn from the accumulation but from standard UX approaches and generalizations about users. These are the symptoms. If you notice these symptoms, consider running a rescue operation, but doing it in such a way that it saves face for both the stakeholders and the other practitioners involved.

For example, what is the viability of a pop-up ad within a few seconds (or a click) of someone reaching your page? You might get 4x the conversion with a popup than with an ad at the bottom of the page, but how sustainable is that — how many of those 4 people will have a relationship with your organization four years from now? Is there a connection? Can you find out? Furthermore, can you ask actual people what goes through their minds when the popup appears? Most likely it’s not about you and your conversion. But if you take the time to find out, you’ll have pieces of the puzzle that can help pull together the layers of prior research in a concise way. When the research is consolidated (people use a mental model diagram/opportunity map for this), then it can effectively influence design and also guide development phases, use cases, inventory lists, etc.)

Struggle 3
In the third scenario, Struggle 3, you’ll want to employ evidence that taking time now helps your organization save time later. Problem space exploration is only hard because it requires a different mindset. It’s disconnected from the solution, so it seems like a bad investment. It doesn’t seem necessary. It takes a mindset that, to support people with more breadth and depth, you need to understand people completely divorced from any thought of the solution.

Here’s an example. You have listening sessions with people, and then you take time to digest what you heard. What you thought you understood the person was saying takes on different meaning when you hold the entirety of what they said together. One concept they mentioned early in discussion gets illustrated with an example later, takes on an extra nuance, branches off into an explanation of where that nuance came from in their history, and then gets restated further on in a more succinct way. If you go over each transcript of each listening session carefully, and it’s magic how much better you understand that person’s thinking afterward. There is clarity that forms, and then patterns across different people coalesce from that clarity. This requires more effort, more time, but results in great depth of understanding. You can create better support for them.

The value comes from that depth of understanding, but also from breadth. With breadth, there are more aspects of what a person is doing that you can support, plus there are more philosophies you can support. Not everyone comes from the same background; people have different approaches. It’s a case like the long-tail — there is plenty more opportunity for your organization. This evidence is the sort of thing you can bring to the Struggle 3 scenario.

Teams and stakeholders all ask the right questions and wonder about risks, but unless there is strong user-centered leadership, very little is done to answer those questions accurately enough to mitigate risk. I think all this hurry has been introduced. It’s not the natural pace of the software craftspeople that I know, who are truly trying to create a beautiful set of code, an algorithm as close to complete as possible. It takes time to consider all the angles and potentials. Most long-lived software has its roots in craft. (Google founders, Apple founders, Microsoft founders) Alan Cooper said, in a UXWeek presentation, “In those days programmers wanted to make good software, and if money came as a result, that was a plus, whereas these days it’s the opposite.” He’s got a point, but I don’t think this is true of every software engineer today — programming still takes craft. It requires a mind that is interested in taking time to consider many different possibilities.

Possibly by identifying which struggle your organization is engaged in, and by encouraging the fine craft of creating digital products, you can slowly change the attitude toward taking time to understand the people you aim to support.