OneSignal is the largest push notification and marketing automation service, sending 7+ billion daily notifications on 1+ billion devices.
- Redesigned core OneSignal Dashboard including design system, custom form elements, and information architecture
- Launched self-service Web Push flow, in use on ~2.3% of top 100k internet sites
- Launched email support and audience segmenting tool
- Rewrote & rearchitected OneSignal documentation
- Redesigned OneSignal website (marketing)
- Conducted user research (data analysis & conversations)
- Management activities (market analysis, Series A deck/pitch, financial models, refined customer support flows, etc)
OneSignal's original dashboard was showing it's age and had many UX and clarity issues, and it wasn't the right design for the many features we planned to build. The redesign added or improved the following:
- New step-by-step UX simplified usage
- Advanced features hidden to not overwhelm more frequent use cases
- Standardized & clarified form elements
- Added tips to provide contextual info on features and direct links to docs
- IA update scales to new & future features
- New coat of paint to suggest premium product
I tackled this problem by planning forward a few versions to features we wanted to build, organizing current and planned features into similar clusters, finding opportunities to simplify workflows by taking an opinionated approach, and identifying shared actions and desire paths. I built out the information architecture before jumping into visual design. You can read more about the process I used in my IA post When to Add Hierarchy, and about the redesign in the announcement post OneSignal has a fresh new UI.
After a few iterations, the solution I settled on the following changes:
Two-level hierarchy - Features were reorganized into four major sections - Settings, Messages, Users, Delivery. Within those, the most common page was presented first, and power user features were available one level down. This better reflected how users used and got value out of OneSignal, especially within teams. Settings was primarily targeted at developers, marketers used Messages, different marketers often liked to build targeted audiences in Users, and for those that didn’t just fire-and-forget their messages Delivery helped them see their performance.
Color-coded sections - Enterprise tools, especially form-heavy tools that reuse the same elements over and over again, tend to have a lot of visual same-ness across pages. Without any significant landmarks to ground them, some users will inevitably get lost. By giving each section a unique color and icon, and reinforcing those throughout our documentation, users were less likely to wind up in the wrong place.
Focus on great forms - Like many enterprise products, the OneSignal dashboard is essentially one gigantic form. This meant getting forms and form elements right was a high leverage point in the design. I hand-designed each form element and spent considerable time rethinking form flows and form clustering to make the form elements as intuitive and pleasureable to use as possible.
More modals - Modals greatly increased our ability to keep users on-task while allowing for quick access to certain desire paths. Our initial design typically had a page for every action, but by moving to modals we cleaned up some clutter deeper in the hierarchy, and were able to develop common interfaces for capabilities that were shared across sections. For instance, by building segment creation into a modal, users could edit audience segments without having to leave the New Message flow, whereas before they needed to do this from the Segments page.
Designing for Understanding
One of the key goals in redesigning the dashboard was to build understanding into every part of it, helping users of all types know what each feature was for and how to best use it. This involved several progressively more visible ways to orient and explain to users the purpose and functionality of the feature, from how individual form elements were labeled, to embedded contextual tips that explained features, to rewriting documentation to be a seamless extension of the product.
The inspiration for this design came from my background in education technology, especially in empathizing with the huge diversity of understanding of our customers, who often neither spoke English as a native language nor had a deep understanding of marketing, because most were developers. Additionally, as a free tool we could not rely on enterprise account managers to help customers; instead the product needed to be self-explanatory. This redesign allowed us to scale to over a half million customers with a support staff of 1-2.
At OneSignal we favored fast and incremental changes, often pushing code several times a day. The scope of the dashboard redesign was both unwinding a Bootstrap-based template in favor of custom HTML/CSS, as well as a desire to move from static HTML to React components. Keeping a redesign on a separate branch over the course of months was therefore rather error-prone, so we made changes incrementally over many months, launching the first set of visual changes as part of another feature change, and then worked behind the scenes over the next several months to implement more and more of the features in React. My part was writing all CSS and HTML for the OneSignal dashboard, working with two front-end developers who were implementing everything in React, and writing, scoping, and sequencing issues into releases on Github.
I also redesigned all of OneSignal's marketing presence to add the polish necessary to move upmarket and target higher value clients, as well as improve user conversion and grow the team:
Part of the strategy of the homepage was also to bring value forward in signup. As the only free push notification service, I wanted us to play to that advantage and make signup as easy as possible, rather than our competitors 'call us' approach. My hope was to push back account creation to after the point where users had done initial configuration of their app or website, thereby increasing conversion because value was seen. Unfortunately we didn't get around to building this as we already had more than enough growth.
OneSignal's documentation was something everyone on the team contributed to, and was a critical part of our ability to be a free, self-service tool while offering free unlimited customer support. However, there were many issues with the documentation that needed addressing:
- Only showed setup steps
- Didn’t explain how to use OneSignal
- Didn’t explain how to use push notifications
- Didn’t sell the OneSignal services
- High cognitive load for users balancing code, documentation, and dashboard
- Didn’t scale well as content grew
- Writing assumed high level of technical ability
In my time at OneSignal I did a nearly complete rewrite and redesign of documentation, making the following improvements:
- Comprehensive product manual for Dashboard
- Push notification concepts & best practices
- Clearer explanations for devs with less technical ability
- OneSignal value-add pitch
- Clearer links between Dashboard <-> Documentation
- Easier reference points from customer support flow
- IA scales to more content & features
OneSignal's documentation is now are primary means for over 750,000 developers and marketers to setup and use OneSignal. During my time there, support burden did not significantly increase despite customers growing by ~8x.
I did a lot of other work at OneSignal besides dashboard, marketing, and documentation, including all manner of early stage executive work like helping raise the Series A, customer support, user research, etc. One example is my work on our Series A deck, which I did all the design and much of the structure of:
I also designed a mobile app called Hang for use in our documentation, which was an example of the power of rich notifications. Hang is about helping friends find activities to do together.