Hi! I am
Discovery
A live GPS intelligence system that monitors logistics operations. It links multiple data providers into a single map so users can see their country-wide business in one place.
The Team
Project Manager
Product Design Lead
Project Manager for Integrations
UI Developer
Solution Architect
Technical Lead
Tools
Microsoft Teams
Project management and coordination.
Apple Keynote
Wireframes and hi-def prototypes.
Affinity Designer
UI assets.
Google Forms
Client feedback and surveys.
Program Brief
Cost is the Achilles heel of an industry with traditionally low margins and extremely high service expectations. A company that can reduce its wasted time or increase overall output can gain an immediate advantage over its peers. A system may be needed that can let logisticians fine-tune every trip down to minutes, thereby keeping its vehicles running for the most possible time.
Timeline
The core product development was an eight month endeavour, spanning from July 2019 to February 2020.
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Research
Design
Development
My Role
I led the design and concept development of this new product, and worked alongside four colleagues and an external consultant to launch it in the market. My specific duties included:
​
-
Coordinating interviews and other research activities
-
Defining the feature set and information architecture
-
Designing its UI and overseeing its conversion into HTML
-
Enabling the Project Managers to oversee the development
Company's Goals
To expand into untapped segments within the logistics market.
Readily integrates with any 3rd party system, to provide a foothold with customers outside our ecosystem.
To cement our brand image as an innovative technology provider.
Research
Discovery centred around a known pain point, shared by many of our existing customers. While using GPS devices had become a norm, we kept hearing from customers that it wasn't helping them improve operations. So my team and I set out to see if that data could be put to better use.
The positioning the product needed, in order to justify it in the market.
Market Analysis
To properly understand what such a product should do, we wanted to see what other companies have tried. We started at the source, by researching what GPS service providers are offering as part of their complimentary systems. They were, in effect our indirect competitors.
​
When we searched for our direct competitors, we weren't able to find an exact match. We found a few aggregators, which help set a minimum feature benchmark, but it soon became clear we would need to explore our own path.
Forming a Hypothesis
Before jumping into customer interaction, we interviewed internal subject matter experts, who integrated GPS tech into our products. They helped us understand what data is available and what our customers use them for.
​
We learned that simply knowing live locations didn't help them much; the fact you are late doesn't (1) tell you why, nor (2) what to do about it. This, for a few, made GPS more of a CRM tool than a source of insights.
​
Our initial product idea thus became the combination of live data with actionable insights.
Understanding Potential Customers
While I conducted interviews throughout the development lifecycle,
my initial research involved five rounds of qualitative interviews with three organizations, ranging in business size and type. I interviewed a range of potential users, at multiple levels of the corporate hierarchy.
​
This gave the team an idea of the problems our customers were facing.
We're sitting in central command, [so] whatever processes we have are only as good as our ability to enforce them.
— A rightfully frustrated business head
A resounding feedback we gained from managers was, even if they were to know what went wrong, and why, they couldn't change anything until there was accountability.
This is when we realized their biggest need is control, and not just visibility.
Personifying the Users
THE FOCUSSED
Ravi
He lives his life one day at a time. He is smart and hardworking, but is only concerned with his own job. Change is usually handed to him.
Product Buy-in
Needs
-
Clarity on expected output
-
Stability in job and daily work
-
Ease in tracking pending tasks
Motivations
-
Running a smooth ship
-
Having universally good relations
-
A stable annual increment
THE PROCESS GUY
Cyrus
He is a result-oriented person, and is mindful of his career choices. He is fine with changes as long as his work is not complicated.
Product Buy-in
Needs
-
Full authority to execute his job
-
Making his work life easy
-
Dependable workers & vendors
Motivations
-
Increasing his team's output
-
Rising up the corporate ladder
-
Networking opportunities
THE GO-GETTER
Vikram
He loves new ideas, anything that improves his business. He is very detailed oriented, often wondering why things can't be done better.
Product Buy-in
Needs
-
Business clarity through data
-
Visible change in limited time
-
Team support and accountability
Motivations
-
Increasing operational profits
-
Maintaining business reputation
-
Making a mark in the company
Getting to the Heart of the Problem
A journey map I developed in collaboration with the sales team, following the thoughts of the "product evangelist."
Predicting the Adoption Journey
During the interview phase, I identified our product's adoption is not going to be as easy as we thought. We might convince the manager writing the cheque, but they too would have doubts about its success. This is because this wouldn't be their first crack at bringing accountability to their company — employees just hate being monitored. For example, drivers unplugging their GPS devices en route is considered unsurprising. Discovery needed to overcome this problem.
​
​
So, we started by listing the biggest hurdles to adoption, which also informed our messaging:
Acceptance by Employees
Deployment of Hardware
Integration with Customer ERP
Support by GPS Vendors
Mapping User Emotions
The biggest hurdle was related to trust in the system. To solve this I needed to understand what users really thought when dealing with business problems independent of such a system. This helped the team better pick features to focus on.
​
In the example shown, I mapped the thoughts and concerns of a 'traffic agent', whose sole job is to monitor vehicle movement.
Quantifying how users think, so as to address it in design.
Defining the Product's Feature Set
Once we had a fair idea of what our customers expect from such a product, we set out to create our WBS. I took the lead here, by first defining feature areas and then working with the team to convert research insights into user stories. Below are three examples:
A representative sample of user stories developed during the planning phase.
Design
Half-way into our research process, we had enough data to start visualizing the product. That initial design then went through several revisions and tests until we were ready for commercial launch.
Transferring Ideas onto Paper
In a typical drawing on a paper napkin method, I doled out several sketches of the skeleton product. The designs became elaborate over time, but each stage gave our team a better idea of the data, layout and navigation that we felt was appropriate.
Some of the later-stage wireframes of Discovery.
Building an MVP
Despite a generally positive interest, we weren't sure how many customers would actually pay for such a product. So we prepared a mockup presentation, which our founder used to demonstrate as a new system "in the works." The initial response itself was enough for our Technical Lead, Shashank, put together a stock version for further live demonstrations. And it was worth it because we funnelled the input and reactions it received back into the product's development.
A screenshot of the MVP, functioning with live data.
Above, are two interactive wireframes which I used to test how the panels would look and function. We came to the conclusion that three tab groups was the upper limit for a touch surface while testing. The animation demonstrates how these panels would slide open on each device category.
Interaction Design
From early on, it was clear to us that there would be packets of data that were only relevant at a particular instance of time. This meant, that I needed to build a repeatable method to invoke relevant packets when appropriate. This led me to design 'info panels', that slide in when the user interacts with the system.
The shape and structure (tabs) were chosen to work well on both desktop and mobile layouts. There would be no more than three tabs at a time, and extra content was scrollable.
Concept Verification and A/B Testing
Throughout the design phase, we had an open communication with our research customers, who helped shape this product through feedback. On some occasions I ended up tweaking the process upon verification, when I showcased low-fidelity prototypes to sample users. On other occasions, as shown below, I selected the user interface preferred by a majority of users (using the A/B testing method):
Viewing one panel at a time
Viewing data from all panels
Viewing one panel at a time
Least Preferred
Despite having richer data and the flexibility to mix and match multiple filters together, most users did not like this design as they found it too complex to work with.
The learnings from this helped us develop a dedicated 'filters' modal that mimicked those from e-commerce websites. It was readily welcomed by test users.
Most Preferred
Most users intuitively understood how to use this design and were able to parse the information provided. Despite having the same data as the other design, the familiar tab structure was preferred by users. Furthermore, this layout gave us an opportunity to add more tabs at a later date.
Creating a Core Design Identity
Challenge
Similar to ride sharing apps, Discovery has a map with vehicles dotted around. Unlike the first case, vehicles are highly diverse in type and status, both of which need to be conveyed.
Resolution
Creating individual graphics for all types of trucks was out of the question. So I created a concentric circle system to both look good and be discernible with 100s displayed together.
These markers may look simple but they share a lot of details in one glance.
The colour of a ring changes based on the status of the vehicle.
If any vehicle is facing an issue, a light orange ring pulsates around it.
The contrasting arrows make it easy to identify whether the customers own the vehicle or not.
In the end, there was such a strong association of the entire product with the "little coloured arrows," as one of the beta-users put to us, that I later incorporated it into the retail logo of the final product.
Putting it all Together
I then made mockups of the product as a whole. I intentionally chose to keep things simple because the target audience couldn't care less for anything elaborate. On the contrary, our research with low-def mockups showed a strong correlation between trust and simplicity.
​
I focused on the core experience of Discovery, i.e. elements users would interact the most:
Search
Alerts
Review
An animated preview of multi-layered search
A quick and easy way to search for multiple entities at once. Users can simple enter one or more (a maximum of three) query items and the system will directly filter the data on the screen. Any associated panel will open as well, which lets the user zoom into the item(s).
As a whole, this lent to the creation of a clean structure and navigation across the product:
Designing the User Interface
After months of research, ideation and wireframing, I was finally ready to create the first hi-fi look n' feel of this new product. I put together mockups and animated prototypes to test the system's flow for one final verification round, before the team proceeded to development.
A screenshot of the icon in design, using Affinity Designer.
A screenshot of the prototype in design, using Keynote.
Development
Once our designs passed rigorous internal testing, we finally moved on to the programming stage. We already had a base ready, thanks to our MVP experiment, so we expanded on its code, one iteration at a time, until we had a ready product.
An early live/HTML rendering of the system.
Building Discovery
Initially, we split the development into two projects to run in parallel. The first was the creation of the UI, led by Dhawal. The second project involved the development of backend processes and over 100 API integrations. That was led equally by Akshay and Siddharth, who worked with Harshad, our development head for Discovery, whose team continued working on the MVP's makeshift UI.
​
Once we made enough progress, we merged the teams for further development.
Technology & Beta Testing
Discovery was built on a host of advanced technologies. We used Microsoft Azure's technology stack to manage the storage and analysis of data. In particular we used Streaming Analytics to parse millions of data points per day (per customer), and identify anomalies to generate alerts. For searching and filtering, which were integral to the system, we used Elastic Search.
​
We approached the development of Discovery in three releases spanning two and a half months. Each of these releases was published to participating customers, who used it as part of our free beta program.
Product Launch
Once we were satisfied with the stability and feature set of Discovery, we immediately went ahead with a "soft release." This made it a billable product while we worked towards a traditional market launch.
​
For the launch, I worked closely with the marketing and sales departments to define a consistent message. The research we conducted also contributed to the market segmentation. Discovery was targeted at not just our existing customers but also at both customers of our competitors (to cross-sell to) and with customers which we had no previous relationship with.
Outcome & Future
Discovery launched under unprecedented conditions in the market, which caused us to change our initial projections for sales and usage milestones.
That said, we did have some outcomes to brag about:
Two of our test participants became billed customers on day one of going live. One of the customers is the world's largest logistics company, that plans to expand Discovery into its other markets.
It is already the company's No. 1 product, in collective data processing; is on track to become No. 2 in revenue.
Discovery has customers in 2 countries and has given the company its highest record of prospect interest.
As on June 2020, I had moved on from the core team to other assignments, but the program has picked up pace. Discovery is already on its fourth major release, with big future plans.
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!