Design systems aren’t new. Not to designers and not in terms of telling stories
This example is from 30,000 to 32,000 years ago using certain symbols and shapes to represent narratives to others - telling stories through universally understood pictograms
We use an atomic methodology, mainly because
It focuses on designing systems not isolated pages.
At Net-A-Porter our eco-system must work throughout each user flows not just in individual instances. This requires us to have a coherent visual and interaction language
So our visitors understand how, when and why to interact with our product.
We’re not here to talk about how systems improve our lexicon and rationalisation for newness.
Now we haven’t got lots of time, so what we want to do is pull out 2 key principles and a case study for you.
up first - granular thinking
Break things apart until they are at their most simple. This allows for focus on the needs of each atom in isolation, critical to keep things simple
Steve Jobs and Apple were famed for using the term ‘Simple Stick’, and nothing is more relevant here.
In terms of design, you might say the atom is a button, or H1 all designed and sitting in a style sheet.
but take that into production and actually we need to think a bit harder. We need to be aware that these have different states / interactions / behaviours and rules then we might want to test it / document it and version it for release.
Now this is your atom in production. Each layer adds more information and more complexity
And you can begin to see why it’s important to start small and apply only what specifically relates to each item. Be as clear and concise as you can - it will benefit you later.
the other principle that i want to point out is the need to standardising the rhetoric
I mean this on 2 fronts
When showcasing to stakeholders/clients/dependent teams - the earlier the better. Showcasing atoms independent of layouts raises less opportunity for subjective commentary, compared to when you might show them within a template, or user flow.
When within your teams (cross-compentency product hopefully) - Use plain language, both for design and engineer problems. You make less assumptions when you don’t hide behind buzzwords. This will make you more efficient, have less rework over the course of a project, also it will be easier for new members to pick up the work
The use of plain language also allows you to solve your problems together as a team. This matures the team’s combine understanding around problem solving making them more adept in find solutions quickly. Mob sessions, Power of 3’s, watching Lab testing together… be a team that wins and learns together
adding to those principles we just want to give you a short case study, which Robin will talk through for you
Creation of a responsive listing to house our New Arrivals product list in Q2, with an iterative rollout of features there after to enable the migration of the entire NET-A-PORTER [product listing] catalogue in 2016
KEY RESULTS 1 Create a responsive product list with no customer features for Upload Preview in Q2 2 Measure benefits and KPI's of responsive listing after delivery and continually communicate to stakeholders and feed results into development 3 Plan and deliver the iterative rollout of listing features against an agreed timeline until at parity with current site functionality 4 Migrate existing lists to the new responsive application by the end of 2016
a couple of the business drivers are:
Optimising our view for our most profitable browser widths. So from a fixed 950px to 1400px
Transferring away from our monolithic web app to allow for increase speed of iteration, releasing and more confidence around reliability
And from our customers, they need
easy to target and accurate information be inspired, feel excited and to anticipate the purchase understand the landscape they need to navigate
And generally their pains revolve around being time poor and distracted
Element First thing we do as developers is break it down into visual components. This for example is a product We can now start to build the element
States Although a product can be dynamic it is relatively stateless two exceptions.
1) atom loading- we are currently working on this state 2) Price can have two states, full price and on sale. It also is a universal component, so we will separate this into another component.
We can now build in some interactions Most basic - we to generate the link to the product page, this will include localisation and SEO friendly url Image outfit shot interaction - currently on mouse over show secondary image, in the future this could be array of products in a carousel
Behaviours and rules
Behaviours and rules
Broken image styling Responsive images using img srcset Schema.org tags to describe the structure of the element
and here is how it comprises of.
but we want to make this production ready - so lets add a few more layers.
Again instead of thinking of testing as a whole page, we want to ensure these components are tested in isolation. So we do the following tests:
Unit tests - make sure the elements interactions, states and behaviors work and are consistent across all browsers
SEO tests - does google know what the element is? We do this with
Visual tests - does it look the same on all browsers
Memory and performance tests - We know it works, but how well does it work
Self documenting code on how to use the component
A demo of how to use the code
We use a tool call bower to version our components so we can control upgrading and making changes
So we now have a visual representation of nap-product-summary, named after LAD data response
Build up the products into a list
This approach you do need more time upfront but it will pay off as you move forward
Design systems in Practice
design systems in practice
David Boddy & Robin Glen
Creation of a responsive listing to house our New Arrivals product list in Q2,
with an iterative rollout of features there after to enable the migration of the
entire NET-A-PORTER [product list] catalogue in 2016