Supply Chain Management Application Designs

My Role

I spent most of my time organizing peoples thoughts into coherent diagrams that could help communicate their ideas. Workshop after workshop I’d drive out insights and plans that could be shared with the rest of the team and guide the product forward. I’d use this information myself to build out the interface.

In this role I mastered Sketch and InvisionApp together to bring ideas to life quickly, gain feedback from stakeholders, and catalog reusable design assets for the broader team. The majority of the visual work was set in place by the director of design who created the initial art direction of the app.

Brainstorming

When a team had a new idea for a product I was the one the PM team flocked to for fleshing out those ideas. Asking people to put a marker in their hand and use it to explain the problem, types of users, and the overall flow of how it fits into our product ecosystem. A lot of my meetings were making things go from this:

Create Requirements & Metrics

Product managers have all the ideas but few of which know how to translate that into instructions for developers. I’m good at listening, digesting, and sorting that information out into a plan that teams can point to and offer feedback. If you don’t have blueprints then whatever the developers interpret isn’t wrong.

Create Visual Flows

If the idea’s fully captured I get the dev team to run through the feasibility of it. After that I run through some rough wireframes (metaframes) that show how you flow through the app without being too detailed. This gets the ball rolling on setting expectations.

Design UI Prototypes

User Testing

Pull in real customers and have them test your ideas in a prototype. The small details the team glosses over are usually the things that trips users up the the most. By testing and validating these components you can take them back and reuse them.

Create Developer Documentation

Rinse & Repeat

I followed roughly the same process in my time at this company; some with variants in between based on content. Let’s take a look at a few other projects that I worked on.

What problem are we solving?

In the space of supply chain management there’s a lot of data but there’s only two things people really care about: is all of my stuff here and was it on time? You can drive a lot of visualizations around that, many of which only satisfy a few customers, but I wanted to keep things clean.

People can’t easily find this information using existing tools; spreadsheets and out of the box software. We needed to figure out the right problem to solve and focus only on that. No other shiny objects to chase or customers to upset.

Dive deeper into data

I love visualizing data like this; a focused view on one thing and seeing how all the angles affect it. Convincing managers and product owners that a simple, focused, multifaceted view was not easy but in the end provided to be viable. Think of Mint.com’s take on showing how you spend your money and where it goes.

Customer Scorecarding

Who’s the best customer you have today? Who’s the worst? Without knowing the numbers I bet any business owner could give you an accurate answer. Could looking at the data change your mind and the people you chose to do business with?

The goal of scorecards is obvious; see whose performing well or poorly and explain why in an objective way. I had a lot of fun designing out report card style visualizations for showing good and bad partners.

Insightful data

Bring customers information that will change their behavior. Show them whether things are getting better or worse, slower or faster, and why that could be happening.

Consistency Issues

Handing assets between teams can be like playing a game of telephone; each team makes small assumptions on the small details which pile up into design debt. This happens between designers and designers + developers. The value in making a system is that no one is doing double the work; a component is designed/developed once and shared.

I lead the team on a journey through creating a comprehensive library outlining every detail of each component to make sure everyone’s in sync. This made the team move faster in design and development by doing more wireframe handoffs instead of full comps.

Component States

Each component needs explicit instructions on what’s to happen in different circumstances. Below is a small preview of a few components from the forms/inputs section. What does a component look like when it’s clicked but the user hasn’t entered data? What if it’s a required field but needs validation? There’s a ton of work defining all these states and making sure they all compliment each-other.

Component Schematics

Documenting states and permutations is the first big step to wrangling components. The next is being very detailed in what the developers need in order to build it to spec. Depending on the eye for detail of the developer you’re working with; you may get away with using Invision’s Inspect tool, otherwise you’ll need to spell out every single detail in exhaustion.

Creating Guidelines

Easy to find, up to date documentation is crucial for keeping the team on the same page. It’s a pain in the butt and most companies don’t understand the value but it’s a vitamin worth taking for your product to stay on track.

This end result speeds up the entire process of building products by allowing the team to focus on the problems instead of the minor details of the solution. Designers can wireframe solutions with managers and developers can translate sketches into existing components.

UI Components

By combining elements together the UI became easier to innovate, test, and go to market with. Here's a handful of examples and iterations of the various user interfaces I built for the platform and for individual apps.

Redesigning the Supply Chain

A series of projects from a large platform for helping business order, ship, track, and analyze their products.