Ellipsis product design and development

Over three years as a co-founder of Ellipsis, I worked on designing and building all aspects of the product.

Product concept

Ellipsis was a platform for workflows that connect people and systems at the workplace together through a conversational interface. My work split into two distinct areas: designing and building the developer/administrator platform used to create and manage workflows, and designing the end-user experience of using the workflows.

The developer platform

In our initial concept of Ellipsis, we imagined that in time, external partners, developers and customers would build and adapt their own workflows. We built a web-based developer product to create, edit and manage workflows, and beta-tested by building workflows with it for our initial customers. The goal was to make something that we were happy to use ourselves and that made it easy and efficient to build and deploy new workflows.

From my experience working at Change.org, I knew that a flexible but consistent pattern and style library would accelerate our work as we tinkered with the product by reducing the amount of one-off design. To that end, I designed a set of base styles for colors, typography, layout and interactive components, oriented towards our product needs, and then wrote a CSS library for use in production.

As the platform product grew in complexity, I felt it was critical to uphold system-wide consistency in key visual details like the design of buttons and form elements, and key interactions like popup content and notifications. I also put a lot of thought into the use of modal versus modeless workflows.

In addition to the design itself, I also did the vast majority of front-end development, working in Typescript and using React to build all of the interactive functionality.

As Ellipsis evolved as a business, offering the developer platform to others became a lower priority, but our focus on the usability of the platform nonetheless made it much easier for us to create and adapt workflows very quickly for new customers, enabling us to deliver results in days instead of weeks or months.

The conversational interface

The core experience of Ellipsis for customers was in workplace chat products like Slack, interacting with a chat bot that requests information, assists with workflows, and delivers results. We put a lot of time into honing these interactions, with a particular focus on three areas: conversation "state", data input, and managing interruptions. We tested the bot extensively with customers and collected feedback to improve it. Our goal was to make the bot's presence in group chat feel as natural and non-disruptive as possible. It should not call unnecessary attention to itself, but instead be there when you need it and be invisible when you don't.

Conversation state

Because the Ellipsis chat bot ran in group channels, we were very sensitive to the need to make it clear at all times who the bot is addressing, what should be expected to happen next, and how to deal with overlapping dialog. In order to handle this, we designed a technical model of a "conversation", representing a specific workflow from start to finish with a specific person in a specific channel. The bot maintained awareness about many conversations at the same time, even with the same person.

For example, most of the time, if someone started a workflow in a group channel, only that person could complete it, so the bot always replied by name to that person. If a response took a noticeable amount of time (e.g. because it needed to retrieve data), the bot started by acknowledging someone with an appropriate emoji reaction. If a workflow required several steps, the bot transfered the conversation to a dedicated thread or offers a dialog to speed up data entry. If a workflow involved sensitive information, the bot moved the conversation to a private channel without losing the original context.

If someone had an existing workflow conversation open, and the bot needed to interrupt to start another one, the bot could put the first one "on hold" in a separate thread, and maintain clarity about which workflow the person was in at any moment. If someone started a workflow but didn't complete it, the bot could remind them later to finish it, providing a graceful way to pick up the conversation when they were ready.

Graceful data input

Workflows were structured around inputs and output. For many workflows, the bot needed to get information by asking questions. Part of the design of the system was ensuring that people could answer questions as effortlessly as possible, with the bot guiding someone to provide the right kind of answer (e.g. "yes" or "no", a number, a date, or a choice from a list). In many cases that meant trying to interpret text someone had typed (so, e.g. if someone typed "today at 5pm", that was interpreted into a precise date and time), but in other cases, the bot provided buttons to click or a dropdown menu to select from. The bot could also understand the same response provided in different ways (e.g. someone clicking "Yes" or typing "y" or even "sure"). And if the response seemed unsuitable, the bot tried to provide additional hints about what it expects.

Interruptions

Some workflows ran on schedule and required input from someone. First the bot sent a greeting to set context, and explained what it needed to complete the workflow. Our initial approach on this had the bot ask a question right away and wait for the person to respond, but through customer testing, we found greater satisfication and workflow completion when the bot instead offered people a button to begin the workflow at their convenience. This also freed up someone to have other conversations with the bot before beginning a scheduled workflow. A simple reminder prompt could be sent later if someone didn't click the button within a reasonable amount of time.

Getting the work done

The aim of Ellipsis was to help people get work done more easily and more reliably, with less training. Over time, we found the most success helping people with a few specific kinds of problems.

One common problem was collecting specific kinds of information and ensuring it was saved to the right system and the right people were notified, often with follow-up actions to take. For example, one customer used it to collect reports from employees about dangerous conditions in facilities, and over time, they used the same workflow even while easily changing the underlying system used to store the reports. A similar variant Ellipsis was effective at solving was guiding people through a regularly-occuring manual process, to ensure completion of critical steps and recording the results to a log. The conversational mechanics and the developer platform made it easy to customize these workflows and tweak them over time, without re-training employees. —L.A., November 2019