Post Image

Beware Sloppy Shortcuts — Use Design Systems to Keep Code on Track

Ben Gremillion
Ben Gremillion

    People like shortcuts. It’s not that they’re lazy; developers and designers alike like to save time, and who can blame them? Beating deadline is an important part of design as a business. But shortcuts carry risk.

    Here’s one problem: copying code snippets is easy. Copying the right snippets takes precious time. And even if a design team’s internal slang helps them remember what things are — billboards, carousels, and rafters, for example — there’s no definitive code behind them. So the thought process wanders: “What was that thing called again? Never mind, I’ll just copy from the web page.”

    Don’t do it!

    Would designers revamp graphics from JPGs or PSDs? Would front-end designers edit CSS generated from Sass? Of course not. They’d go to the source. So why copy/paste code from old web pages into new ones? That approach is fraught with peril.

    • You might copy to much or too little code.
    • Or get unrealistic expectations of what content goes into it.
    • To avoid the above, you need to spend precious time analyzing source code to find the correct bits.
    • It’s impossible to say how an instance of code has changed. Copying from an instance might get someone else’s hack.
    • Depending on a team’s code standards, someone has likely vetted a design system’s code against major browsers.

    A systematic approach

    Imagine making a list of components in a project. From sidebars to buttons to scrollers to list items, there’s no shortage of things to inventory. Picture this list as a sketch of each component. Then imagine giving each one a button that copies its code to your clipboard.

    Click. Copy. Paste. Move on.

    Spec mode screenshot

    Such a solution is part of a coded design system. It’s about getting code from the source. A visual source that’s easy to browse.

    Ideally developers could look up a component, module, or other widget by its look as well as its name. Upon selecting that element, they’d see its code which they could copy/paste into their favorite code editor.

    The advantages are huge:

    • Working from the same codebase, everyone on a team can work with everyone else’s code.
    • There’s no need to reinvent and test blocks of code, saving time in development and maintenance.
    • Front-end developers can test code snippets beforehand, ensuring that it will work with their target browsers.
    • There’s a smaller chance for typos.

    What are the downsides? As the saying goes, old habits die hard. Some people have trouble remembering to use the design system’s code snippets, or figure eh, I’ll just cheat a little. After all, it’s just one button.

    One button with a potential bug. One button that doesn’t fit the spec. One button that, when it needs editing, someone must take time to figure out. These little problems add up.

    Bringing the team onboard

    How do you fight old habits? With new ones.

    A habit is what we tend to do without conscious thought. And they’re usually small: checking email over morning coffee; paying rent on the first of the month; muscle memory for your favorite keyboard shortcuts. To change a team’s habits, you must make changes one step at a time. Specifically, adding new habits to replace old ones rather than trying to “break” them.

    In the case of visual code libraries, changing the copy/paste habit begins with a few simple steps.

    • Include everyone in developing the pattern library and its code.
    • Start today. Don’t put off changing your or your team’s current habits or else they’ll continue to dominate your workflow.
    • Practice building web pages or app views with the design system’s pattern library.
    • Enjoy the “work” so your mind accepts change more readily.

    What’s in a snippet?

    You may chose to document more than a visual reference and the code itself. Five bits of metadata you might include with your code snippets are:

    • A sensible name. “Top widget” could refer to anything. “Navigation bar” is more descriptive.
    • Version number or date. When was it last updated? Is there a newer edition that your team should use, even though older versions are still in use?
    • Min/max. How much content can it handle? What are its widest, narrowest, shortest, and longest dimensions?
    • Safe browser versions. Since web browsers change frequently, knowing which snippet works in what circumstances is critical as users’ capabilities evolve.

    While these metadata are optional, you may find them handy for long-term success.

    Going forward

    It’s not that shortcuts are a problem. Far from it. Recognizing a technique vs. a cheat, however, is the key to getting consistent, accurate code for your digital projects.

    Ben Gremillion

    by Ben Gremillion

    Ben Gremillion is a Content Strategist at UXPin. He’s worked as both a web designer and a back-end developer. On the side he builds and maintains a CMS for webcomic artists, and participates in annual NaNoWriMo challenges.

    Still hungry for the design?

    UXPin is a product design platform used by the best designers on the planet. Let your team easily design, collaborate, and present from low-fidelity wireframes to fully-interactive prototypes.

    Start your free trial

    These e-Books might interest you