Why We Don’t Do Wireframes Anymore

Sarah Eva
5 min readMar 23, 2015

Elegant, easy-to-use prototyping tools are everywhere, but we’ve decided to stop using wireframes as a client deliverable. Here’s why.

Over the last few years we’ve evolved our process several times over, in both big and small ways. One of the most significant changes has been in our approach to bridging strategy and design. More and more, we place an emphasis on real content development much closer to the beginning of our projects.

At mStoner, every design project begins with strategy, and our strategies are both broad and detailed. We cover mental models, governance, digital communication strategy, personas, content sustainability, SEO, advertising opportunities, and many other aspects that help make our clients successful even after our engagement is over. As the creative director, I find these documents to be incredibly informative to the creative brief and the design process.

But what we don’t cover in strategy are heavy recommendations for user interface and functionality. In the past, we’ve relied on wireframes to begin that conversation. Wireframes, like the one below, communicated a lot. They unveiled content ideas for the main feature well, helped illustrate how long the news and events listings would be, clarified which links would live in the footer or the header, and much more.

Wireframes also led to a lot of misunderstandings. At times, we placed calls to action in certain locations and clients became attached to that exact placement waaaay before designers or users had a chance to weigh in. At other times, we spent a lot of meetings fielding questions about why there was no color, why the buttons were square and not rounded, and, overall, why it seemed so plain. As a creative deliverable, it was confusing to high-level approvers, underwhelming visually, and generally started off our client interaction with more frustration than excitement. We needed to be making decisions about content hierarchy and sustainability in those meetings, not color or copywriting, so we had a problem that needed solving.

Much of the great thinking about best practices in interface prototyping is applied to industries that are a bit more nimble, with a much shorter sales cycle than a college purchase. When an app developer is trying to make sure its interface encourages a quick, low-cost download, it makes a lot of sense to iterate on that interface, testing button placements, size of headlines, and other layout-related items. Optimizing their interface is the key to achieving their primary goals. Length of sales cycle aside, wireframes can be a hugely helpful tool for any site with the right team and goal set.

But higher education sites have lean teams and hybrid communication goals. This reality forces choices. They’re publishers and reference sites, like Vox; they’re product sites like Amazon; they’re portals for current students, staff, and faculty, just like any other intranet. Meeting all of these disparate goals while properly expressing branding strengths is primarily a challenge of creating great, well-organized copy and imagery.

Contrary to popular belief, digital content doesn’t create itself. Given the lean communications resources we encounter at many institutions, that means we often suggest new hires in our governance recommendations. Grappling with real content and conveying its importance to the success of the visual presentation makes the necessity of that new hire much more salient. A properly staffed up team will help the end product fulfill its most awesome potential, long after launch.

But after 10 years of working with non-profit clients, I’ve seen, over and over, that even upon the recommendation of consultants, staffing models rarely support the hiring of specialists in both interface optimization and content development.

Our clients do a lot with a little, and, for them, content sustainability has to be the primary goal. Interface is important (especially to me and my team), but it’s the rare Chancellor who will make a fuss over a breakpoint or button style, whereas the exact packaging of a feature story can be debated for weeks or months. Yes, months.

UXPin is awesome, though.

That said, we care deeply that the final interface is modern and delightful to our clients’ audiences. But we want to leave our clients in the best possible position for long term success.

We also want our UX experts and designers to be able to fully understand the content reality in order to devise interface solutions that are fully baked, and ready to serve up a sustainable, realistic content hierarchy. Coming to terms with the reality of content sustainability is a big deal. It deserves its own phase, free of the distraction of boxes and moving elements.

This is why we don’t do interface-focused prototypes anymore. Instead, we use a type-only tool to capture and discuss the volume and style of content needed to keep a university site going.

Using Gather Content, we’re able to focus on the words and take a long hard look at things like the feasibility of producing 5–7 pieces of micro-content to accompany each feature story. What’s key is that we aren’t spending time debating tangents like whether the microcontent will appear in the right sidebar or span the center well.

GatherContent is the tool we use to create content prototypes.

This shift means that our prototypes are free of lorem ipsum. The design is optimized from the beginning to put forward, for example, the actual 20-word headlines(!) the news team will continue to write. By removing the crutch of placeholder content, we find we’re paying more attention to the interface — just at a later, more appropriate phase of the project.

It’s not the right approach for every design firm or every client base. But for us, and for higher education, it’s been a big step forward.

Originally published on MStoner.com
Photograph courtesy of
https://unsplash.com/jens_mayer

--

--

Sarah Eva

Writer, pivot-tabler, lover of the new, creative director at #bcorps LimeRed and strategist, www.IfThen.how