7 Reasons You Should Stop Making Static Wireframes

Photo by Daniel Cheung on Unsplash

Why is it so hard to let go of the anachronistic notion that the web is made of pages? Don’t get me wrong; most of my interests are a bit old-fashioned (Victorian occult, hardbound books, drawing with pen and ink rather than the easily reversible digital method). But that’s my own curated, subjective experience; to impose those values on the users I design for in my day job is just rude.

Symbols of the tangible world persist in the digital dimension, because humans still have bodies covered in skin. We still touch real things and receive haptic feedback (not to mention feedback for all our other physical senses). Some digital symbols of tangibility (often found in skeuomorphic design) are more benign than others. A little picture of a house that represents a home state isn’t hurting anyone; in fact, it reassures the user that if you’re lost in an app, you can always “go home.” But the idea that a single, even linear web experience equals a printed broadsheet ignores the thing that makes the web special: interactivity and changing states.

The development of web UX should be interactive. After all, why should we make static PDFs to represent designs that move and change? When I joined Hook & Loop, most information architects (including me) were doing just that. Since IAs are often assigned the job of making and recording the decisions that shape software designs, PDFs full of wireframes and annotations had become its own time-honored tradition. Why, here’s one I made:

This is a somewhat complicated bunch of notations.

This project started out as a simple redesign of a couple pages, but the more research I did, the more I realized that the project would require a significant shift in search-and-filter pattern design across the site. Following protocol and sticking to my comfort zone, I made a series of static OmniGraffle-based PDF wireframes to document the complexity of this interface shift. But when I showed it to my developers, they about lost their minds.

I’ll admit the PDF wasn’t very easy to comprehend. There were so many functionality notations in the PDF that I ran out of colors to code them with. On more than one occasion, the team filled the Basecamp with questions about user flow and logic and progressive states.

The documentation I had produced simply didn’t illustrate the end state fully enough; I followed what had been done before instead of trying out a new but better-suited process. In an act of desperation, my devs finally asked for a Word doc. (A WORD DOC!) Dejected, I sat down in a conference room and sketched my ideal IA tool on the whiteboard, and it was, more or less, a website — a layered and clickable experience.

Now, I could code such an experience — I can write HTML and CSS (and a teeny bit of jQuery). But I’m not as fast as my developer colleagues; in my current role, it is not an efficient use my time for me to code a minimum viable prototype. Thankfully, the prototyping software sector is enjoying a heyday in the form of prototyping tools like InVision, UXPin, Adobe XD, Framer.js, Principle, Axure — I could go on. Currently, I’m using Sketch plus InVision’s Craft plugin to make what I sometimes call “protoframes.” Let me show you what I mean:

The orange button triggers my notes.

As you can see, this prototype is really just a wireframe with hotspots and some transitions. But it takes me less time to lay out a few states in Sketch, sync my artboards into InVision, and add interactivity than it does to approximate and notate that same interactivity in a flat PDF. (And as I learned from our search-and-filter project, flat pages are just too limited to describe the complexity of digital experience.)

I realized that I could add a clickable layer of notes to my prototype in the same way that I built the hotspots that illustrate the interactivity. So, I placed a little button on the views that had notations — I used a bright color, not used elsewhere in the design, so that it would be noticeable, but I placed the button slightly out of the way so that it wouldn’t interfere with other interactive elements.

Notes are turned off by the same button, now the “x.”

Everyone on my team understood what I had done right away; in fact, they used InVision’s Comments functionality to ask questions about my comments! We were discussing aspects of the design in the design. My devs never asked for a Word doc again.

(At the moment I’m trying out UXPin’s capabilities; its Documentation tab adds the ability to pin text comments directly on the UI elements they relate to, which is a compelling alternative to InVision.)

Why prototypes are good for your team

I’m certainly not alone in switching to from producing PDFs to clickable prototypes; almost all the other UX designers and IAs at Hook & Loop have adopted some form of this workflow too. Those of us who design and test interactivity can readily understand the value of an interactive and testable prototype, but roles that tend to work at a more granular level of fidelity (such as graphic designers or certain kinds of coders, who need to retreat and focus on details for hours at a time) can benefit from “protoframes” too. So here are seven reasons why we should stop making pages and start building prototypes that emulate the experience:

1.Your IA notations — and your team’s questions — should happen in the same place as the design.

Trying to connect questions from a Basecamp discussion to a flat PDF is a big pain. It’s so much easier to add a “notes layer” to my project that can be turned off and on. Also, many prototyping platforms include a way to add “comments” to a prototype; that way the discussion can be physically attached to the piece of UI it’s about. As my fellow UX designer Kate Merlie puts it: produce fewer things that contain more information.

2. Flat PDFs are no damn good to your remote developer.

Most of the devs I work with are in a different office. I can’t just walk over to their desks and point around on a PDF. Interactive wireframes give them the chance to click around and examine their own expectations of the product before we hop on a video call to discuss it.

3. Designers don’t have to recreate design in (insert Adobe program here).

Can you believe that our IAs used to make PDFs in OmniGraffle and then hand them over to our designers who would recreate everything in Adobe? That’s crazy! Apart from being a huge waste of time, that process eliminates any possibility of collaboration.

4. Everyone can share a library of elements with Sketch/Craft.

This goes along with supporting collaboration. For those of us using Sketch and Craft, not only can team members work on the same file, we can also use the same design system by making a shared library. As elements get codified during development, they’re added to the shared library for everyone’s immediate usage. Sharing is caring!

5. Clickable prototypes live on one URL, not as an attachment somewhere in your email pile.

Flat PDFs can’t be updated; you must send out a new copy. Soon everyone is looking at a different version, or can’t find the email you sent. One browser-based prototype with a consistent URL can be updated as many times as you like and requires only a browser refresh to see changes.

And speaking of URLs…

6. Mobile prototype on your mobile phone = accurate testing!

You can’t test a PDFs on a phone.

7. Final QA goes more smoothly.

If you’ve already sorted out questions of interactivity and functionality in a prototype, your product will be way more accurate by the time it gets to QA.

How to start (carefully)

Successfully moving from one workflow to another isn’t easy, especially when the workflow affects not just you but the entire team. When I asked my colleagues about their respective shifts away from flat PDFs, we all agreed on a few adjustments that help smooth out the transition to interactive wireframes:

You need to spend some time.

Initially, you’ll spend a lot of time making symbols, adding elements to libraries, and figuring out new software — but the payoff in terms of consistency and speed is worth it.

You need to be organized.

Now that you’re sharing more stuff, you’ll need to tighten up your own process and practices. No more randomly-named layers or lazy symbol construction! And if you’re going to share actual files, you need to develop and agree on a storage system (such as Dropbox).

You need a little patience.

Many prototyping platforms, especially those that sync with design applications, are still in development — which means sometimes the latest update might be a little buggy. Conversely, some platforms might be somewhat limited in terms of animations or logic until those bugs are worked out. Communicate with their dev teams! Let software makers know what you need.

You still need to consider your audience.

All my colleagues agreed: now that we’re all sharing tools and capabilities, it’s easier to produce higher-fidelity wireframes, or use pre-designed components earlier in the process. That’s great in terms of saving time, until the person you’re presenting to becomes obsessed with that one widget’s color scheme instead of the basic user flow. To combat this issue, Infor’s Customer Experience team is developing a “grayscale” version of its component library specifically for wireframing. However you deal with audience expectation, don’t let the shiny stuff get in the way of you getting the feedback you need.

Ironically, it was a low-fidelity sketching exercise — my sad day with the whiteboard — that led me to a happy new workflow bolstered by the latest tools. Interactivity is just a concept that you can use as a tool to help people understand your idea, and a component of design that can be reworked just like color, type, or layout. Use as much (or as little) of it as you need to tell your story, and build it with the tools that provide the most interoperability.

Thanks to the colleagues I interviewed about their team’s workflow:

Becca Kroll, Senior IA for HCM

Kate Merlie, Senior IA for Manufacturing

Jonah Tozman, IA for SCM