Consumerizing the Okta User Experience, Part I
Part I: Why Enterprise Software Has Such a Bad Rep
We are all consumers. The experience we have with products in our personal lives helps set expectations for any product that we interact with – the enterprise software we use at work included. In the past, that software was infamous for being complicated and costly, and the user experience for those enterprise apps left much to be desired.
In this two part post I am going to talk about how massive improvements in consumer software products and online services (part of the “consumerization of IT” trend that Eric referred to) has affected significant change in enterprise software user experience broadly and how we are pushing that even further here at Okta.
In this first post I want to reflect back on how the enterprise user experience (UX) ended up with such a bad reputation.
I started my professional career as an application developer at PeopleSoft in 2000 so I have some insights into why the experience was not that great. I should mention that PeopleSoft was actually known for having a pretty good UX relative to their competitors at the time.
On-premise = captive audience and high switching costs
If you were an end user of enterprise software ten years ago it was likely not purchased by you. You either had it installed on your computer by IT or it was accessed through some internal portal that probably cost hundreds of thousands of dollars and months (if not years) to implement. If you didn’t like using the software, too bad – it cost a lot of time and money and decision makers needed to get their ROI. In other words, the “switching costs” were very high.
The advancement of SaaS and resultant de-centralization of IT has dramatically changed the buying experience and lowered those switching costs. People now evaluate enterprise software the same way they do a consumer product: by evaluating their own needs and budget and finding the best product that meets those needs for a given budget. If the product ends up not meeting their needs a better one is only a Google search and a free-trial away. Consumers and Enterprises have certainly benefited from this increasingly competitive environment.
Enterprise apps address complex problems so they must be complex, right?
I have a friend who is a UI engineer at a SaaS enterprise software provider and we often talk about UI design. He showed me one of the applications he worked on and while it was visually impressive, I was overwhelmed.
“It’s complicated. I don’t know what to do,” I said.
“Well, it’s enterprise,” he said.
Admittedly, the problems tackled by enterprise applications are often complex. Unfortunately this complexity is often transferred to the user because frankly it’s hard to make the complex simple. A commitment to great design is a path to simplifying the complex. I believe the emphasis on user experience design was previously missing from enterprise applications. At Okta we understand there is real value in simplifying the complex. Everyone is committed to keeping it simple; it’s one of our core values, as Eric mentioned in his recent post, it is also central to the business model that we are betting on.
Built by engineers from an engineering point-of-view
The last thing that contributed to the lack-luster user experience of enterprise apps was the process of making enterprise applications. Most enterprise software companies had several groups involved in making an application.
- Strategy team – their job was to know the market (i.e. the competitors’ feature set) and predict what to build next (good luck with that)
- Product management – they knew the product intimately and talked to customers to better understand their specific needs.
- Business analyst – they met with the product manager and strategy team to write a functional specification for the feature.
- Application developer – this person (my role at Peoplesoft) took the functional specification and built the feature from the backend layer to the user interface.
Unlike the agile process we use at Okta, the traditional enterprise software process was more towards the waterfall end of the spectrum. The problems began when the application developer got the specification and had to turn it into an actual application. The developer had his or her own perspective on how to build the feature. Much of their perspective was shaped by constraints in their development platform and their in-depth familiarity with the data model behind these features. They were in a box that is very much real but arcane and irrelevant to the user. As a result, the user interface was a product of these constraints; an often-literal representation of the data model in the UI that was unintuitive to the user.
It’s not that the developers wanted to make it complicated; the process and organizational structure just resulted in the production of technology-centric products.
Where’s the designer?
The other thing conspicuously missing in the list above: a user experience (UX) designer. It wasn’t until later in my time at PeopleSoft that we started to see a UX team get involved with application design. Even then, the UX team was a separate entity and not embedded into the team or consistently involved in the development process.
At Okta, I sit directly with our engineers, sales team, product manager, and head ninja (er, CEO). More importantly, I listen to our customers directly and observe them using our product every week. Our design process is free of the silos that once detracted from the end result. Teammates and customers inform our perspective constantly.
In part two of this post I will go into more detail on how specifically we are doing things differently at Okta