Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Design systems in Practice
Ähnlich wie Design systems in Practice (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Design systems in Practice
- 2. design systems in practice David Boddy & Robin Glen @threetwotwo @arielwithlegs
- 9. two showcase early and only with atoms plain language and consistent naming conventions solve problems together
- 10. case study
- 11. 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
- 13. 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
- 14. in practice
- 16. breakdown
- 17. nucleus
- 18. 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
- 19. states nucleus
- 20. states N E W S E A S O N LANVIN Fringed boucle-tweed mini dress £2,325 £1,162.50 50% OFF
- 22. 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
- 24. 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
- 25. 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>
- 27. unit
- 28. SEO
- 29. visualvisual
- 32. self documenting
- 36. building up
- 37. N E W S E A S O N LANVIN Fringed boucle-tweed mini dress £2,325 <nap-product-summary>
- 41. questions?
Hinweis der Redaktion
- 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
- our goal
- Element
- 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
- 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.
- Interactions
- 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
- 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.
- Testing
- 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
- Documentation
- Self documenting code on how to use the component
- A demo of how to use the code
- Versioning
- 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