LINK PLATFORM
Link is a supply chain management and lab testing platform tool for collaboration between the world’s largest footwear & apparel brands, their suppliers, and their safety/quality testing laboratories. Detailed screens and prototypes are not available due to proprietary reasons. For more product information please visit the company’s site.
THE PROCESS
UNDERSTAND & OBSERVE
The goal was to create a dynamic platform for brands to manage the lab testing requirements required of their supply chain. I gathered requirements through interviews with the product owner and a seasoned developer of similar custom-built software systems. Using the key points from these interviews, and similar but custom software as an example, I was able to identify key product requirements.
Three main user types were identified, and seven major goals to achieve within the product. These goals, or focus areas, were named and split into manageable chunks called epics.
DEFINE & IDEATE
Starting with the main epic, and assumed to be the most common goal of the platform, I mapped out the user flow for all three user types. This was done using Post-it notes, with a separate color for each user type (see image below).
Using the user flow map, lo-fidelity screen types were then wireframed on the whiteboard for each task/Post-it note. Now the core types of screens, or main components, could easily be identified and it became clear some components would be used in multiple places.
Using the lo-fi’s, I made mid-fidelity collages in Sketch to further flush out the details before getting too deep into making symbols. Making collages is a quick and valuable way to include a mix of current and inspirational UI to better flush out the components before any painstaking pixel-pushing is done.
At this point, these findings were reviewed with team and stakeholders to get sign-off before moving forward.
Identifying the main component types, such as tables, made it easier to begin the hi-fidelity design.
PROTOTYPE & TEST
UI design decisions for Link were previously agreed upon by the team including the brand colors, font (roboto), and to follow Google Material Design principles. Using these rules and the mid-fi’s as guidelines, I created the hi-fidelity screens. These were often fully or partially reviewed with the team and stakeholders before prototyping.
Because the mid-fi’s helped to identify the main components, and those could be added as another building block to the UI library, it enabled much quicker hi-fi design iteration.
It became evident over time that reviewing just the hi-fi screens alone with the team or stakeholders was not as effective as a prototype because of the lack of context. Truthfully, sign-off on each stage up to this point came more easily than when reviewing prototypes or the site in production. I believe this was because of simplicity and/or lack of context.
The hi-fi screens from Sketch were then uploaded to Marvel and prototyped - the ability to sync the screens to Marvel from Sketch using a plugin was invaluable.
The ability to sync the screens to Marvel from Sketch using a plugin was invaluable.
To start, hi-fi’s images or prototypes via a Marvel link were presented to stakeholders for sign-off at the End of Sprint reviews. By the third or fourth sprint review there were more updates to present (such as the development progress) and so I created those updates with slide decks using Paste. Embedding the prototypes into the slide decks allowed for adding additional context and value by being able to split prototypes up, show them in a sequence, and add written detail or screenshots.
I collected feedback from all reviews and presented the findings to the Product Owner and Project Manager. Decisions to address next, put in the backlog, or disregard were often made collectively based on the product roadmap, and filed in Jira.
The End of Sprint reviews were valuable, but better feedback could have come from the stakeholders navigating the prototypes themselves. Stakeholders were often only presented with the prototype as I or another team member walked through it. This allowed us to provide valuable insight behind the design decisions, but meant that they were never fully engaged enough to provide feedback. This came out later when they were able to walk through the UI in the production environment and had a lot more feedback on the flow and the UI.
BUILD
Sprints were 3 weeks long, and design sprints were a sprint cycle ahead of development. This meant that typically designs would be validated at the end of the sprint and handed off for development to begin the very next sprint. When design work received validation (from the team, product owner, and/or stakeholders), I wrote detailed tickets in Gitlab to hand-off to the Development team.
More often than not, follow-up discussion via the daily development team checkins, Gitlab, or email were required.
EXPERIENCE & GROWTH
TOOLS
Jira, Post-it notes, Post-it Plus app, whiteboards, Chrom Dev Tools, Sketch, Marvel, Pasteapp, Gitlab
I LEARNED HOW TO
Derive project requirements from conducting interviews with the product owner and through frequent stakeholder communication
Design within Google Material Design rules and constraints (learning when to adhere to and when to ignore)
Communicate design requirements with developers - both local and overseas team - using Gitlab
Deliver design within an Agile development process using 3 week sprint cycles
Prepare presentations to update customers with at the end of each sprint
Conduct usability studies (prior to stable-product usability testing)
Manage and plan design tasks and deliverables using Jira
Have design reviews with PM, PO and team
KEY TAKE-AWAYS
Rework is often required, but constant communication with the development team, the PO, and stakeholders is key to building a product with less of it
Conducting any kind of usability studies before handoffs to developers saves time and effort
Trust the design process, but always be prepared to tweak your process
Define upfront if your customer is a stakeholder, or simply a customer
Organize your files so that anyone else can understand your system