Alpine Chorus is an enterprise application for data science that brings together data, people, and machine learning into one collaborative environment, allowing teams to manage the analytics lifecycle in order to build, deploy, and use predictive analytics for business insights.
When the project started, Alpine Chorus had reached version 4, and consisted of two pieces:
Version 5 launched with the updated design and improved ease of use. Over the next two business quarters, these changes were credited for a 10x increase in the subscriber base (as measured by user seat licenses).
As head of product design, I was responsible for all aspects of the redesign.
The redesign project provided an opportunity to both immediately improve the user experience of Chorus and to construct a longer-term product design vision.
To capture both the short term and long term goals, design objectives were articulated to describe and orient the project. These objectives were used internally, and communicated externally to let customers know about the direction and product design roadmap.
Each part of Alpine Chorus came from a different background before they were connected together; not surprisingly, the disparate parts did not match. The differences spanned many levels — from basic visual elements of typography, color, layout to higher-order interaction behaviors — resulting in a disjointed user experience.
Although there were multiple technologies behind the different sections, the product design principle was to present the application as a single product to the end user regardless of the technology.
Disconnection is felt by users instinctually and consciously. Successful unification is not noticed at all. It is transparent.
From the perspective of the user, the sense of unification — or disconnection — is determined by the visual, linguistic, and other experienced qualities of the application. Therefore, the primary project goal was converting both parts to have the same user experience, the same design. The new design.
In practical sequence, the collaboration environment was first converted, followed by the workflow editor. Reconciling and melding the applications spawned its own set of requirements and issues to solve, including:
A broad design objective, this imperative began with transforming the visual style to make the application more contemporary, approachable, and aesthetically pleasing. The application’s interaction behaviors were then analyzed and revised.
As a result of both historical development and lack of user-centric advocacy, Chorus had evolved to include a variety of egregious behaviors that hurt usability, from general web application issues to domain-specific problems.
On the basis of the initial design research, high-profile usability problems were identified and prioritized to be fixed immediately. What could not be solved in the first release was queued for subsequent fixing.
The redesign project provided the right occasion to define and institute a core set of product themes where none existed.
The product themes began to take shape during the initial design work and resolved more completely through iteration loops as the project progressed. After the first new product release, these themes were the foundation of product work in subsequent releases (until they were reevaluated and updated).
Strategic themes provide inspiration and context to answer questions of “What should the product do?” and “Why implement this feature?” They are a framework for a holistic product and strategic direction. They help make the right product/user fit.
Synthesized by design insight, and formed out of comparative/competitive research, the broad application environment, analysis of customer feedback, and the company’s business priorities, six motifs established the first product design vision for Alpine Chorus.
Design research at the beginning of the project (and iteratively throughout) set up a baseline for the product, using a selection of techniques appropriate to the time and resources available.
The results of these efforts provided a way for everyone involved in the project, and then everyone in the company, to gain a broader view of Alpine Chorus as it presented to users, to companies, and in the market; and to understand the design changes in those contexts.
One outcome of the research was an end-to-end user journey map that modeled the (existing) user types, how they use the application over the course of a project, and how it fits into their work process.
The most flagrant usability issue in the application that needed immediate resolution was a selection behavior that confounded users (and belief). In a list of items, whether files, datasets, or jobs in a workspace, there were two different, independent selection actions available. A person could:
For each selection set, a collection of respective actions would display for the user to act on the items.
Also, all lists first displayed with the first item pre-selected.
This behavior was clearly confusing to everybody, evidenced by the feedback, customer service questions, and logged feature requests — a conclusion supported by the heuristic review.
To fix this, the double selection was removed, and selection behavior was redesigned to have simple, logical, and consistent behavior rules. This pattern was then applied throughout the entire system. Selection behavior became usable and understandable.
Originally, there was no practical overarching navigation for the application. When a person signed in, the first page was the application home page, and navigation was accomplished through links embedded within the page.
In addition to not providing any orientation about the structure, this made it difficult and awkward for users to get to a specific location in the application, even from the home page. And from an internal page? A user had to go back to the home page first.
These problems were fixed by the introduction of a ubiquitous primary navigation menu that met people’s expectations and needs.
Adding primary navigation had additional importance because it made possible the later project of converting the home page into a personalized dashboard (see: Home Page Dashboard).
Navigation and wayfinding changes were also made within the application, particularly on the heavily used workspace pages where the project context (i.e. the workspace name) was made a persistent page element. This resulted in an improved, clearer sense of “you are here” when working.
Words are important. Most of the conscious interactions that a user has with a software application happens through the words used in the interface. Consequently, the words themselves are a critical piece of the user’s experience and impressions with the application.
To revise the experience of Chorus, the language also needed to be rewritten.
In the same manner that the visual language was developed by first figuring out what impact the visual style should create, the written language needed to start with a definition of what it should evoke.
Through a series of short discussions and feedback surveys, a tone and voice model was composed to establish the attitude, personality, and character of how the application should “speak.”
The next step was to audit and take stock of all the existing text. This was necessary in order to sort, group, and digest the quantity of individual text units (i.e. each individual word, phrase, or sentence) that were spread across different features and experiences. When grouped, similar and related text could be more easily compared, evaluated, and rewritten. Differences and problems that would not otherwise be obvious become readily apparent.
One example: labels and messages indiscriminately used “delete” or “remove” without distinguishing between (a) an operation that erased the item completely or caused it not exist in any form anymore, and (b) an operation that would take the item out of the current context without deleting it elsewhere/in other contexts. While these terms might be generally held to be synonymous, I felt that there is a critical difference between them that is very important in the context of a data-centric tool, where “deleting” a data set has significant real-world consequence versus the non-destructive action “removing” it from a particular workspace. By rewriting all of the action names and using them consistently, the application became more internally sensible and comprehensible.
It was not possible to rewrite all of the interface in one release, so the revisions continued incrementally over several releases, guided by the language and voice definition. A manual of style (a guide) was also created to be a reference and documentation resource for the entire organization.
Making text changes was inordinately easier because of the engineering best-practice that required all of the interface content to be in discrete language files. Formally for internationalization (i18n), this structure provides a valuable degree of flexibility because copywriting and copyediting can be decoupled from the regular development stream and can be done by the design team instead of the development team.
At the root of the new application look, the new color palette was simple, clean, and modern. The initial palette was intentionally limited, and then allowed to expand slowly over subsequent releases as the design language matured and holistic changes were easier to make.
Previously a mixed set of text fonts were used in the applications. They were replaced and standardized across the entire platform with a single family, Source Sans Pro.
Its humanist-derived style complemented the new design, and it has a wide range of weights that provide flexibility in different interface situations. As an open-source webfont, its licensing and availability were compatible with the business requirements and technical restrictions of Chorus (i.e. on-premise installation, behind firewalls).
Text sizes, styles, and formatting was then normalized across the entire application.
Once the interface style and palette changed, the graphics used in the interface needed to change too. An audit of image use identified that there were two classes of graphics (as is typical):
Generally, these are icons used with application actions, graphics related to the application structure, or communications from the application to the user.
Examples: open, close, configure, alert message marker, loading in progress.
These are graphic elements whose presence is dependent on user actions. Generally, these are graphics used for content and things that are part of the work being done with the application.
Examples: data sources, machine learning model, workspace documents, automated jobs.
The first category is reasonably universal and common to many applications. To standardize these with improved visual consistency, take advantage of resolution independence, and to improve the total application load time, all general image files were replaced with a glyph webfont.
In category two, the context-specific graphics and icons needed to be re-designed and re-created by hand to work with the updated application. With pictograms and ideograms as the inspiration and influence, imagery was simplified and flattened visually, eschewing the faux 3-D of the older graphics.
The new icons were created to be familiar and easily identifiable. When representing an element that has an external existence (e.g. a commercial database), the imagery directly references the external identity (e.g. a version of the logo). When the element is unique to Chorus, it was kept as simple as possible. The icons for a job, for example, use circling arrows to represent the concept that a job can be run recurrently. Within the arrows, a clock distinguishes a scheduled job from the “play” icon of an on-demand job.
Where possible, SVG formats were used for the same reasons as the webfont with the first category.
This work done to redesign the general application icons was a prelude to the subsequent work of redesigning the entire family of machine learning operators in the visual data science programming environment (see: Operator Iconography).