Our processes and methodologies for building client websites evolve all the time. We’re always looking for a better way to work—whether that means finding ways to increase our efficiency, improve our communication, or reduce friction points for end users—we never stop looking for ways to keep doing good.
Oftentimes, those improvements and evolutions come in the early stages of our process. Recently, we’ve searched for a better way to wireframe our responsive websites and apps—and we’ve found a terrific solution in building website blueprints using actual HTML.
First, some background into our process.
Why wireframe websites?
It’s part of our normal process to build a set of wireframes for each website or app we build. It makes the most sense for us to wireframe just about anything interactive because there are usually a lot of stakeholders, each of whom have their own goals, agendas, and priorities. Wireframes, along with requirements, help us communicate our plans and intentions to everyone involved, both on our end and the client’s end.
Before we start wireframing a website or app, we’ve completed our discovery process with the client—understanding goals of their business and this project. Our process translates what we’ve learned and places it into a low-fidelity visual blueprint.
Wireframing is also a core piece of how we work with website content. Oftentimes, our wireframes define content themes—based on things we’ve learned through the discovery process—so we can create or collect content that matches users’ needs and organization goals.
We build wireframes because they’re a much more cost-effective way to iterate. Naturally, it takes us far less time to assemble plain gray boxes and adjust hierarchy than it does when we’ve moved into the visual design phase, where a structural change could render the entire design ineffective.
Using HTML to wireframe
For our website projects, we’ve shifted our wireframing process almost entirely to HTML-based wireframes, as opposed to traditional static, unchanging layouts and PDFs.
Since every website we build is responsive—that is, usable on any device or screen size, small or large—it’s rarely prudent to assemble page layouts that show a screen scenario at one particular size, as static, fixed-width, PDF-based wireframes of the past have done. The simple fact of the matter is that things are fluid—a top-locked navigation bar might work great on an iPad, but might be out of someone’s natural one-hand reach on an iPhone 7 Plus. A menu might tuck away neatly into a drawer on a phone, but become a discovery disaster on a laptop.
When we started building responsive websites in 2011, we tried to use our normal processes and adapt them to new challenges—for example, building a static “mobile” wireframe and a “desktop” wireframe. This led to issues and made our developers’ (and worse, visitors’) lives more difficult than necessary.
“Sure, this layout looks great on an iPhone 4 (remember, we’re in 2011! Nyan cat and planking!), but what about on my Android phone with a larger screen? What about on my tablet? What about on a 21:9 4K desktop monitor, compared to the ancient 19” monitor on the intern’s desk?”
Or, we might have built our two wireframes, large and small, iterate and make revisions, then find out that we built an inconsistent experience between the two different layouts. It was an inefficient process, and we needed a better way to show page layout in a world where there are a million different scenarios for just how a person views a page—a challenge that hadn’t existed until everybody started carrying a smartphone.
Building wireframes in HTML solved the efficiency problem. Since we were assembling pages in the browser, using real markup and styles, we could instantly see how a layout might behave on a phone. On an old phone. On a giant phone. On a tablet. On a projector screen. On a giant desktop. On the intern’s monitor. And everything else in between.
Wireframing responsive websites in HTML gave us the gift of responsive responsibility. Everything placed on our HTML wireframe needs to go somewhere at every screen size. In our early days of responsive web design, we’d take what’s now seen as the easy way out and simply zap anything we couldn’t comfortably fit on a mobile screen. Just totally remove it. Of course, over time, we learned that it’s not a good idea to penalize users for the device they’re using—that people want the same content whether they’re on a phone or their office PC.
There’s also the benefit of speed and efficiency. Like the websites we eventually build based on our wireframes, there’s only one set of code—no need to maintain separate “mobile” and “desktop” wireframe files. We change the text on a button once, not several times. Since wireframes are designed for faster, cheaper iteration, it’s a no-brainer to minimize the amount of time it takes to make changes.
With HTML and CSS wireframes, you can also be as detailed as you’d like. You can create lo-fi screens that aren’t much more than a gray block with some simple text, or go the opposite direction—high-fidelity—and introduce brand colors, typography best practices, and real imagery, though these things are typically handled in the visual design phase once wireframes are nailed down.
Our tools for wireframing in HTML
Another nice thing about HTML wireframing is that you don’t need expensive software.
Text editor
You’re not doing much more than assembling some HTML—any text editor will do. I’m personally a fan of Coda 2.
Tachyons CSS
If you know me, you know I’m a fan of Tachyons, a lightweight CSS toolkit. I use it for just about everything these days—from wireframing to full-blown production-ready websites. Tachyons majorly speeds up the time it takes to wireframe with HTML since it’s predictable, flexible, well-documented, and responsive by nature. When I’m wireframing with Tachyons, I never have to touch CSS at all—I can focus on designing and iterating.
Unsplash.it
I love the impossibly vast collection of free photos from Unsplash. I also love services like placehold.it that make it easy to drop placeholder images into designs. Unsplash.it is a beautiful marriage of the two, allowing you to quickly drop placeholder photos from Unsplash into your designs at any size you need. Plus, it’s complete with grayscale filtering, blurring, and random images. I’ll turn to Unsplash.it when I want to show a photo in an HTML wireframe.
Web Browser
HTML wireframes are actual HTML files, so you’ll need to preview them in a browser (or preferably, multiple browsers on multiple devices).
Web browsers are a lot better for showing how websites should function than PDFs.
HTML isn’t always the answer
While HTML wireframes are terrific for designing HTML-based websites, we don’t use them for every project.
When we’re designing something that has heavy functionality, like a fully custom mobile app, we’ll use different tools. Sometimes, for us, it’s faster and easier to show certain interactions and transitions in a different program than it is to code something for a simple wireframe.
Another time we’ll stick to our other tools is when we’re building something that’s not responsive, like a kiosk that only has one screen size and is only ever used one way. When pixel perfection is more important than responsive behavior and layout adjustments, we don’t need a tool that prioritizes the latter.
When we’re not wireframing or prototyping in HTML, we’ll usually turn to Axure RP—though it’s hard to go wrong with popular industry tools like InVision, Balsamiq, OmniGraffle, or Microsoft Visio—or any other program. Pencil and paper can go a long way, too.
Use whatever makes you comfortable
Whether you venture into HTML, stick to a purpose-built program, or sidestep wireframing all together, use whichever tool or method that allows you and your team to do your best work. I’ve met interaction designers who could build great things in Axure but couldn’t comfortably write the tiniest bit of HTML markup. For me, personally, I feel handcuffed by programs like Photoshop and Sketch, so I prefer to design everything in the browser using HTML and CSS.
I’m always an advocate of using the tools that allow you to work comfortably to solve the challenges at hand. For our team, that means designing responsive websites in a way that’s responsive from the beginning.
Want our team on your team? Let’s talk about how Liquid can help.