UX Redesign of Ninjavan’s web app for merchants

Designing a logistics enterprise software for low tech merchants in Southeast Asia
Merchants in 7 Asian countries using the redesign
Easier to use*
*Based on scores of Single Ease Questions (SEQ) from usability studies
Significant increase in user comprehension of interface
Photo of e-commerce merchant looking at screens from this project
Ninjavan is one of the biggest logistics startup based in Southeast Asia. It primarily serves the e-commerce merchants of the region, ensuring their products get into the hands of the region’s consumers.
Build a simpler, more intuitive web app
I worked with a PM and a squad of developers. I was the only designer on this project. 
I was responsible for Research, Prototyping, UX/UI Design, and the creation of the Design System.
Build a simpler, more intuitive web app
2018, 8 - 10 months
A complicated software hurts business
In 2018, Ninjavan decided to revamp their merchant-facing web app.
The software was too complicated, so merchants would rely on salespeople and customer service to help them with basic tasks. This sapped up precious company resources. Ninjavan wanted to change that.
Build a simpler, more intuitive web app to increase user uptake
Design a web app that is simple-to-learn and easy-to-use for e-commerce merchants in Southeast Asia
Create an entirely new UI while keeping with Ninjavan look and feel

Act 1: Research

Questions to understand who users are 
To understand the problem our merchants were facing with the web app, I first wanted to learn about them: 
The identity of our merchants from all 6 Southeast Asian countries
Their needs, goals, and challenges as merchants
Their end-to-end workflow, from getting an order from a customer, shipping, to after sales support like returns and damaged parcels
How and why they were using/not using the current web app 
The particular problems they faced while using the current web app
User research with 65+ merchants across 6 countries
During the first couple of months, my PM and I zipped across 6 Southeast Asian countries to conduct user interviews with 65+ merchants who shipped with us.
Our goal was to build a deep understanding of our merchants so we wanted ethnographic data of our merchants. Being there to see them in person allowed us to gather that information.
Some of the amazing merchants we spoke to. It was very inspiring to see the resilience and innovative spirit of our merchants. 
Making sense of our users and their workflows
As the data was collected, we made sense of what we learned about our merchants with techniques like: 
Personas - to group emerging user behaviours, goals, needs and challenges
Customer Journey Maps - to understand merchant's end-to-end workflow
Workflow documentation - to 'see' what other interfaces merchants were exposed to as part of their work and leisure
*Actual research documents and full findings have been omitted to comply with disclosure agreements.  
Most users had low tech sophistication, so the interface design had to be direct, clear, and hand-holds users through tasks 
Many users were employees, so they had a real fear of screwing up at their job, making them very panicky users needing assurance
A key problem they faced using the interface was the lack of clarity and understanding of what they could do with the system
Low tech users forced to use a complicated system
Users had low tech sophistication
Most of our merchants had limited experience and confidence with using desktop applications. This meant that the interface design had to be direct, clear, and hand-held users through their tasks.
Users had a real fear of doing the wrong thing
Most of our users were employees, so there were naturally afraid of making mistakes and evoking the wrath of their bosses and customers. This fear meant they were very reluctant to click around and explore the interface. For these users, it was crucial that the interface was straightforward and clear. 
Inherent system complexity
While some parts of the old web app were truly and needlessly confusing, there were parts of the system that couldn't be simplified further due to the multiple cases the system had to support.

How would you design an enterprise software for low tech users? 

How might we make a complex enterprise software usable for low tech users? 

Here's how I attempted the challenge

Act 2: Design Approach

Reduce complexity
Identify key functions and build around them + Simplify flows and interfaces
Optimise workflows
Optimise flows and components to meet user needs
Create Calm
Tweaking flows and interactions to create calm in panic-prone users
Identifying key functions to create hierarchy and easy access
The first goal was to identify the top task and problems merchants typically used the web app. By understanding our merchant's job responsibilities and workflows through the research, I was able to design the web app around these main functions:
Structuring the webapp around key functions
Building around 3 main functions. By identifying these main functions early on, we were able to work out the Information Architecture and create hierarchy on the Dashboard.
Simplifying flows and interfaces 
This was the bulk of my work. To accomplish this, I had to understand the needs and logic of both our users and Ninjavan's backend systems. 
Working with the PM and developers, I used flow diagrams to map out the required inputs and technical limitations. Next, I took a step back to think about what problems we observed users having, the problems they were trying to solve, and what would make sense from their perspective. 
I simplified and rejigged flows. I experimented with ways to express the process clearly and simply. Over many rounds of prototyping and testing, the design started to take form. 
Flow diagrams to understand the system. Here, I map out all possible flows for a process (top), and the required inputs from the system's point of view (bottom).
Simplifying user choice. To create a parcel, the old design required users to choose between 4 order creation methods. In the redesign, we consolidated these 4 methods into 1. Users would go into the 1 flow, then choose their preferred creation method. Users found this significantly easier to understand the order creation options available to them.
CSV mapping in progress
Employing visual metaphors to make clear what users had to do. CSV mapping is a function that allows merchants to quickly create orders by uploading a CSV file, then matching the columns in the CSV to the system input we needed. It's an incredibly useful function, but was poorly understood due to the UI complexity involved. To make it easier to understand, I tried drag-and-drop interaction to make apparent the matching action users had to make. This made it significantly easier for users to understand how to use the function.
Optimising flows and components 
With each feature, I dived further to understand the mini user goals and rationale. Which flows and components do merchants find most useful? Why and when would a merchant use a component? What was their goal? Which information is crucial? Why does this matter? 
These questions allowed me to think about how we could design a feature to better meet the needs of our users.
Discovering and linking related flows to create a seamless userflow. By working out our merchants' workflows, I realised there were disparate features in the old web app that merchants would use together to complete a task (such as helping a customer figure out where their parcels are). I therefore linked up these different features into one complete flow for the users. This was very well-received with the merchants we tested the prototype with, so we shipped this. 
Old parcel statuses. Parcel states indicate to a merchant how many of their parcels are stuck at a certain stage. In the old design, they were hidden in the top nav. Merchants found these states very useful and would actually log in to check the parcel statuses. However, each merchant only cared about a few status, and these states differed merchant to merchant. 
The redesigned parcel states were brought to the Dashboard so that merchants could see these states immediately after they logged in. States were also made customisable so that merchants could focus on the states they cared about. 
Calming panicky users
During the research, I observed that users would panic very easily if things did not go as they expected. Thus when I designed the flows, interactions, and UI elements to create a sense of friendliness and calm.
Error message masqueraded as an alert
Deliberately deescalating error messages. Users panicked when they made errors. Thus, error notifications were made to appear as warning messages so that users would not unnecessarily be alarmed. In the above image, the user has actually made a couple of errors, but the copy and icons don't communicate the error at all - it just looks like a minor hiccup.
Are you sure pop-up
Listening to users, going against UX canon. Although it's UX canon that 'Undo' is preferable to this ugly pop-up, usability testing revealed that respondents overwhelmingly preferred having the pop-up as it gave them a sense of security of not having made any errors at all.
Brand mascot peeking out on success confirmation
Making interactions feel supportive and encouraging. One of the ways I did this was to use the brand's adorable mascot on key screens either as a a celebratory 'reward' (welcome and success screens), or on 'stressful' screens (ie. error screens). I also loosened the copy to be more casual to complement the character of the mascot. 
Validating designs with actual users and internal users
We only had the first 2 - 3 months to speak to actual users. This is how I adapted to the constraints: 
However, due to budget constraints, we only had the first 2-3 months of the project to speak and test with actual users. ¡Qué pena! In response, we had to be strategic with how we prototyped and tested.
Pen and Paper Prototypes with sticky notes
Validating key features, AI and flows with actual users across SEA
I prioritised getting the AI, main flows and functions right with actual users as these elements had the biggest impact on the usability of the web app.
I started with paper prototypes made in Balsamiq, then moved on to clickable Axure prototypes as we became more confident about the designs.
Prototyping in the Sketch app
Fine-tuning secondary flows with internal testing
To test secondary flows, I recruited colleagues from other departments who matched the profile of our users in terms of tech sophistication and role.
Clickable prototypes were made with Sketch’s native prototyping tool.

Act 3: UI Design

Modern but unique
We based the 'feel' on the aesthetic glazing most tech products today. We choose this aesthetic as it was most appropriate for our project goals and users. 
To make it 'Ninjavan', I worked around the brand colours of red and black to create a UI.
Designing in 2 week sprints
We worked in sprints developing the UI to follow the production cadence of developers. It is an approach I don’t recommend for creating UI because it leads to a lot of problems when components break with newly discovered use cases in each sprint. Many times I just felt I was walking blind with components.
Still, if you gotta build, you hafta build!
Designing for accessibilities
Accessibility was constantly at the back of my mind because... we're in the 21st century? But I wanted to design beyond WCAG web standards and for the accessibilities I was made aware of through the research. 
To do this, I did several accessibility checks while designing the UI:
WCAG checks
Checking for Colour blindness
Checks for Colour Blindness
Colour blindness was a crucial consideration as the logistics industry is disproportionately staffed by men, who have a 5.5%+ prevalence for colour blindness in Asia. 
Inputting different languages to make sure the component does not break
Checks for different languages and regions
Since the web app had to work for both long and short languages, and in all possible viewports sizes, it was important that components would not break when translated. To prevent this, I did 'stress tests' on components as I built them.

Act 4: Design System

Documenting all UI components in Sketch
Over time, we amassed a lot of UI components. I was responsible for managing, standardising and documenting. Using the atomic system, I documented components as atoms, molecules, and organisms. 
This document provided developers, designers, and PMs a common point of reference, thus making standardisation between design and code a lot easier.
Made in Sketch, shared with Google Drive. We made the system sharable to designers and the product team through a system of Google Drive + Google File Stream.
Establishing a shared practice with developers
Working closely with my developer squad, we created a way of working where the developers understood that my designs always referred to components in the code library they had built.
Shared knowledge of components was made possible through redlined documents hosted in Zeplin, and  introducing new components during fortnightly sprint meetings so that the whole team was aware of our current stock of components. 
Redlining a mobile component
New components were redlined and introduced to the whole development team during sprint meetings so that the whole team became aware of its existence.
A peek into the Design system. These artboards were uploaded to Zeplin after each sprint so that developers could inspect them and their corresponding components. The development team maintained their own corresponding code library.
Release to SEA
After 8 months of hard work, we launched in August 2018 to a group of beta users. Full rollout would take several months as our PM wanted to do the release in controlled batches across different countries. In any case, we achieved the following impact:
Merchants in 7 Asian countries using the redesign
Easier to use*
*Based on scores of Single Ease Questions (SEQ) from usability studies
Significant increase in user comprehension of interface
A formative project
This project taught me many things that I now utilise, such as working with Design Systems, working with developers, and adapting UX best practices to actual ground conditions.
Still, the biggest lesson was a personal one. It was my first job out of school, and I felt an enormous pressure to 'do well' — to prove to my team and myself I was a 'good' designer. At some point, it became very emotionally draining to do the work.
I still don't have a solution for it. There are still times I feel that way. I suppose we will never fully escape that feeling. 
But one way I've learnt to deal with this is to focus on effort and detach from outcomes. If we can accept we will sometimes not meet the expectations of others, and that it is alright and natural, we are then free to make mistakes and focus on the craft and process.
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram