Wireframes are dead. Here’s what’s taking their place.

Go on, take a look, she’s still up and running:
TheProject.html

The web’s done a lot of growing up in its quarter-century of life, so it’s surprising that so much of the web design process is still rooted in traditional print design. We sketch out ideas for layout, get client approval, then go back and add design elements. But with the web evolving into a dynamic medium of multiple devices and constant interactivity, there must be a better approach.

The trouble with a static approach

The traditional approach to designing a website for a client, sending them flat images of how a page might be laid out, has trouble keeping up with the way modern sites are built and it leads to a bewildering amount of lag in the approval process. So what’s wrong with it?

It’s too limited

Websites aren’t like TV, they don’t just change the size of the picture to fit the screen they’re on. They scale and flow and reorder themselves to provide the best experience on whatever device they’re being used on. And while you can do a different static design for several different device sizes, it quickly becomes time consuming and wasteful. What if your client’s looking at your design on a hybrid laptop or an iPad Mini or some 6.2” inch monster phone you’ve never come across before? And worse, there’s no way to get over the feel of how the site will work if you’re sending out static designs. Modern websites are tools for users to find and act on information, so you need to get a feel for that sort of interaction as early as possible in the design process.

It’s not intuitive 

You can always tell a good website because it doesn’t have to explain anything. Users feel that they already know how to do the things they need to do. The trouble with wireframes and static designs is that you need to explain everything. Explain how the nav menu moves in from off-screen, how the buttons raise up to show they’re interactive, how the footer slides out from under the page content to make it obvious you’ve reached the end… even the best wordsmith will fail to get across the feel of these things. They work because they’re subtle, and if you have to explain them, they lose their power.

It’s really time consuming

All these different device-specific designs and copious explanatory notes make static wireframing and design a very time consuming and therefore costly process. And if you’ve ever had to go through and change some footer text across 30 page designs in Illustrator, you’ll know the pain of making changes at this stage. Which is a shame, because this is exactly the point you should be encouraging feedback from your client.

Meet Live Prototyping

Prototyping has evolved over the past few years as the limitations of static images have become more apparent. The simpler versions just involve uploading your designs to a website and linking them together with hotspots to loosely emulate buttons. Some services let your customer drop comments and questions onto specific parts of the page. And on the designer side, tools now let you create symbols and styles that let you quickly make changes across all of your designs at once.

But that’s only half the story. At Three Little Trees, we’ve started using a system of Live Prototyping which gives the customer much more than a series of linked designs — it gives them a fully working website that responds properly to all different screen sizes and devices, animates its appearance and interactions, loads and navigates like a finished site and can easily be shared with stakeholders without any explanation.

Here’s how it works: once we’ve done the research and mapped out the user journeys, our designers use Webflow, one of the new generation of visual code builders (colloquially the ‘web building for designers’ tools) to quickly create a simple, working version of the site. The customer can see it come to life and their feedback allows us to iterate and improve right from the beginning of the process. This not only makes sure we’re on the right track, but also avoids that dreaded ‘big reveal’ to the client after weeks of work. And we’ve found it to be incredibly helpful:

It’s intuitive

It’s a proper website. It works just like a normal website, so clients can visit and click round it without needing any explanation. They can pick up their phone or tablet and look at it there and it’ll format itself correctly. 

It’s collaborative

Having the client involved in the living site from the beginning helps you to clarify things, spot things that may have been missed and quickly iterate to make sure you’re hitting all of the client’s key requirements.

It’s faster

While it certainly takes longer to build a working prototype site than it does to draw a static illustration of one, the process of iteration gets hugely accelerated. Because the prototype is styled using CSS, it’s simple to change design elements across the entire site. It’s so fast that we find we can make changes live while talking to the clients. And if they really wanted to see what that nav bar looks like in pink, it’s easy to change it back again with pretty much zero time wasted on redoing designs.

It gives you better usability testing

Testing with users gets you much more informative results if you’ve got a prototype that actually works like a website. There’s less guesswork needed and the whole testing process is much more natural.

It highlights the importance of responsiveness and interaction

The modern web lives on screens from just a couple of inches wide to massive multi-monitor displays. It lives on Smart TVs and in watches. And every device means the user will need different things from the site. Building a responsive, adaptive prototype right from the beginning keeps everyone focussed on this fact, helping inform design and UX decisions and avoiding that ‘crammed in’ feel you can get on smaller devices where the content hasn’t been properly thought through.

How to make it work

As with any process, there are some core concepts you need to stick to when prototyping to make sure it works well and produces a good return on your investment of time.

Don’t over-fuss

Most designers are perfectionists. Add in the extra complexity of the code and you can stumble down a path of tweaking that could be endless. You can get really excellent results with Live Prototyping tools, but there’ll always be some tiny bug that needs a developer’s experience to fix.

Don’t over-promise

Likewise, there are things you can build into a prototype that might simply not be feasible on a final site using the actual data from the client, when everything has to work on every browser and device. Sharing with your developers early on will help you avoid showing the client some amazing but impossible thing that’ll lead to them being disappointed.

Share widely

Share internally as much as possible. Get input from your developers, other designers, anyone. Everybody’s a web user, so use them for user testing. How much you ask your client to share at their end is a more delicate matter. Input is good, design-by-committee is bad. But involving key stakeholders early on avoids nasty surprises later.

Share often

One of the best parts of Live Prototyping is that you can iterate more like a software developer, publishing changes daily, even hourly if you need to. The client will always have access to the latest published version, so you can quickly get feedback on specific changes and fixes, speeding up the iteration process considerably.

There’s much more to be explored. It’s an exciting new way of working and we’re enjoying discovering its pleasures and pitfalls. I’ll be back with an update once we’ve got a few more projects under our belts.