Beware the Uni-App
A Product Design Trap
It’s Simply Complex
Startups know that simplicity is a tenant of modern product design. Apple reaches for simplicity in its carefully crafted end-to-end experiences from economizing material usage in hardware construction to having minimal visual clutter in software interfaces. Consumers have grown familiar with mobile apps that let you push a button and be driven away by a personal driver (Uber, Lyft), have your laundry done for you in an hour (Washio), or automate tasks (Workflow, IFTTT Do).
But in the hearts of uncounted professionals exists a desire for the opposite — to have a single, united interface that magically allows them to perform as many tasks in their own personal workflow as possible.
“There are two ways to make money in business: You can unbundle, or you can bundle.” — Jim Barksdale, Former Netscape CEO
We’re in the Post-PC age experiencing a great unbundling of app features fueled by the inherent design implications of mobile, including smaller screens, no keyboards, and new usage contexts. Behemoth apps are broken into a constellation of smaller ones to adapt. The SaaS business model proliferates and more niche market apps are created. The number of apps each of us must use in our daily work grows.
There are strong benefits to this — experiences are finely tuned to our needs in a way that generic software accommodating multiple markets could never offer. But problems surface in our workflow. Moving data from one app to another requires manual data reentry, opening the door for human error. Collaborating with other departments within companies becomes increasingly cumbersome.
When new customers are considering using your product, they are simultaneously wishing they didn’t need another app.
During my time as a Product Designer at Zapier, I first learned of this hunger for a global app, which makes sense considering it’s a startup that makes an app that connects hundreds of other apps. Occasionally, prospective customers would assume that, rather than getting an interface for building simple integrations, they would be given a universal interface showing them all of the data inside their other apps, offering all the functionality within each, plus new functionality made possible by connecting them.
It’s no wonder that idea is attractive — it’s an intoxicating proposition. Envision yourself being in the command seat at app mission control, effortlessly executing tasks, automating the push and pull of data between services, and always being presented with an appropriate interface to enable your intended actions.
In your imagination everything works as expected. When you work through the product details, you discover that you’ve not only taken on the challenges of making the simple integrations features work well (already a sizable challenge when APIs, which are often unreliable and difficult to troubleshoot, are the means by which you do so), but also all of the inherent product issues with every app you connect to.
It should be obvious that a startup doesn’t have the resources to build this at all, and that’s before losing time dwelling on whether or not you should.
I heard the request for the uni-app again recently when consulting for a startup with engaged, early customers, many of whom are frustrated by the number of apps needed in their daily workflow. New SaaS startups need to be tuned to customer pain in order to build something people will pay for, and here are numerous customers seemingly with the same request: “I want one place where I can do all of my work.” The request can sound valid, yet impossible to fulfill.
I wanted to get some expert advice on how to handle customer requests for the uni-app, so I asked two Lean startup leaders for their insights.
The Benefits of Consolidation
You’ve discovered real pain that exists for numerous customers. That sounds great on the surface, but Laura Klein cautions us to take a hard look at the value offered by the uni-app and notice: “The interesting thing is that consolidating them really only solves two problems.”
Problems Solved by the Uni-App
- App Switching
Having to repeatedly leave one app and switch to another is inconvenient. Mobile design cooks this interaction into the core user experience of returning to the home screen (or using a multi-tasking feature to switch between opened apps), which has alleviated this somewhat. Laura has observed all kinds of workarounds people have for this on desktops, which attempt to help them remember an app exists for a given task, and then get to it quickly.
- Manual Data Reentry and Syncing
Sometimes apps need to share data. Often people simply type the same information into multiple apps. Typos and slight differences can cause issues later and if you need to keep the data in multiple apps fresh, you’re losing a lot of time.
Apps like Meldium and Okta, which give you a single place to see and access apps and let you quickly log into your accounts, show that app switching is a problem that people will pay to solve. These are hard products to build and support and they only address one problem above.
Customers who are your primary target and are feeling app fatigue will wish that consolidating their apps will be something you can tackle while adding the new functionality your product offers. But, don’t fall for it. As Laura says:
“The products themselves have all sorts of other usability problems, but you need to decouple those from the user’s request for consolidation. The fact that each individual app is hard to use isn’t in any way solved by consolidation.”
Dig Deeper Before You Build
Brant Cooper remains hopeful that the evolving world of products offering well-designed APIs and will one day offer us “workflow nirvana”. But for now, he is skeptical:
“I find it hard to believe that new products built for specific workflows are a panacea. Reminds me of the ol’ suite vs ‘best of breed’ debates.”
The uni-app is a mirage — a product design trap you must avoid for your business to survive. There is a way forward. You must get to the root of the request for consolidation with multiple customers. Sure, Customer Development got you into this mess, but luckily, it can also get you out of it.
Take Laura’s advice and dig deeper:
“Figure out WHY they want the things to be combined. No, really. It’s not the reasons you think. It’s probably not even the reasons they think. They don’t actually want everything crammed into the same product with the same interface that has to be used for wildly different things. This is an Information Architecture nightmare waiting to happen. But they are trying to solve a specific problem by saying, ‘can’t these all be in one place?’”
This process works for all feature requests and gives you actionable recourse when the request is impossible. Look beyond the solutions customers propose to find the problems that inspired them.
Brant notes that even if you can find a repeating, root problem, you have to assess if you have the resources necessary to solve it:
“I think the key is trying to find a pattern among the customers. Are they asking for similar workflows? Are they in a particular phase of their business? Will they ever be happy or will they just continue to ask for more? Ultimately, you want to try and objectively evaluate whether these customers represent a market opportunity or one that simply causes too much pain to support.”
Here’s one last kick in the pants from Laura:
“When users ask for a specific solution, they’re really asking you to solve a very important problem. Figure out the underlying problem, and then figure out the right way to solve it for them. Sometimes it will be what they’re asking for. Sometimes it will be something much simpler. Or much harder. Whatever. Find the root problem and solve it.”