Hi! I am
Mobile-first Ethos
In a world rapidly moving away from computers, we asked ourselves: how do we make a business system intuitively work on a phone?
The Team
Project Background
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.
Timeline
3 months
Including ideation, research and prototyping
The Story in Numbers
22%
System users exclusively operate on mobile, owing to their on-field job role
10%
Top management already access the system on their phones in responsive
300+
Average daily transactions involving long-form data entry by each customer
8
Years experience of some users on current or legacy versions of the systems
250+
System functions (listed in the menu) that had to be adapted to the mobile
90%
Functionality of the entire system dedicated purely to business data input
20+
Quarterly requests for mobile or tablet projects;
a notable shift in workflow
28
Average age of 80% of users. This segment was between 22 to 35 years.
Research Objectives
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
Structure
I kicked off this project by identifying the challenges in front of the team. We realized early on, the target users and circumstances of usage were vastly different from traditional desktop-driven operations.
Challenge Checklist
We identified some differences between our desktop and mobile users, based on informal interviews:
• Back office or "post-factum" operations
• System is a part of real-time operations
• Volume-oriented (users read 4 reports at a time)
• Limited to one task (e.g. a single data entry form)
• Relatively accommodating to latency
• Feedback showed, latency is equated to low quality
• Catering to management, who are on the move
• Catering to ground staff, who're averse to extra steps
Fundamental Observations
Furthermore, we had well documented past projects that recommended against mobilifying the entire business system, citing two key reasons:
1
Responsive
≠
Mobile-first
-
Designed for desktop users
-
Text and content-heavy
-
Focussed on layout
-
Mobile is a backup device
-
Designed for mobile users
-
Almost always content-lite
-
Focussed on process
-
Mobile is the default device
2
Most screens are data intensive
Output (90% of Screens)
Being a data-driven system, it's only natural to have several reports on offer. Each report has ten to twenty five columns, and a typical month's business generates 5,000+ records.
Input (10% of Screens)
While the volume of data may be less than output screens, the number of sections and required fields made it difficult to adapt to a mobile UI.
Setting Expectations: Identifying Ideal Traits
To tackle the above observations, any new screen would need to meet the following benchmark:
Cognitive Lightness
To be easy to understand and quick to operate.
Intelligent Automations
To reduce the steps to complete an activity.
Progressive Elaboration
To set the granularity based on the use case.
Testing the Waters
For our mobile-first interface to succeed, we first needed to resolve the dichotomy of business data being easy to consume yet comprehensive enough to be valuable. That meant asking what really matters to users.
Entity / Action
Further Context to Entity
Outcome
Supporting the Outcome
Simplifying Output
Upendra and I started our research with output data, as it is rarely adopted on mobiles by most of the industry even today. When we analyzed our most popular reports, a surprising pattern emerged from the table composition.
After a few reports, we could easily identify two pieces of essential data, the "entity" and its "outcome". The rest of the columns were either providing further context to the entity (e.g. if Employee ID is the entity, name and branch is context) or additional views to an outcome (e.g. if Attendance is the outcome, total work days is supporting it).
This let us define a new table structure, with up to three columns (each with an essential and a contextual data).
Optimizing Input
Guided by Devang, our tech lead, we embarked on the next challenge: minimizing data entry.
To do this, we analyzed a set of complex forms in the product. Most averaged 50+ data points that users either entered or verified to submit.
From those points, an average of 12 fields were really being entered. Here, mobiles can offer a unique advantage—they can automate entry of connected data with additional context.
Additional Context for Intelligent Automation
Current Location
Popular Selection
Operating Branch
With context, four fields in this example were auto-filled by entering just one. This happens when the system is context aware.
User Interfaces
Structure was only half of the story. Our mobile-first design needed a unique visual identity that balanced seriousness with a modern look. It also had to handle large quantities of data while being unintimidating.
Grid System
I used a twelve-column grid layout, grouped into four sections, to structure the UI.
Despite having lots of data, ample spacing gave the screens a balanced appearance.
Fluid Layout
Described in detail below, by using the grid to design the components led to a unique styling feature — the ability to fit multiple input / labels in a single row.
The animation is an illustration of how this layout can accommodate up to four items into a row, depending on the need. Each item is at least three columns wide.
Grid as a Component
Grid systems are essential to UI designing today because they are repeatable, and thus create a harmonious layout. Grids do this by setting the boundary for objects to logical segments. This fact caught my attention. If a section of the grid were to also be dimensions of a component (such as a textbox), one can stack a group of related elements together without the need for superfluous spacing. And despite being edge-to-edge, as see best in the desktop screen, they appear less cluttered.
White space between components can in turn become a tool for spatial context and logical grouping. For instance, the textboxes for "Consignor" and "Consignee" are close by but not connected, indicated they are part of the larger group of "Delivery Details" but are still distinct pieces of information. Compare that to the inputs for "Vehicle No.", "Service" and "Pay Basis", which are joined to indicate their interdependence.
Theme and Colour Palette
If structure is the essence, then colours are the identity of a design. Building the identity of this product was thus a paramount initiative.
Landing Pages & Menus
Implementing Dark Mode on a Business System
Dark themes are a mainstay of consumer products, but not so much for business systems.
As our primary medium was mobiles, we needed to consider dark mode from the get-go.
This endeavour, though, was not as easy as swapping white for black background.
For each supporting colour, I had to also create variants of shades for it to work properly.
Primary and Supporting Colours
With the new structure, most screens would have an action button, which would be their focal point.
Even though buttons are styled with a secondary colour, I wanted it to grab the user's attention. As a result, I chose a variant of cyan. For the primary colour, I followed the subtractive colour theory, as a contrasting theme wouldn't suit such a product.
P
S
The colours of the final version also contrasted with the minimalistic canvases. It gave the UI a much needed relief and help define its identity.
Most screens would also have bits of data to provide additional context. These supporting elements thus needed a supporting colour palette. The objective of such data would be to stand out from the rest of the UI elements, which is why I chose a diverse set of colours with three levels of saturation, as shown below:
Learnings from the First Iteration
When I initially worked on the theme, I chose a muted palette to reinforce cognitive lightness. However, most testers gave the feedback that they found it "to be dull, when they first saw it alongside the rest of the screens."
To solve this, I quickly adjusted the contrast level of the colours and conducted a vote. The new palette, though not calibrated, still won by 95% support!
Human Interface Guidelines
I created this document as a guideline and design benchmark for both developers and product managers in preparation for the transition. It features UI components, language rules, interaction design, colour scheme, and more.
Information Architecture
With a structure and design in place, it was now time to put the separate pieces together into a cohesive product.
As part of this, we identified two areas with the biggest impact on the architecture:
Navigation
How to get to the relevant data?
Workflow
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 product's menu so long? The answer lied in how the original 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.
For consistency, they standardized the lifecycle of all documents, as shown below:
This enabled users to have a shallower learning curve, as well as set the product up for adding new processes in the future. Sadly, the way they implemented it into the final product could not stand the test of time, as we'll discuss next.
Hurdles to Scalability
Since all documents pass through approximately four independent stages, the team decided to have separate screens for each of them. And this was with good reason:
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 issues.
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 (retracted) menu.
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, which was directly inspired by Android's app drawer.
The above photo is of Aqib, our Support Manager, who tested the new UI. The animation shows the new structure in action.
Implementing Iteration One
The applet structure was a big step up from the hamburger menu. It instantly made our system feel native on a smartphone. Also, it was well received by beta our users which prompted us to take it live by early 2021.
Problem was, the navigation was fundamentally the same. We had reorganized the menu, not simplify it. And it led to bigger complications:
Adding two menu levels added steps to access any feature.
We'd be forced to create landing pages for every module.
Reassess. Reset. Repeat.
At this point, my team was disappointed with the outcome. We asked if this was the extent of improvement possible, because it felt more like a re-theming (without addressing the underlying problem). So we headed back to the drawing board; but we kept a lot what we learnt from the previous iteration.
The applets were a solid foundation; we needed a way to remove the menu within modules. What I created to achieve this was a tabbed interface shown below:
This layout all but eliminated the menu. It also made the overall process easier to visualize. However, it still didn't reduce the process. 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
The current process wasn't optimized for mobile, which meant it needed rethinking.
Integrating Processes
The solution came from an unlikely source: buying recommendations on e-commerce platforms. These recommendations reduce friction encouraging more time and money spent on their platforms. In our case, the "next action" recommendations give users simple single-screen management of documents.
Since this presented a fundamental change in architecture, I came up with the idea to highlight the action column to help the user easily locate and understand it. User tests are ongoing (as of late-2021) but initial feedback is promising.
Imagine an email program that made a separate app for each task. Besides cluttering your screen, it makes mail management difficult.
This was our process in a nutshell; it wasn't intuitive for mobile users.
Combining Related Workflows
By integrating multiple steps (and effectively multiple screens) into one table, I was able to shrink the process footprint of any document. An unintended consequence of this was the perceived 'lightness' it created.
This also gave Upendra and I the ability to visualize documents as not just singular entities but as part of a larger activity as well. Take for instance, Trip Planner. This module is a combination of two previously independent modules that users had to visit separately to perform the single activity of planning a trip.
Load Planning
Vendor Bidding
Trip Planner
Samantha
May
Marketing Executive
I'm a paragraph. Click here to add your own text and edit me. It’s easy. Just click “Edit Text” or double click me.
Step 1
Identify your workload
This new way of thinking about documents unlocked a great potential for simplifying this product.
Containers: Circling Back to Navigation
Input
Output
With the ability to simplify and reduce modules it was time to revisit the menu structure. At the very start of this project, we had identified two clusters of data: input and output. It suddenly became clear that this was the best method to group all features.
All output data was clubbed to the top, with the search-bar as the focal point. All input features were neatly tucked behind an action button.
This does away the menu in a traditional sense.
Seeing Containers in Action
A preview of the new grouping structure is shown below. I've used a desktop layout for its linear navigation.
Putting Everything Together
Use the guides to navigate the below interface:
Quick search →
Advanced search →
← Menu of input activities
← Reports and dashboards
Project's Outcome & Future
With a direction in place, the recommendations from this project were handed over to respective product managers to take ahead.
Projected Milestones
Q3
2020
Q4
2020
Q3
2021
Q3
2022
Q1
2023
-
Get Client Buy-in
-
Deploy First Module
-
Review Progress
-
Recommendations Submitted
-
Design System Distributed
-
Onboard All Critical Processes
We chose a non-radical approach to redesign our system. We decided on keeping our current UI, and instead focussing on implementing the new process, thereby lowering friction.
2021 Update
One of the reimagined modules for on-ground staff was deployed with 500 bikers for a major Indian firm, with resounding success.
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!