Defining Design Guidelines at Belong.co
Belong.co is a predictive outbound hiring solution that helps employers discover, engage and hire hard to find talent & help candidates find workplaces where they belong. We currently have two products in our portfolio:
Belong Hire — An employer facing SaaS Product.
Belong Experts — A market place connecting recruitment experts, candidates and companies looking to hire.
What are Design Guidelines ?
Design Guidelines comprise of :
- Style Guide — A library of UI components that ensures a consistent visual system across our products.
- UX Patterns — Rules defining how the each component in the UI library will behave and how it can be used.
What was the need to define Design Guidelines ?
- Our product portfolio is expanding (external and internal) and each product is becoming a sub-brand of its own. This creates a need for us to ensure that everything looks and behaves like the parent brand Belong.co.
- A comprehensive library of components make it easy for front end developers to implement things. This helps us maintain an agile workplace atmosphere.
- As the team grows, design guidelines will make it easy for new designers & front end developers to work on existing products.
How we went about it
Inspired from Atomic Design, we went about defining a structure for our UI library.
- Foundation — Before defining any components, we started with the foundational elements of a UI library. For example : layout and spacing rules, colours, text styles and icon types. These are used to define other components (analogous to atoms).
2. UI Elements — These are the smallest UI entities that can be used in an interface on their own. Examples are buttons, menus, tooltips, form elements(checkboxes, radio buttons, text input fields).(analogous to molecules)
3. UI Components—These are combinations of one or more elements. Examples are modal pop us boxes, Sign in/Sign up pages.
Case Study : How we used Sketch App features to define text input fields.
Context
A text input field had five attributes associated with it. There are:
- Type(blue) — Single line, Multiple lines and with button
- Label(Green) — Does it have a label or not?
- Label type(Violet) — Alignment of the label
- State (Orange) — Normal, Focus, Error, Warning or Disabled ?
- Value type (Yellow) — Text colour and alignment options.
Problem
This leads to a total of 225 different permutations in which a text input field can exist. A crude and simple solution would be to make different symbols and organise it using Sketch nomenclature rules. This would lead to a six step navigation inside symbols dropdown.
Solution
- After trying out different permutations and running experiments, we realised that Type and Label were the first things that come into a designer’s head while selecting a new text input field. We decided to build our primary symbols navigation around these.
To arrive at a specific permutation, we followed this naming convention, separating individual steps with a “/”.
Step 1/ Step 2/ Step 3/…..
By default, Sketch arranges your symbols in an alphabetical order. Here, we wanted single-line to come above multiple-line because it is used more frequently. A hack to make them appear in the order you want is to give numbers as prefix. So, 1-Zebra would above before 2-Apple.
2. The other 3 attributes — State, Label-type and Value-type were to be included as Overrides in the Inspector panel. We used similar naming hacks to organise the State, Label-type and Val-type options in the order we wanted(most frequently used to least).
How can I make an attribute show itself in the overrides?
This is where nested symbols come into the picture.
When you nest a symbol inside a symbol, and the symbol nested inside has other variants of the same size, the other variants present themselves as options for that property (as seen from the chart).
We defined 5 symbols for different state types — Normal, Focus, Error, Warning and Disabled.
We used one of these as a nested symbol inside the text input field (shown in screenshot above). Since other symbols related to State (warning, error, focus) are of the same size, they present themselves as options in the overrides panel under state.
Other attributes we wanted to use in the overrides panel were added using the same process. We defined symbols for Label-type & Val-type and included them as nested symbols.
Testing
We are continuously testing the components we have already defined by building everyday digital product mockups using them. This lets us discover how the components we have defined behave in different use cases. We then go back and make changes to the Design guidelines to accommodate use cases we didn’t consider while creating the components.
Impact
In the 2 months since first draft of the design guidelines has been created, impact has been felt around how quickly we can prototype ideas on software.
Ideally, we would want to make low fidelity prototypes, But, in an agile atmosphere, people don’t spend time on converting low fidelity prototypes to high fidelity mockups.
Summary
- Use “/” to name symbols for your desired symbol dropdown navigation.
- Use numbers to tweak the default alphabetical order.
- Use nested symbols to define overrides.
- Use “Symbol Organiser” plugin to organise your symbols page.
Conclusion
Defining & implementing Design guidelines is a gradual, stretched out process because of:
- To and fro between creating and testing.
- Working in an agile product design & development atmosphere, our primary task is defining & implementing the product roadmap.
What did I learn from this ?
By working on the Design guidelines, I was able to :
- Better my grasp on Sketch as a tool and use the capabilities and limitations of Sketch to my advantage.
- Have a better understanding of the UI design process and truly appreciate pixel perfection.
Set up behavioural and stylistic rules for UI components leading to a better understanding of their specific functions.
I hope that this helps designers standardise and scale their Design guidelines.
