Non Featured

PROBLEM STATEMENT

Koverse is a Seattle based platform used to manage, normalize, and interpret large and complex data sets.

The original platform was built in 2012 with a focus on the extract, transform, load (ETL) process of combining and normalizing data.

Over the years as new features were added on to the platform, they had been added on in a siloed or piecemeal fashion. This made the tool work for one-off tasks but was not very effective for an end-to-end data processing workflow. Koverse was looking to remedy this.

APPROACH

USER INTERVIEWS

Because none of us on the design team were data scientists ourselves, we needed to talk with data scientists to understand their mental models around processing data, and what workflows were more or less common to people in the processing stage.

We spoke with 18 people with job titles ranging from Data Analyst to Business Managers, and then sorted what they told us into common groupings using affinity diagram sorting.

PERSONAS & JOURNEYS

The affinity diagram sorting allowed us to group common responses into themes, and to see how the people with different job titles and roles all thought collectively about the data processing part of their jobs.

From these groupings of responses, and different workflows people had walked us through, we were able to assemble in depth personas for the different roles of people who would likely be interacting with this tool.

FLOW DIAGRAMS

Using our persona journeys and competitive analysis as guides, we set to work mapping out the workflows that would become the main paths the new tool would be designed around.

With a tool this complex, and solving for such a complex set of workflows, it was imperative to diagram out the functionality and the main goals the users would be trying to achieve before jumping into screen level design.

CONCEPTS & WIREFRAMING

We settled on a left rail menu paradigm that would keep context continuity throughout the tool, and a main workspace where the user could go step by step through the data processing workflow.

This series of screens shows the concept of a three-step wizard flow for importing data into the platform.

GOING DEEPER WITH COMPLEX TRANSFORMS

One of the big challenges with the Koverse interface is that the tool allows for transforms of the data (rules for how to systematically manipulate the data) to be chained together. These transforms could be selected from a list of common transforms, or written custom in Python.

With many data transforms in a row, the data flow becomes very complex to think about and control.

We did multiple rounds of sketching for the transform workflow, trying to make the experience intuitive and cut down on the vast cost of trial and error with large data sets. Here is one sketch and a Balsamiq wireframe exploring the interface we ultimately landed on for the design.

TO CODE

Once the core elements of the design were wireframed, we went into a more ‘sketch to code’ phase where the prototype was being built in code and running with dummy data.

The prototype was built with Angular JS Material, and we tried not to stray too far from the default components for the sake of time and efficiency. Working this way allowed us to finish each sprint we were working on with fully functional code that Koverse could then use or test further.

As the design and prototype was being worked out and built, the visual designer on the team was working on a parallel path to style the interface from a component standpoint and provide a comprehensive style guide as trailing documentation. 

PROBLEM STATEMENT

Austin Eastciders is a hard cider beverage company in Austin, TX.

They wanted to produce something simple but fun that would be interactive on a mobile device to centerpiece a social media campaign and promote four new flavors of cider they were introducing.

APPROACH

MEETING AUDIENCE WHERE THEY ARE

The marketing of Austin Eastciders is built around conveying a fun, social, summertime feeling.

We were very familiar with the brand after designing their website and online store, but when thinking about what kind of campaign we could run we began with re-examining the audience we would be targeting.

It was by kicking around ideas of what would appeal to the audience that we landed on the idea to produce a simple, interactive mobile game that could be easily promoted through a social media campaign.

FLOW DIAGRAM & NARRATIVE MAPPING

With the general idea of the game in place that the user would need to interact with the ingredients to help ‘create’ the new ciders, the next stage was to figure out the mechanisms of how users would actually create the cider, and the challenges that would confront them.

We sketched different ideas and landed on an idea where the ingredients would float around the screen and the user would need to ‘tap’ on them to crush them into cider.

This fit multiple levels of what we were trying to accomplish – a coherant storyline, the depth of commitment by a user would not be too high, and the gameplay difficulty could be adjusted based on the speed of the ingredients floating around the screen that the user would need to tap.

PROTOTYPING THE HAPPY-PATH

From the wireframes, we worked with the visual designer and the existing Austin Eastciders brand elements to develop a simple prototype of how the game would look, function, and behave.

The prototype was built quickly and only designed around a single happy-path.

The purpose of prototyping this was was to make sure we captured key elements of the game narrative, got the behaviors of the interactive elements right, and also were able to discuss and get good feedback from all project stakeholders.