In a world rapidly moving away from computers, we asked ourselves: how do we make a business system intuitively work on a phone?
During my employer's annual business review in 2020, we set a new, lofty, target for ourselves. We wanted to move our systems to a mobile-first architecture by the start of 2025. Like IoT automations and cloud before it, we realized the rise of mobile in the business landscape was inevitable. We either prepared for it before or lose precious time playing catch up. But this wasn't simply a matter of updating our designs or reorganizing menus; unlike mobile apps, we had over 250 menu items and 15 years of legacy users to accommodate. I was tasked to investigate how to run a company with simple phones.
Including ideation, research and prototyping
The Story in Numbers
System users exclusively operate on mobile, owing to their on-field job role
Top management already access the system on their phones in responsive mode
Average daily transactions involving long-form data entry by each customer
Years experience of some users on current or legacy versions of the systems
System functions (listed in the menu) that had to be adapted to the mobile
Functionality of the entire system dedicated purely to the input of business data
Quarterly requests for mobile or tablet projects;
a notable shift in workflow
Average age of 80% system users. This segment has an age range of 22 to 35 years.
The aim of this research project was identify a suitable way to convert a suite of business systems, used to manage all the major functions of the target company, from a traditional computer-driven to a portable (mobile or tablet) driven infrastructure. I had to look not just at the designs but the processes as a whole. The proposal from this research had to provide 'how-to' answers for the following questions:
Simplify the overall workflow
Design a suitable interface
Preserve overall productivity
Propel the transition to mobile
The first place I started was to understand how people use the existing product and what work they do on it.
As part of this, we identified two areas having the most impact on the architecture:
How to get to the relevant data?
How best to present that data?
Upendra and I started by analyzing the menu and identify areas of improvement:
Tackling Complexities in Navigation
So, why was the system menu so long? The answer lied in the manner in which the original development team handled various document lifecycles.
Like any business system, WebXpress emulated the real-world operations through document management. Performing any activity meant creating a corresponding document; and in the process of completing that activity, the document would go through a series of updates, i.e. a predetermined lifecycle.
To ensure consistency across modules, the team standardized the workflow for all documents. In fact, they used the same terminology throughout, as shown below:
This not only a was fantastic way to help users have a shallower learning curve, but also set the product up for adding new processes in the future.
Sadly, the way they implemented this workflow in the final product could not stand the test of time, as we'll discuss next:
Hurdles to Scalability
Since a document passes through an average of four stages, each being dependent but not related, the team decided to have separate screens for each of them. It was done with good reason too:
Most customers have each stage handled at different locations
They also have different people to manage different stages
Not all users have rights to certain stages (for security reasons)
This worked fine when the product had twenty features. But as more were added over the last fifteen years, the menu ballooned.
This is still acceptable to desktop users, but as we began our transition to phones, we quickly stumbled into major usability problems.
Scrolling through such a long hamburger menu was intimidating to novice users, something we often experienced during client training.
The wireframe represents the general structure of the product's many processes. The animation is a screen recording of the actual menu (partly retracted).
Looking Inwards for Inspiration
The users' biggest complaint was their inability to distinguish between the purpose of different menu items, and not necessarily their count.
It turned out, we'd partly solved this problem in the past with our in-house app, XpressOffice, by separating different modules into applets.
This was the 2017 version of the app, which was directly inspired by Android's app drawer. Large icons and unique colours were found to give our users a sense of context and natural grouping.
The photo is of Aqib, our Sr. Support Manager, who tested the new UI. The animation shows the new structure.
It was a big step up from the hamburger menu. The applet structure instantly made our system feel like it belonged on a phone. It received positive feedback from beta users as well, which prompted us to take it live by early 2021.
A problem, however, surfaced during its development. The system's navigation was fundamentally the same. We had reorganized the menu, not simplify it. Further, the new structure led to bigger complications:
By adding two menus, it required extra steps to reach a desired function
This would force us to create a landing page for every module
Reassess. Reset. Repeat.
At the end of this exercise, my team was disappointed with the outcome. We asked ourselves if this was the extent of improvement possible, because it felt more like a re-theming (without addressing the underlying problem). So, the team headed back to the drawing board; but we kept what we learnt from this iteration.
The applets idea was a good foundation; I needed to find a way to remove the menu inside the module that opened. The result was a tabbed interface shown below:
This layout all but eliminated the menu. It also made the process easier to visualize; each step was a tab and each document would pass from one tab to the next.
There were two challenges, however:
Exceptions, by their nature, were not a part of the process. Placing this section as the last tab negated the simplicity created by the tabs.
But even more problematic were the tabs themselves. If there were three tabs: there were three tables, three filters, and three sets of programs to fetch essentially the same data. This wasn't really solving the navigation problem.
Like the grid of apps, tabs were a good idea; what we needed was a better way to execute processes.
Rethinking the Workflow
Containers: Circling Back to Navigation
This does away the menu in a traditional sense.
Seeing the Containers in Action
Putting Everything Together
Use the guides to navigate the below interface:
Advanced search →
← Menu of input activities
← Reports and dashboards
Project's & Outcome Future
A Note on Privacy
Throughout this case, I've tried my best to balance the amount of details I share to highlight this project's journey while avoiding sensitive data, features or sales figures from being disclosed. I still hope you found it informative and enjoyable!