Not long ago we created an ✌️awesome new feature called Task Management for our users and made an outstanding improvement visually and functionally to searching and filtering in the editor.
To release these and many other features and enhancements, we needed a plan to notify users about the changes in the UI, to educate and walkthrough in the new behaviour and to provide the high-level concept behind this major alteration of their workflow, why we decided to go in that direction and importantly what benefit they will get from this change.
Although this might seems an easy task, it was not. Why?
At first we had to decide what elements should we use, what components we had in our quiver, decide for the positioning, the pages that are affected, what should we show when a new change comes, when is the time to re-think and change a component, what are the technical limitations, not to mention copy, supporting help material, documentation entries and so on…
As a result for long time and in many cases we planned, discussed, designed, validated and after that planned, discussed, designed, validated and after that …
That was our initial onboarding strategy, it was not that bad, it worked, people were notified for new changes, they used and loved the new improvements but it didn’t feel streamlined and agile right?
So we started re-framing our own model, re-questioning our own process.
Re-framing our model didn’t include design at all. We didn’t introduced a new component, we didn’t question our own styleguide. All the parts were there for us to use. But the core thing that was absolutely missing was the structure, the plan and the interconnection between all.
What we did?
We created a document, a simple Google Document which would be the source of truth for our strategy.
We could possibly create a doc where we could explain the rationale behind onboarding, perhaps document components, provide some past example and mockups to choose.
But is this approach modular, scaleable in a design system? Maybe not..
I could have started by looking around, gathering materials, articles, any kind of source and paradigm of good and bad onboarding UIs.
But I didn’t want to look around. I didn’t want another component in our Design System, I didn’t want another bad example to compare.
To be honest I wasn’t looking for answers. I was desperate of questions.
So I started asking questions!
The Ws of Onboarding (and a H)
☞ What is user onboarding?
☞ Why do we use onboarding?
☞ When is needed?
☞ What UX patterns we use?
☞ Where have we use onboarding?
☞ How we use UX patterns?
With these questions in hand i started writing possible answers. After a lot of refinement I ended up with the following study of Onboarding principles.
It’s worth mentioning that this doc includes and explains the patterns one by one. There are screenshots and examples of components we use.
But the main concept to be scalable is that this strategy is based on abstraction and intention of the onboarding experience, so for every change of a component or a pattern or interaction — the core logic is not affected.
With all these questions, patterns and scenarios in a document a schema emerged which provided a common vocabulary between all stakeholders.
That new form of communication was liberating.
We skipped a step; the thinking.
With the logic defined, the development as well (since we had all the patterns ready to be used) and design too — it became a matter of choice and decision.
So how this applied to our process. Let’s take a not so hypothetical deployment.
In the question “Do we need onboarding for feature X” the team will cite the onboarding blueprint and decide if onboarding is needed (that will assist PO and Customer Success Managers orchestrate any public update through email, blogpost, documentation), when is needed (which will help interaction designers plan the timing and frequency of the onboarding), what’s the type of change (that will help designers and frontend engineers to not reinvent the wheel and apply reusable components).
Problem solved, right? And it is.
A major part of negotiating, debating inside a team is gone. Everyone is in the same page, they all have a clear path to follow.
For every puzzle; a citation to the doc is able to move things forward, unlock a process and deliver things in a consistent way.
Below some conversations that we had in the past and how we converse today and how we solve unknowns and uncertainties.
But something’s missing from the above structure.
Something truly crucial. What’s that?