A new UI language for Ableton
When I switched to Live team in 2013 it was to help work on a new design language for Ableton. The goal was to set a new standard, taking Live a leap forward that would be as big as what we delivered when we launched Live 1. Our first step was to understand the current state of Live's UI, what made it special for our users, as well as documenting key design patterns to see how they could evolve. As we started to look at the team I also suggested that not only would we need to develop the UI, but the design team that supported it: in part our UI was a product of our organisation, so to evolve one wouldn't be looking at the whole picture.
To get moving quickly we started working with an external design studio A Color Bright, hiring as we went to build up a team around our work. The project grew to include ambitious technical goals and new products (Push 2), but as can happen with ambitious technical projects we realised some of the risks weren't worth it... so some of our more ambitous ideas, particularly with Live needed to be set aside.
Despite the tough choice around what we could ship for Live 10, the project produced the beginnings of the Ableton product design team we have today. It also helped produce the initial UI concepts for Push 2, which has been one of the most succesful hardware products in our industry. Lastly many of the concepts helped set the direction for other Ableton products and ideas that are still progress today.
Push 2's UI
When Push 2 went from discovery to delivery, I became responsible for working with A Color Bright and the Push team to develop Push 2’s prototypes and initial concepts into a UI language.
Push 2 was building on the functionality of Push 1, but had new challenges of its own: it was Ableton's first time engineering a hardware product on their own (Push 1 was a collaboration with Akai Professional handling the engineering) and it was our first time creating a full UI for hardware (Push 1 only had an alpha numeric screen). My main focus was helping define the goals and priorities and our approach. Later as the project progressed to the details of delivery I transitioned to supporting the designers around method and decision-making.
Based on user research for Push 1 and our assessment how the new features of Push 2 would change things we made a few choices:
- To handle help connecting hardware UI elements AND deal with Push 2's four different modes we worked to create a UI system that was regular, modular and always left the software UI relating to a specific hardware control in the same part of the screen.
- To help users orient themselves across Push 2's mixtures of modes and track structures, we decided to use colour as an orienting element.
- Along with the hardware design, we chose to focus on creating a minimal UI that where possible disappeared when there was no content to fill it.
The launch of Push 2 was very successful, and the UI (alongside other aspects of the experience) was frequently cited as an important contributor to this. The system that we started has been successfully extended for multiple released of new features for Push 2.