WHEN THERE’S SO MUCH TO UNTANGLE
IT’S SOMETIMES DIFFICULT TO KNOW EVEN WHERE TO START

Sphera, as a company, has a complicated history and some of its legacy code reaches all the way back to the early ’90s. Nearly every company that’s been around a while has experienced the pain of trying to migrate desktop software to the cloud. Even companies that started in the SaaS era have often experienced difficulties with some of their solutions not playing nice with modern browsers or lacking any semblance of reasonable user friendliness. Sphera was no different.

In an attempt to solve this problem, Sphera acquired Rivo in 2017 in the hopes of using that as their central platform to house all of their disparate software solutions. During this time, legacy products were converted to the Rivo interface while at the same time, a brand new UI initiative was launched in an attempt to also update Rivo’s aging visual design. Unfortunately, these initiatives did not do much to improve the interaction design (i.e. the UX) and only succeeded in creating further disparity within the products as only parts were updated this new UI. This was not the first time this was attempted prior to the true UX initiative.

Prior to 2018, Sphera already had three different verticals: operational risk, environmental performance, and product stewardship. With the acquisitions of Petrotechnics, SiteHawk, sparesFinder, and ThinkStep, Sphera broke into even more markets. Each of these acquisitions brought along additional pieces of disparate software, each with their own user flows and interfaces (some even with several), to the already complex problem of making them all play nice together.

One of the most important problems to solve in this whole process was “how do we switch between apps and how is that different (or perhaps part of) the primary and secondary navigation?”

Remembering that proper UX research methods weren’t available to us, we again leaned on our internal subject matter experts, product managers, and sales colleagues for help in understanding our user base. At this point, we also did competitive analysis to see how our rivals solved this issue as well as investigated how the largest companies such as Google, Microsoft, and Adobe handle it.

There are obviously many ways to switch between different products inside of a single suite. However, Sphera’s user base is tremendously varied depending on the role and it was important to choose the paradigm that would be most familiar to the personas who would be switching between products the most.

ACCOUNTING FOR ALL THE EDGE CASES

As is common in enterprise level software, you often have to account for rare possibilities well beyond the realm of reasonable expectations. Two of the most common questions I ask are “what if there are 10,000 of them?” and “are we letting the user customize these?” Both of those questions usually lead to making the solution as flexible as possible to handle worst case scenarios.

In the case of our app switcher, we needed to account for several combinations and permutations of factors that affected what appears in the menu. Here are some example scenarios we had to accommodate:

• What if the user only has access to one or two apps?
• What about super users who have access to literally everything?
• Where do the custom entries go?
• Can the user rearrange these?
• Can a user choose to hide apps?
• What if the number of groups forces the page to scroll?
• What if the number of entries in a single group forces the page to scroll?

We ultimately had to create solutions for all of these questions along with writing precise specifications for when to use each of those solutions. Unfortunately in the end, our best ideas were scrapped in favor something quick the development team could get out the door in a hurry, but that’s the way it goes sometimes. We were still proud of the work that we did and I was proud of the team for coming together for this exercise and doing it the “right” way under adversity.