Thinking about design patterns
At Avocarrot, we are in the middle of building a very challenging product — a brand-new one. Obviously, I cannot share a lot, but I can share this: we haven’t made such a product before. We need to go into exploratory mode and try out new things without many insights on user behavior. We are eager to iterate fast and provide the optimal experience to the end user at any given time of that product’s life.
We have done the basic groundwork. The main idea is there — from business to user interface. One of the most challenging parts is that the user is incentivized to take many actions each week in our platform — with each action driving revenue numbers. Having said all these, we’ve made the realisation that the feedback loop between the user and the platform should be one of our highest priorities while we are building this. Feedback loop essentially is a piece of information that the user receives, which informs him about the status of his task whether it’s accomplished or not.
The way we are trying to solve this problem, is with notifications — because it’s an immediate, subtle and non-intrusive way to inform users about specific things. Essentially, notifications should contain small pieces of information which inform the user about the status of his task.
In order to make notifications as valuable as possible, we came up with a workflow. The workflow is the following: before we jump into Sketch we need to answer 4 questions:
- What?
- Why?
- When?
- How?
What is a notification?
A notification is a piece of information which informs the user about the status of a task. It should be used only on primary tasks.
Why is it needed?
Because users need to receive immediate feedback on the status of the task they complete.
When should it happen?
Every time a user completes a primary task in the platform. Primary actions are highlighted by the product team — and they are actions that affect the revenue numbers on the platform.
How should it look like?
The layout of the notification is dictated in our style guide. Notifications should not include sounds. Notifications should not send automatic e-mails. (We have a couple Do and Dont’s here — to illustrate the correct use and make sure everyone is one the same page).
We have been working with this primary but powerful methodology on a number of features. We are formalizing it in our process as “Design Patterns” and it will be included in the product’s style guide conventions. Design Patterns is a growing library of patterns and the main benefit it brings to the table is that it establishes rules for how the product works. Both design and engineering teams should be aligned and follow these rules when we think, create or iterate on parts of the platform. We are trying to go deeper and deeper everytime we iterate on the patterns — and solve as many user needs as possible.
