‘Y’ fidelity: adapting design for agile workflows

Beautiful, pixel-perfect design comps invite people to get tapping and clicking. They solidify a vision in the minds of customers and stakeholders. For UI designers, it’s tangible proof of hours of effort—another trophy for their Dribbble portfolio.

But in agile workflows, monolithic, high-fidelity mockups can quickly get out of sync. Design can become a bottleneck to development, putting the successful delivery of a project at risk.  

The COMFY approach reconciles traditional design tools and processes to the needs of a lean or agile workflow, with lighter deliverables and better communication.

Everyday I Draw the Comps

To geologists, monoliths are very large, solitary stones. To film buffs, the Monolith is the mysterious, featureless black slab from 2001: A Space Odyssey. In design, a monolithic deliverable can be equally large and cryptic.

• Monolithic designs are built around complete pages, not page elements
• These pages are delivered are in flattened pixel formats like JPEG, or otherwise uneditable by others, like PDF. Occasionally you may get the original PSD, but good luck if it’s not well-organized.
• Every element is custom-made, rather than drawn from an atomic design system or pattern library
• They’re built using pixel tools like Photoshop that make it hard to apply global changes without a lot of tedious manual labor
• Content is represented by placeholders, instead of being conceived from the content out, with a plan for sustainable content creation and governance
• More often than not, monolithic designs are desktop-first, not mobile-first. As my wife says, the end result on mobile is often like trying to move a houseful of furniture into a studio apartment–ugly, messy, and cramped.

Monolithic design practices come from print workflows that are at the core of the applications we use.

I’ve used Photoshop and Illustrator since (shh) Mac System 6, and InDesign since the dawn of Mac OS X. These programs came of age during the desktop publishing revolution, when we all moved from phototypesetting and manual paste-up to digital prepress, and photographers and artists began to move from airbrushes and fine-liner pens to layers, vectors, gradients, and pixels.

Thanks to nearly 30 years of market longevity, user familiarity, and the need for broad compatibility, these applications have come to dominate the design industry the same way that Microsoft Office dominates corporate productivity, for better or worse.

Even with modern add-ons that make them “web-friendlier,” what you get out of them is primarily page-centric layouts and static comps. These tools all but dictate that your deliverables will be monolithic.

Furthermore, like the mysterious Monolith from 2001, the design process can seem like a black box to other stakeholders—all they see is the finished product.

(I Don’t Want To Go To) Sprint Planning

Monolithic, static designs simply “tossed over the wall” to an agile development team is a recipe for costly design churn. This scenario may be all too familiar:

• An initial batch of mockups is delivered to the developers
• Inevitably, later batches of mockups have incorporated changes and improvements based on interim feedback
• Time permitting, the designers will circle back to update the earlier mockups to meet the current standard
• But… the coders had to start building features to meet their sprint deadline, so they started with the deprecated mockups as a guideline
• Now, those incorrect designs have been baked into code, and the designers and developers are chasing their tails on subsequent sprints, trying to fix things
• Did I mention they haven’t got to the mobile views yet?
• In some cases, the developers might simply refuse the new edits, as they got the changes too late in the cycle, so they’ll ship the current version and fix it later (incurring design debt)
• And the designer might be retasked to other projects in the meantime, so those corrections might not make it in for months or years

Design churn can lead to a blame game between coworkers and departments. It shatters trust in the idea that designers can deliver on time or that agile can accommodate changing designs.

“Designs ‘tossed over the wall’ to an agile dev team is a recipe for costly design churn.”

It can further entrench silos between workgroups that may have taken months to break down—and it definitely frustrates everyone involved.

In the end, you’ve burnt a pile of money.

All This Useless Beauty

Not only is constantly editing and re-outputting static comps monstrously inefficient—even if the results are beautiful—it’s a recipe for designer burnout. (How many weekends do you wish you could have back?)

Coders can’t wait for a Final Perfect Design before they start work—otherwise we’re back to waterfall-style Big Design Up Front, the polar opposite of agile.

Moreover, since developers in an agile environment work on user stories aimed at delivering individual features, not pages per se, a page-centric, monolithic design approach doesn’t really mesh at all.

Finding a better way to handle prototyping and comps with an agile team means adjusting both the design workflow and deliverables to be much more lightweight.

It also means finding different paths to communicate and negotiate with colleagues, between teams, and with your clients and stakeholders.

A word about visual prototyping

We’ve used InVision extensively on recent projects. It brings the team and stakeholders together, and there’s much less guessing involved. (You may have your own favorite tool, or maybe your team rolls their own solution.)

What we’ve learned is:

• Yes, you can put high-fidelity mockups of every page in your site in your prototype, with detailed interactions for every form field, button, slider, hamburger menu, lightbox, and accordion
• With more time and effort, you can do it all over again for tablets
• With even more time and effort, you can do it yet again for phones
• …and smart watches, smart glasses, smart hair clips, smart shoelaces…
• But you really shouldn’t

Once you make the considerable time investment in high-fidelity full-screen prototypes, the more committed you are to making equally high-quality, labor-intensive revisions.

Now multiply that effort across dozens of screens and interaction states. Your prototype can become a never-ending treadmill of updates, rather than a convenient tool for getting consensus on design or interaction decisions.

Patterns and flows

Prototyping tools provide better value to our process in 2 key ways:

• Working out rough screenflows – branching sequences of screens, such as signup flows, site search, or shopping cart checkouts. This lets us figure out what content ought to be at each stage, and double-check our thinking.
• Prototyping interaction design patterns – hover states, single-purpose forms, folding/unfolding accordions, slide-over dialogs, and so on. Finding the appropriate pattern for the right use case is faster if you can see how well one works or not in context.

To use a visual prototyping tool effectively in an agile context, you must keep the prototypes small, tight, and focused.

You can then use your tools—web-based, HTML, or graphic—to rapidly iterate, building a reference library of patterns and flows, rather than just making a pretend website.

(In my experience, the hardest problem is wrangling real content to build your designs around, so you can focus some of your newly found free time there.)

Get COMFY!!

The COMFY approach stands for Content-Out, Mobile-First, Y-Fidelity.

Content-out and mobile-first are self-explanatory, but if you’re not familiar with these concepts, I highly recommend the articles linked earlier.

Y-Fidelity is short for “Why high-fidelity?”

Ask yourself: do you really need to be applying high-fidelity designs at this particular stage in the process, or will lower-fidelity wireframes and sketches serve just as well, if not better?

The answer is to apply just enough fidelity to adequately describe a feature (user story) or flow. Not too sketchy that it loses the important details, and not too detailed as to go beyond what you’re trying to communicate, and potentially distract your audience.

Just-enough-fidelity, or JEF—pronounced “yef,” with a Spanish j—can use collaborative whiteboard sketches, scanned-in Post-It Notes, wireframes, even screenshots of similar features from other apps or websites.

Then, tools like InVision can be used to glue these together into a clickable, tappable proof of concept—but one you’re prepared to discard as your understanding of the problem evolves.

Some Things You Need To Get Used To

So, where is high fidelity design best applied in an agile process?

Style Tiles are a quick way to get consensus on the design language with a “moodboard” approach of color palettes, type, icons, shapes, and so on. You can build these in your app of choice, or directly in HTML and CSS using something like this CodePen project.

The next step is expanding that Style Tile language into high-fidelity designs for elements and components that will be reused across the project.

If your project is for the Web, it’s also a good idea to start with a basic set of HTML elements to define visual styles and typographical scales. You’ll need to define paragraphs, image styles, captions, headlines, line spacing, line lengths, and so on.

If you’re using Adobe apps, I urge you to look at using InDesign for setting up grids and type, as its page-layout concepts aren’t that different from the CSS box model used by web browsers. Think of text boxes as <divs>. With some planning, you can map out character and object styles to CSS rules. Plus, when you update a style rule, it updates everywhere it’s been used, just like CSS.

As you build up these styles, start collecting them into a style guide. If you’re starting without one, you should document as you go, but keep it lightweight.

Most agile and lean projects are in some level of flux at the beginning, and you’ll encounter issues you can’t plan for. For instance, translating designs between different device layouts, or discovering a feature has been added which affects your templates—so be prepared to revise.

We’ve found it useful to create a living style guide as a reference for our team, that designers and developers can contribute to equally. There are many tools and platforms for creating these, but something as simple as a shared Google Doc can get you rolling. Just be sure to maintain a change log near the top for authors to note their updates.

Keeping the team up-to-date by other means is also key, so that you avoid developers being out of the loop on design changes, and designers know what the development challenges are. Email lists, regular touch-base meetings or calls are vital—and so is sitting in close proximity, if you can manage it.

A pattern library documents interactions and flows, usually separate from visual style. Examples of design patterns are things like hover interactions on a map, how multi-page forms might work, how options are presented in dialogs, and rules for when audiovisual feedback is presented.

Design patterns are the territory of user experience/interaction designers. If you’re on a small team you may be wearing both design and UX hats, so you should become comfortable documenting everything. Both patterns and styles are necessary to avoid any ambiguity in how things are turned into code.

Once you’ve progressed in documenting styles and patterns, a few high-fidelity page mockups and prototypes can be useful to demonstrate size relationships and spacing between elements, define layout grids, and show how to apply other styles in context.

A handful of pages that demonstrate core templates is all you need—if you’ve defined and documented the styles correctly, it shouldn’t be necessary to generate whole new ones when you add a new type of component down the road.

CSS Will Happen

It’s easy to stay in the pixel-perfect Photoshop bubble, and even if you stop delivering time-consuming pages and start delivering smaller, faster, more agile collections of elements, flows, patterns, and modules, you may still not know what HTML and CSS do, exactly.

Just as aircraft engineers know aluminum and steel, knowing the materials that the Web is made of is really important. Even if your day-to-day work doesn’t involve writing code, you should be able to read it and discuss it comfortably with your colleagues.

The beauty of the Web is its openness. All you have to do is View Source to see what’s going on under the hood. And there are many, many resources, both free and paid, to help you learn the ins and outs.

Once you become comfortable with HTML and CSS, many things open up to you. Web frameworks like ZURB Foundation and Twitter Bootstrap, tools like the Web Inspector built into your browser, and code sketchpads like CodePen can help you communicate your designs to different stakeholders faster and easier, alongside the visual tools you know and love like Adobe CC apps and InVision.

After all, what’s higher fidelity than an actual website?