The Common Problems

Design Artifacts are not Version Controlled

“Is this the updated version?” (Heard six times in a single thirty minute meeting)

Without the benefits of git and version control systems that software engineering relies on, the handoff process with User Experience Design teams has historically been a formidable challenge. Keeping up-to-date with the most current design file(s) leaves all of us cautiously optimistic that we are seeing the correct “vision“ from our design team. We have recently attempted to improve this by switching to handing off physical files in Sharepoint instead of the previous approach of exclusively using adobe XD cloud links. As we shift into this new approach, we may have made things even more complex since we each are saving flat files that as soon as we open them, fall out of date. All of the major design platforms are putting all stock and support behind cloud links. We use Adobe XD but Figma, Sketch have similar strategies for centralizing design artifacts in the cloud. Below are several reasons you should move away from designers storing their beautiful works of art on their machine and move them to a link hosted in the cloud:

  • Cloud links often store design revisions for a design or styleguide. This allows for easily being able to iterate and/or go back to a previous “version” of a given design.
  • Allows a design team to operate more like a software engineering team – When working on a cloud design document, it innately centralizing revisions so other designers can see those changes.Requiring them to resave to an arbitrary folder somewhere just introduces extra work across multiple teams.
  • Prevents having multiple “Single Sources of Truth” or “Acme Website Design version 9 – Final FINAL” – Providing that your design team is working from one cloud document per product or brand, it prevents confusion as to which version is the most up to date and collaborators having to sift through multiple folders finding the correct design.
  • No more outdated ticket references – Often times, design artifacts get uploaded to JIRA, confluence, sharepoint, dropdox, etc. If a design is rapidly iterating, this quickly opens up the risk of fragmenting what gets built after design. The engineers may be using a file that is a couple version out of date and then QA may be using a version that is one version out of date. You can see how this leads to confusion and wasteful conversations.

Translating the “States” and Animation

During grooming sessions, you will often hear things like:

“What’s the hover state for that? What does it look like when it opens? Does it animate?“

All of these questions and uncertainties usually result in more meetings, more conversations, and an erosion of trust for all parties involved. The qualitative goal here is to save time and translate the design vision to engineering as efficiently as possible.

Use Page Groups Not Product Walkthroughs

““Sorry all, this thing takes forever to load. -6 minutes later- Well, we’ll have to come back to that, I don’t see a design for that. Great. My machine just locked up.““

If a Product Walkthrough contains a hundred plus screens and is not linked to a styleguide, there are thousands and thousands of would-be components that just get severed from the library they were originally sourced from. This causes tens of thousands of elements frozen in time across all pages (at all breakpoints), statically. This is why there are such long wait times to open big product walkthrough type documents. After speaking with our design teams, it was revealed to me that the real intention of those enormous files are to sell executives, directories, product owners, and the like on the overall web application experience for that product. It’s meant to be a selling tool, a brochure. It’s really shouldn’t be a working document that is held as the single source of truth. Another drawback of this massive file being the focus is that all the designers work out of that single document more often. This introduces complexity and confusion amongst the designers and reviewers alike. When we had published links, our producers (project managers) would be reviewing it with the software engineering teams only to have elements move around on them mid-meeting!

8 Tips and Tricks to Work More Seamlessly

  • 1
    Front-end and Design Matching Styleguides – When kicking off a project, design will often work ahead of engineering. I think there are arguments to have that feedback loop pretty tight. In example, the engineering team should never be too far behind Design but both teams should be working from a styleguide that attempts to mirror each other. Whether Design is six months ahead of engineering or six days, the lifecycle should look like this: Design creates a beautiful, usable User Experience Design (UXD), combs those screens that make up that experience and pluck out the common design elements /modules and put them into a Product Styleguide. After some collaboration sessions, the Software Engineering team should be trying to recreate that Product Styleguide in a Front-end Styleguide. If you aren’t using some of the great solutions for this like Storybook, a static page with these common elements could suffice.

    Build the Lego Blocks first before you start putting together your 7,500 piece Millennium Falcon masterpiece.

  • 2
    Unified Measurement – Most design applications like Sketch, Figma, and XD have a few options for measurement. In software engineering, we should be using mostly REMs and in a few select places pixels. Since even REMs are usually derived from pixels, we asked our designers to make everything pixel based so we don’t end up working on the new header area and uexpectedly, the designer has set it all up to use inches. (True story. :-). Agree on a measurement and both team’s stick with it. Software Engineering Tip: If you are developing your application with a CI system (Continuous Integration) and part of that process is linting the code using tools like ES Lint and Stylelint, you may be able to actually setup a rule to ONLY allow pixels for X, Y, and Z and REMs for all other values. This locks in this bullet item so that engineers can’t break the pattern.
  • 3

    Typography Normalized Between Teams – If you are using Figma or sketch, I believe typography can be set up to use REMs so this line item should be easy peasy if your team uses either of those. However, in XD, they use pts instead of pixels or rems for typography, by converting values ahead of time, Pts can be converted into pixels IE: 1.33% pt = 1px = 0.1rem. If this has already been normalized for your teams, then you can check this item off. The point here is to make a concerted effort to pull up Designs’ artifact and your web page with 100% zoom, set them both to the value both team’s are expecting, and ensure they match size, kerning, weight, etc.

  • 4

    Business Copy Agnostic – All copy within a design document should use Lorem Ipsum for non-intentional or dynamic/example copy. There are several Lorem Ipsum plugins out there if it’s not directly baked into your design program. This helps avoid avoidable conversations around verbiage where the designer was simply providing an example of copy that would ultimately come from a CMS or another associate. It also prevents a designer from having a little too much coffee one morning and using the text in a header: “Boring Header with Worthless Meaning”, this getting coded to spec and eventually slipping through QA. (Another true story!)

  • 5
    Design Using Components End to End – As a design team creates experiences, they will of course copy and paste that card style or header treatment into a new set of screens. Good designers, try their best to keenly identify these repeated components and highlight them in a styleguide. Even if you have already built fourteen screens and it’s going to be some work, please go back and move these repeated components into your styleguide. Most of the today’s design programs will let you use a symbol/component and create instances of an original one that exists in the styleguide. Although, it’s a pain, doing this will pay off in the long run. As design team’s get more mature, this process will become second nature. Repeated components never get too far into a dozen screens without a styleguide component getting created and used within the screens. This also includes the Product’s color palette. Always stick to the colors within a product’s color palette so questions don’t prop their ugly head up once a design is over the fence to engineering.
  • 6

    Stateful Design Components – All Items in the library need to have “component state” for the various front-end states. IE: default, hover, active, focus, innactive, open close, etc. Figure to left: See the various states saved to the master component

  • 7

    Use a Shared Glossary – While the project manager, pumps ticket after ticket out describing the user stories or work that will need to be designed and developed, urge whoever is managing the work to create a shared glossary. Business terms like song vs. track vs. piece vs. etc. design and development should try to align on the same terminology. If this is not possible, each team’s respective reference point can be clearly outlined here. Having this glossary can help prevent effort getting lost in translation down the line.

  • 8

    Name the Design Components What Front-end Calls Them – A design team’s job is not directly to build a Design System, they are the creative artists that dream up novel ways of experiencing the internet. Whether you call individual components atoms, UI Style Tile Modules, or a UX Element, chances are, the designers are just calling them something that makes sense to them. By huddling with front-end and attempting to use their nomenclature, it keeps both teams aligned as they design, build, and maintain these individual components within the application. It also aids greatly in maturing each member of both teams.

  • 9

    Once Both Team’s are in a Rhythm, Keep it Tidy – Once both teams are in a good rhythm, it serves everyone involved to purposefully go back and trim the fat within the original design artifacts. I’m sure there are comparable (and most likely easier) ways in Figma and Sketch to identify unused layers/components. However in XD, I relied on a tried and true workaround to easily identify and delete all unused components within a given User Experience design(s). Here are the steps:

    1. 1. Press CMD + A with anything selected on the canvas. This will select all objects in the file (i.e. all objects on all artboards + pasteboard)
    2. 2. Right click on any selected object on the canvas/artboard and select ‘Reveal Components in Assets’
    3. 3. Notice how some assets are highlighted but not all within the Assets Library left sidebar.
    4. 4Left click your mouse on one of the highlighted assets and drag to top of panel (IE: Components). Observe how all assets are dragged together, then release mouse button to drop them just above the top-most asset.
    5. This effectively moves all components within the document are now listed at the top and everything below the last selected component can reliably be discarded.
    6. Now select the first unused asset, hold shift and then left click the last unused asset. This will select all unused components within the document.
    7. Right click the selected assets and and choose delete. Caveat: If you do not see the option “delete“, try shift + left click a smaller amount of components. Some components may be locked which will prevent your entire selection from being deleted.
  • 10
    Use Plugins to Find Patterns across Teams – Remember plugins and extensions are your friends. They can save you and your teams countless hours and help mirror your respective workflows. I’m sure there are comparable plugins for all the major design platforms. Here is a list of XD add-ons that I would recommend:

    DSP Reader: https://www.adobe.com/products/xd/resources/plugin-directory/p-13815-dsp-reader.html

    Jira Cloud: https://www.adobe.com/products/xd/resources/plugin-directory/p-13830-jira-cloud-for-xd.html

    Lorem Ipsum: https://www.adobe.com/products/xd/resources/plugin-directory/p-13834-lorem-ipsum.html

    ReplaceItems and Replacer: https://www.adobe.com/products/xd/resources/plugin-directory/p-13838-replaceitems.html, https://www.adobe.com/products/xd/resources/plugin-directory/p-13839-replacer.html

    SelectMenu and Selection: https://www.adobe.com/products/xd/resources/plugin-directory/p-13842-selectmenu.html, https://www.adobe.com/products/xd/resources/plugin-directory/p-13843-selection.html

    Stark: https://www.adobe.com/products/xd/resources/plugin-directory/p-13848-stark.html

    Tags Manager: https://www.adobe.com/products/xd/resources/plugin-directory/p-13852-tags-manager.html

    Tool Kit: https://www.adobe.com/products/xd/resources/plugin-directory/p-13857-toolkits.html

Recent Works

All 12 factor application principles laddered up to better front-end performance