We’ve been accustomed to the same basic user interface across all apps and sites for essentially two decades now: a layout with buttons. Those layouts have become slicker over time, but they’re still the same species.
Now that the other layers of the software stack are being reinvented — through data warehouses and operational analytics in particular — there’s an opportunity to reimagine UI as well. I chatted about this with James Evans from CommandBar, which just launched out of beta on Monday and announced a seed round (which I participated in). James and his co-founders envision a world where, in their words, we can translate intent to action through search (Command K) rather than buttons.
What's the origin story of CommandBar?
My co-founders, Richard and Vinay, and I were working together on a different B2B product. We faced a fairly common user segmentation problem. Our power users gave us great feedback through email and Intercom, and we responded quickly to that by evolving the product. But those product changes made the product hard to use for people who didn't fall into the power-user segment that had offered most of the feedback (and frankly also hard for power users, since no one really used all the features). The product was kind of one-size-fits-all but in a way that meant confusing-for-most.
So we were sitting around trying to figure out a solution to this problem. We've all used Superhuman and other products that have a command bar inside -- basically a search bar for functionality, with keyboard shortcut "Command K" -- and we had an "aha" moment. A command bar would allow us to remove the entry points to a lot of features: instead of a button leading you to X, we could allow you to search for X. That way, any user could quickly find what they cared about, but the UI would never be cluttered or overwhelming. Basically this was a way to scale a UI but keep it discoverable. It also had the unexpected effect of increasing our product velocity; we could build narrow and experimental features without sacrificing any UX.
So we started building it. As we went, we realized that this problem was generalizable to basically every software company, and that it was hard to build well. So we decided to productize the feature.
Do you believe you're creating a new category?
I’d say so, in the sense that there isn’t an established buying center for what we’re building. From a product perspective, you could say we’re redefining search to make it work for software.
You could also say we're tackling the same job-to-be-done as some of these companies that offer onboarding flows for customers, like WalkMe or UIPath. They're trying to make it easier for a company to onboard users of different flavors. But we're doing it in a way that helps users across the lifecycle. They can get started with CommandBar to learn how an application works, but then we can support them throughout their user journey, discovering new features or just using CommandBar to do stuff faster in an app.
It's not like there are 5 other command-bar-as-a-service vendors. So people aren't used to buying a product exactly like this, and they don't always have a perfect vision in mind when we start working with them -- but they're super energized by the possibilities. We’re addressing problems that every PM or product owner feels viscerally.
We still do personalized onboarding, hand-holding new customers through that initial configuration to try to identify ways to use the product in their business. We'll discuss, what is hard for users to do in your product? What are the five pieces of functionality that new users might be really interested in when they hit your site? What are the flows that power users complain about most often? So it becomes more of a co-creation process. We supply the activation energy for more folks to get started, and they give us incredible feedback.
What do you think the rise of CommandBar says about how user interfaces will evolve for this next generation of SaaS?
There’s a famous blog post from 2000 called “The End of Web Design” that basically says: because users spend most of the time in other apps, your UI should use the same building blocks as every other app -- buttons, menus, tables, etc. This I think does a good job of explaining why most user interfaces (rationally) look the same. We’ve gotten really, really good at rearranging these building blocks to create great user experiences.
But I think some trends are creating a need for new building blocks:
Lower attention spans: In 2000, maybe we relied on 3 apps, so we could learn how all the menus were structured and what all the buttons did. Now we use so many apps that it’s impossible to remember how every UI works.
Higher expectations: More users are used to hyper fast consumer experiences like Google search. The traditional UI building blocks just aren’t that fast. I bet everyone reading this has spent some time in menu hell, trying to find some simple feature you know exists but getting stuck wading through nested menus.
For me what these trends point to is a need for primitives that make it faster for users to go from intent to action. CommandBar is our proposal. In an app that uses our widget, users can open up the app, click once to open CommandBar, search for what they’re trying to do (in their own words), and be presented with a series of actions they can take immediately. No learning required. I often joke with our customers that turning off CommandBar would be like asking their users to stop using Google search and go back to Yahoo Directory. It just makes the old building blocks feel old.
I don’t think the old building blocks are going away though. Traditional UIs are really great at teaching users about information architecture, for example. But I expect new primitives -- maybe CommandBar, maybe something else -- to supplement them by providing a faster way to get from intent to action.
Why do you think Command K is so powerful?
Because CommandBar is a search bar, it’s very simple to use. Some people look at it and think “that looks like a command line interface, it must be for power users”, but we have tons of end users who don’t identify as power users and don’t use keyboard shortcuts. Anyone who can use Google can use CommandBar. Just type, in your own words. That’s it.
Like search, it’s also personalizable. PMs spend so much time creating flows to accommodate different user archetypes (this is basically the brick wall we ran into at our last company that motivated us to build the first version of CommandBar). CommandBar is easy to personalize: it’s very easy to show onboarding-related commands to new users and more niche features to power users.
And then the kicker is that it’s also fast. When you achieve something with CommandBar, it feels good because the time between intent and action is short. So you want to use it again. And not using it is like ordering something on Amazon and not getting free-2-day shipping: it just feels subpar.
I've often thought that eventually UIs will be independent of screens — whether it's through audio commands (like Alexa, but built into software) or perhaps holographic. What's your take on this? If you agree, what kind of timeline is likely for UIs to evolve in this direction?
I view Alexa and voice interfaces generally as another solution to the “intent to action” problem. When I’m lying in bed at night and need to set an alarm, I want the alarm to be set as fast as possible after I form that intent. I don’t want to do anything to achieve it, I just want it to happen.
I don’t expect voice interfaces to replace software with screens anytime soon though, because there is so much work that would be impractical with voice. Imagine trying to build a spreadsheet with your voice. Keyboards and screens are pretty great for a lot of knowledge work. Maybe there’s a Lindy effect there -- maybe they’ve stuck around for so long because they’re just really good interfaces.
Neuralink and other brain-machine interfaces could completely upend the keyboard-and-mouse status quo, though. I don’t really know anything about the technical details, so I’m not sure what kinds of workflows are actually tractable to achieve with a brain-machine interface, but I’m pretty sure that there is no faster way to go from intent to action than to go from thought to action.
Moving from vision to practical matters…What's your go-to-market strategy?
We are serving two primary archetypes. Our initial champion is often a technical person who sees that our product would save them weeks of work. Our second archetype is someone who's excited about what our product can do for their users. It could be a customer success person who's interested in ticket deflection, or a product manager who's interested in user discovery.
The technical champion often uses our docs and gets up and running largely on their own. The second champion often benefits from more onboarding to flesh out how we can solve the use case that brought them to CommandBar and also identify adjacent ones.
Do you have a specific way that you measure product-market fit?
Yes, two ways. First, we ask all of our customers the question that's become commonly known as the Superhuman product-market fit question: How would you feel if you could no longer use CommandBar? Second, we ask our end users -- the people who are using CommandBar inside of our customers' apps -- the same question. It could be that the customer doesn't think there's value but their end-users actually love it.
That's very interesting that you're taking ownership over the customer experience that your customers are offering. It’s a “meta” form of customer success.
If you’d like to learn more about CommandBar, check them out here.
If you'd like to hear from more founders like James about once a week, sign up for my newsletter here: