October 21, 2019

Data Apps that Succeed - why friction matters

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

I’ve spent a lot of time lately thinking about data apps - which apps are successful in their goals (presenting the user with data and getting them to take action), and the UX patterns that drive that success. The Data-User Experience (DUX) Matrix was my initial take on the two factors influencing success (transparency and friction). Now let’s spend time making that theory feel real by tying it to actual examples.

In my career, I’ve had the privilege of working on lots of internal data apps. These were all bold efforts to leverage the power of data to move the needle. (Yes, that was intended to sound like a string of buzzwords :) ). Some of these apps had an impact, but most didn’t. Here are examples of two apps I was involved with that were trying to solve very similar problems. One failed. One succeeded.

Similarities #

To compare a success and failure, we should first explain how they were similar.

Main problem: given a large pool of people (about whom we have data), how do we organize/filter/prioritize then select a subset for X purpose? (segmentation)
Starting state: independent, siloed teams, (almost) no enforced governance/oversight, no iterative process, data not the top priority
Subject matter experts who saw the same patterns being repeated across the company (with little/no improvement)

Now let’s see how their approaches differed.

The Failed App #

Why consider the app failed? It was developed for nearly two years, and thrown out before ever being used in production
Operating principle underlying the project: Build a cool, slick interface that incorporates best practices and handles governance behind-the-scenes; users will prefer the look/feel of this to their existing tools
What went wrong?
- Ignoring the friction of the everyday user: what was going through their mind when they do work? What keeps them from making good decisions?
- Ignoring the friction of organizational change: hoping people would jump to a new process because it looked cool, instead of the hard process of gaining buy-in and setting a direction
- Ignoring the SME: development efforts and internal product direction disregarded much of the input provided by the SME, and attempted to circumvent that person, instead of empowering them

Success #

Why consider the app successful? Even the earliest iterations were used extensively by the intended customers, and significant ongoing investment was made based on demonstrated usefulness
Operating principle underlying the project: An internal process was broken (in a very costly way), and needed to be fixed with a combination of data and knowledgeable people
What went right?
- Starting with the most basic data needs: Much of the data needed by target users was not easily accessible, or not accessible in a useful format; this app started by addressing the most common questions in a basic way
- Organizational buy-in: The SMEs spoke, leadership listened, and the toll of changing a major process was embraced
- Empowering the SMEs: The most basic needs were automated to the point of self-service, freeing the SMEs to become process consultants who focused on bigger problems.

Takeaways #

Deciding factor: the successful app acknowledged friction upfront and made a concentrated effort to tackle it. The failed app tried to ignore the friction and focus on simplicity.
A slick, “perfect” UI that tackles perceived problems is less valuable than addressing basic data needs
SMEs will always play a role in business process, but they need freedom and support to drive organizational change

Notes #

Engineer-minded folks might be tempted to think better underlying tech influences the outcome. Better tech allows teams to iterate faster and try new things, which is a must for modern product development, but in these cases:
- The failed app was backed by a state-of-the-art data warehouse, had a React front-end, and was deployed on Kubernetes
- The successful app was backed by a series of database procs, Python scripts, and had a front-end built in Oracle Application Express (I still have nightmares… but it served it’s purpose)
Cutting-edge tech is often viewed as the “fast” solution, which is not always the case:
- The failed app spent nearly two years in development before being thrown out
- The successful app, though ugly, was thrown together in three months, and during that time the SME team was already working through their process manually
This lesson is most effectively applied to internally-developed data apps; but can be useful for B2B. Highlighting friction upfront is a critical part of setting expectations for business customers.

Feel free to connect with me!

Kudos