Alegion Control

Website About Alegion Control
The Alegion Control logo.

Launching a data labeling SaaS product from scratch is no easy feat. And if you are going from "nothing" to "customer-ready" in five months it is all the more challenging. It requires rapid discovery, rapid design, rapid implementation, rapid everything. Our initial release did not include all the features we wanted and it was rough around the edges, but here's the bottom line:

Prior to launch it wasn't even possible for our users to create a project without assistance, much less generate their own training data. With the release of Control, someone who knows nothing about data labeling can create a project, create an ontology, annotate a video, and get their training completely on their own. For me, this is big a win.

🖼 Concept Art for Product Design

"Software as a Service" is broad in meaning. Alegion needed to understand what it meant for us, a company focused on data labeling services, so I found myself faced with the challenge of figuring out how to quickly and succinctly convey that meaning. My answer came in the form of concept art. Ralph McQuarrie and Yoshitaka Amano are two of my favorite concept artists. I'm fascinated by the dreamlike, protean nature of their work, and how it influences the final production. It dawned on me that there might be a parallel in what I was trying to accomplish for Alegion. But why concept art in particular?

Photo of Ralph McQuarrie's Star Wars art book.

As a designer, it's important to view your colleagues using the same empathetic eye with which you seek to view your users...your colleagues are also your users! Understanding what internal teams respond to is foundational to effective communication within an organization. I think my approach worked because I had learned that our organization responds better to rich visuals rather than conceptual descriptions.

Initial 'concept art' for the dashboard. Initial 'concept art' for the project page.

The SaaS "concept art" gave us an aspirational goal to rally around. This was important because, just like everyone else, we were all dealing with the stress and exhaustion of the pandemic and all the turmoil it caused. With a concrete vision to reference, the Product and Engineering teams were energized to embark on a major new initiative.

🛠 A Job to Be Done

At Alegion, the Product team bears most of the responsibility for deciding what to build. I facilitated a series of workshops that leveraged Clay Christensen's Jobs to Be Done theory to help us arrive at a product definition and to identify a prioritized list of features for the MVP.

JTBD Guidelines

A Data Science Team's job to be done is...

"Successfully train a model using trustworthy data."

We perform a customer's job when...

"We provide an end-to-end solution for a Data Scientist to create trustworthy training data."

Our biggest constraint was time: we only had a matter of months to define, design, and build our new offering. This meant we needed a narrow and well-defined scope of work. Alegion has three primary customer personas: Data Science teams, BPOs, and enterprise customers. We strategically chose to focus on Data Science teams whose needs, while complex, don't require the same degree of scale as the needs of our other personas. I established two design principles to guide my choices as I transformed the concept art into a fully specified product offering.

Design Principles

⒈ Don't Get Into A Busted State

The software should not have dead-ends. It should anticipate complexity and remain in a valid state at all times.

⒉ Remember The Future

The product must extend and scale as we learn from our customers and add support for new personas.

Creating self-evident workflows and clear interactions took precedence over other design activities, particularly visual design. I jokingly refer to the Control design language as "Some white, some blue, and some Roboto"™. 🙃 This will be rectified in a future release.

🦑 Creating Ontologies

A self-driving car is controlled by a ML model that has been trained on lots of dashboard camera videos. Before the model training can happen, a person has to label the points of interest in every frame of those videos so that the ML model knows what to pay attention to when it "watches" them. These points of interest are called data labels and they can range from “a person crossing the street” to “a car is changing lanes” to pretty much anything else imaginable. In Data Science parlance, the ontology describes the meanings of, and relationships between, all those data labels. Creating an ontology is complicated because it describes real-world situations…like all the things happening in a busy intersection.

I believed that making ontology creation frictionless would be a key differentiator for our product. This is where actionable design principles play a major role in guiding decisions. To avoid dealing with invalid states I designed the creation process to provide sensible defaults when a new element is added to the ontology. Additionally, our internal tool for creating ontologies requires hand-coding JSON, and there is no easy way to visualize what it looks like. Control provides users with a summary screen to make it easier to understand the ontologies they build.

The Control ontology screen.

Determining the ideal structure for an ontology is an iterative process; it takes time to discover the best way to represent information. We wanted it to be easy for a user to make changes and see how it affects the resulting training data. To meet this need we created a preview mode that lets Data Scientists see ontology changes in real time, create test labels, and even download a sample of their training data before beginning their work.

The Control ontology live preview screen.

🗣 Responding to Feedback

We were able to conduct a scrappy round of feedback before launching. I was grateful for this because it uncovered two areas of significant confusion that we needed to address. First, because we were not able to launch with a dashboard and on-boarding features, people were uncertain how to get started. We solved this by using AppCues to created an optional "Your first project" walk-through.

The Control FTUE 'Welcome' screen.

Second, we had to cut certain ontology features from the initial release. Some of the screens were so similar that it wasn't clear to the user that they had moved from one state to the next. We addressed this issue by using CSS animations to provide motion-based visual context.