Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Big Little Robots
Lead Product Designer & Strategist
The goal was to both streamline and centralize access to both critical supply chain information and important information, like documentation and reports.But, with that centralization also came the challenge of segmentation.
We needed to find the best way to not only combine an incredible wealth of information (including 11,000 daily reports), but also how to protect that information between different user groups (executives to analysts) without sacrificing the usefulness of the application for each individual segment.
We began with a series of exploratory calls, each one diving a bit deeper, with a few more specifics, to even grasp the scope of the project or the types of content we needed to organize. It wasn’t until after these conversations that we even began on defining the scope for the exercise.
In the initial phase, the priority was to define the scope and functionality of the platform. It just wouldn’t be possible for anyone to understand the entire magnitude or scale of the data, so we focused on understanding types of data (charts, inputs, documentation, etc) and groups of data (logistics, transportation, etc).
My team’s role started with creating the architecture. We began by listing every type and group of data we were aware of. From the beginning, there was a need for a systematic approach to prioritize features based on their value-add to the platform versus their complexity. We grappled with balancing the inclusion of strategic information against the accessibility of tactical data, devising a litmus test to gauge each feature's significance. Through iterative discussions and visual diagrams outlining different organizational pathways, we ultimately refined the platform's requirements.
Eventually, we went from loose wireframes and undiscriminating lists to a basic architecture.
We answered lots of questions during this process:
How do we define the dimensions of interactions and permissions with the data? We eventually decided on Seniority, department, and country.
How do we define the different user groups, and are there overlaps between certain levels, like Regional VPs and Warehouse Managers? Do we prioritize data points based specifically on business value, or prioritize what is the most frequently used? What metrics are important cross-company, and how do we define categories that fit into this (for example if planning and transportation is important to logistics, do all levels of logistic operations need access to cross-company functionality as well as siloed data reports)?
After spending several weeks refining the architecture and addressing any issues, such as missing categories or overlooked user group permissions, we moved on to the UI design. We started with wireframes, which were closely aligned with the architecture and centered around the most critical element: the navigation. These wireframes then evolved into the final UI design.
We explored several design approaches for this. Should each category display cover images for deeper layers, or should reports be immediately visible? We also debated whether to offer customization and themes—though this raised concerns about usability. With so many reports, what if a certain color theme made the data unclear or ambiguous?
Given the complexity of this project, and the sheer amount of changing reports, we did not design every screen, simply just the system, based on several screen examples. This final handoff piece documented the guidelines and the flexible system meant to create the framework for data reports and management for years to come.
This project was a collaborative effort between the team at Big Little Robots and my team at Klyxx Creative.
2024 | Victoria Gunell
