design systems in practice
David Boddy & Robin Glen
@threetwotwo @arielwithlegs
Brad Frost: http://atomicdesign.bradfrost.com/table-of-contents/
moleculeatom organism
key principles
one
granular thinking
atom
testing
versioning
documentation
states
behaviours and rules
interactions
nucleus
two
standardising the rhetoric
two
showcase early and only with atoms
plain language and consistent naming conventions
solve problems together
case study
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
950px1300 - 1400px
customer pains and needs
easy to target and accurate information
be inspired, feel excited and to anticipate the purchase
understand the landscape they need to navigate
time poor and distracted
in practice
breakdown
nucleus
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325
product image
badge
designer name
product description
price
states
nucleus
states
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325 £1,162.50 50% OFF
states
interactions
nucleus
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325
interactions
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325
states
interactions
behaviours and rules
nucleus
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325
behaviours and rules
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325
product
image
badge
designer
name
product
description
price
Currency
Sale state
Rounding
Schema
Offers
Price & Currency
text translations
scaling of text size
truncation rules
Schema
Brand
rollover image
carousel of images
missing images
broken images
loading state
Schema
Image
<nap-responsive-image> .product-badge .designer-name.product-description <nap-price>
testing
states
interactions
behaviours and rules
nucleus
unit
SEO
visualvisual
memory and performance
testing
states
interactions
behaviours and rules
nucleus
documentation
self documenting
testing
documentation
versioning
states
interactions
behaviours and rules
nucleus
building up
N E W S E A S O N
LANVIN
Fringed boucle-tweed mini
dress
£2,325
<nap-product-summary>
<nap-product-list>
time
delivery
applying principles
questions?
thanks
@threetwotwo @arielwithlegs

Design systems in Practice

Editor's Notes

  • #3 Design systems aren’t new. Not to designers and not in terms of telling stories
  • #4 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
  • #5 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.
  • #6 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.
  • #7 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.
  • #8 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.
  • #9 the other principle that i want to point out is the need to standardising the rhetoric
  • #10 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
  • #11 adding to those principles we just want to give you a short case study, which Robin will talk through for you
  • #12 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
  • #13 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
  • #14 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
  • #16 our goal
  • #18 Element
  • #19 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
  • #20 States
  • #21 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.
  • #22 Interactions
  • #23 Interactions 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
  • #24 Behaviours and rules
  • #25 Behaviours and rules Broken image styling Responsive images using img srcset Schema.org tags to describe the structure of the element
  • #26 and here is how it comprises of. but we want to make this production ready - so lets add a few more layers.
  • #27 Testing
  • #28 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
  • #29 SEO tests - does google know what the element is? We do this with
  • #30 Visual tests - does it look the same on all browsers
  • #31 Memory and performance tests - We know it works, but how well does it work
  • #32 Documentation
  • #33 Self documenting code on how to use the component
  • #34 A demo of how to use the code
  • #35 Versioning
  • #36 We use a tool call bower to version our components so we can control upgrading and making changes
  • #38 So we now have a visual representation of nap-product-summary, named after LAD data response
  • #39 Build up the products into a list
  • #41 This approach you do need more time upfront but it will pay off as you move forward