Food SamplingDashboard

An awesome application redesign for a company that dispatches representatives of food brands to popular stores to give out free samples and record customer behavior.

User Research

A solid client that wants to know what their users want and most of all; what they need. A client like this is a rare but amazing one to have. I did my homework on the application and what the business does to make money and what they will do to make more. To help the client I ran a workshop to further understand the business targets and distractions for this short engagement. This is a piece of post workshop documentation that displays the clients strengths, weaknesses, opportunities, and threats.

By having the client verbalize what the job duties of each employee does, I was able to segment out who needs the system improved the most in many different ways; job type, tenure, and so on. The client sent me down this road:

With the audience of interest being vast, I sent out a quantitative survey asking all employees what their behavior is like. There was a wealth of responses that conflicted with the businesses understanding of what the employees need. They weren't far off from the target, but as we see in the graph below there is some interesting information on how the busiest of people may not be the best.

The client initially wanted to add mobile support out of the gate because of blinding use of mobile devices. I was in their favor, only because I love designing for both, but suggested we see what our users technology allows for. We also learned that phone usage during demonstrations was discouraged.

With both qualitative and quantitative data in hand; I produced a matrix of characteristics, behaviors, problems, and requests by the main 3 types of users of benefit. Overall the current application was ok, but the users were really tolerant of the system due to how good the management is to their staff. A new system with basic usability fixes like entering dates properly, ability to retrieve your password, and easier uploading of documents.

From here we start getting serious; we have our business and users thinking about the same needs. Now it's time to extract data for the application.

Information Architecture

Before I do anything visual, I try to extract key points of data from the stakeholders or existing applications. Knowing when to ask for more information on a topic is tricky, but I feel you can cut through the company nomenclature and find a schema for a database. This example is a visualization of the entire database that any client can understand.

The simplicity of the information is visible when zoomed in to help trace routes with your finger. I found this useful homework to give to the client in regards to how something works. These are great for conditional information or showing the relation and hierarchy of the information. This is huge if you can have a coworker who digs databases and have give you help on structuring it. (Instead of later when the real database ruins your process flows) If you can get both your developer and client to work together to talk about the organization of information; you can build solidly on top of that architecture to show how all that information is strung together contextually.

Process Flows

Before I do anything visual, I try to extract key points of data from the stakeholders or existing applications. Knowing when to ask for more information on a topic is tricky, but I feel you can cut through the company nomenclature and find a schema for a database. This example is a visualization of the entire database that any client can understand.

The simplicity of the information is visible when zoomed in to help trace routes with your finger. I found this useful homework to give to the client in regards to how something works. These are great for conditional information or showing the relation and hierarchy of the information. This is huge if you can have a coworker who digs databases and have give you help on structuring it. (Instead of later when the real database ruins your process flows) If you can get both your developer and client to work together to talk about the organization of information; you can build solidly on top of that architecture to show how all that information is strung together contextually.

Interaction Design

Visual Designs

Normally we design moodboards to get further insight into the brand details, but this company was very happy with both set brand fonts, colors, and images and open interpretation for a web UI. The visual designer and I took key screens from the wireframes that displayed a deep level of interactions/states, modular components that appear on other pages, and pages of high priority.

Application States

The best part of working on applications like these is that creating components that you can reuse to enforce design consistency and make your front end developer happy. Each component is pulled from the wireframes if it's shown on many different pages and is a high traffic interaction. Below are some examples that both Jake Haugen and I created together:

Related Projects