Problem
Users were using Elementum to monitor supply chain elements - shipments, orders, inventory items - however the user adoption wasn't sticky or consistent. Leadership was looking for a way to provide the value that would support user needs more consistently and holistically throughout their supply chain challenges and remediations
User Needs
Users used Elementum to monitor and track supply chain objects. For example, if there was a concern about a shipment being late, they could log into Elementum to confirm the status of the shipment but they would remediate the problem outside of the product. We saw an opportunity to manage the remediation lifecycle more holistically within the product by introducing rules to proactively notify users of potential disruptions and incidents to collaborate with their counterparts around problems through remediation.
Product Challenges
The entire product had a information architecture designed around visibility. We wanted to validate this paradigm shift to rules and incidents quickly, with a modest development investment and without a complete rewrite of the product initially.
Personas
Administrator
Admins were responsible for creating rules when triggered, would notify and generate alerts to assigned users.
Operator
Operators received alerts for potential problems and could create incidents to bring collaborators together around a problem.
Team Lead
Team Leads viewed could escalate, reassign and monitor their teams performance around an incident.
Design Principles
One Platform
The surface area of supply chains span multiple functional domains - sourcing, logistics, manufacturing and inventory - and the complex organizations within each domain. For each supply chain domain, my objective was to find a common ground around actions and user archetypes. The purpose was to define an information architecture that could accelerate development without compromising the user experience.
Personalize
To support the various supply chain personas using the platform, we wanted to design a set of workspaces that were customized to their scope of ownership. We knew we couldn't design a custom workspace for each persona due to development resources and timelines but my hypothesis was that we could work off of persona archetypes. In other words, groups of personas need very similar things and therefore workspaces could be designed for persona archetypes.
Speed
There were three outcomes we optimized for around speed: speed of user adoption, speed of user workflow and speed of development.
Information Architecture and Design Concepts
Designing workspaces for persona archetypes
Operational User Archetype
My analysis of our personas concluded that the first persona archetype that we needed to support was an Operational User archetype. This covered all users who operated tactically. These users managed and monitored stateful objects. For example, a logistics manager often monitor shipments. If a shipment had a status that was delayed, the logistics manager would attempt to remediate that shipment until it was back on time.
Strategic User Archetype
The second user archetype was strategic users. Strategic users often managed whole teams and departments of operational users where each user was accountable for a set of managed objects. By definition then, these strategic users were responsible for all the tactical operations that needed attention as well as the category of issues that represented higher-level supply chain risks. For example, a lead might own the partnership of the carrier responsible for individual shipments being repeatedly late.
Workspace Characteristics
Essentially, we had two types of workspaces: one for the general needs of operators and one for analytical users
Example Mockups
I designed several mockups and flows to prove how we might represent analytical workspaces for the different supply chain domains and how collaboration between analytical leads and tactical operators could occur.
Impact
This new information architecture was shared, first with leadership and then with the R&D team. The domain teams took this concept and customized it for their domains before conducting user feedback sessions and usability testing with internal stakeholders and then customers. 8 months later, we rolled out the first workspace (Inventory) which was very well received.
Reflections
-
Anchor on Users - While the objective was to pivot from visibility to a transactional system of record, the anchor was still on users and what they do. We were moving fast but always asking the question around user goals and how our decisions were making them more efficient.
-
Tiger teams and Ownership - We employed a tiger team at first consisting of the CEO, Head of Product, Head of Engineering and myself. While the rest of the teams were working on supporting legacy features, we were exploring new territory. It would have been my preferences to operate more transparently but ultimately the decision was made to not disrupt the teams until we had some answers. This approach required broader healing and made it more difficult for teams to lean in.
-
Systems Design - While thinking about things as a system naturally has the benefits of reusability and engineering velocity, the user experience was ultimately very uniform and set us up well to absorb into a design system.