So you’re a designer or UX professional, and you work with the web. Everyone’s telling you that you need to learn how to code: at a bare minimum, to gain a rudimentary understanding of HTML and CSS. And they’re probably right! After all, if you’re involved with making things for the web, it doesn’t hurt to get your hands a little dirty in the stuff it’s made of. Yes, coding can be intimidating, but have no fear. There’s a nice, easy place to get started: wireframes.
Wireframes have an important place in the design process. They allow us to make key content, UX, and information design decisions without investing premature effort in refining look and feel. But in a responsive design process, the old black and white PDF can quickly become a cumbersome, misleading, throw-away deliverable. Which is why creating wireframes in HTML and CSS can be a great move for you and the project stakeholders.
Now before you start breathing into a paper bag, let’s get something straight. No one’s expecting you to become a web development wizard overnight. Wireframes are stylistically dirt simple, so building them in HTML/CSS is a lot easier than marking up a fully-designed web page. OK, ready? Deep breath—here we go!
First things first: strategy#section2
Like every project, RWD wireframing needs some degree of research and planning. Ideally, your IA work will be fresh on the heels of some great content strategy, setting you up with a plan for real content, information hierarchy, and user workflow.
Once you know what view you’re going to wireframe (homepage, internal page, etc.), get with your writer or content strategist and figure out what the words are going to say on that view. You want the real ideas and words that will end up on the live site (or as close to it as you can get at this point). It would be a shame to come up with all these fancy layouts if it turns out there isn’t content for them to support in the first place.
Meaningful markup#section3
Now that we have content, it’s time to write some semantic HTML! Remember that when you’re first marking things up, visuals aren’t important: don’t make something an h5 just because it should be small. If it’s the second-ranking heading on the page, make it an h2—later, we can make it look smaller with CSS.
In fact, don’t even look at it in the browser yet. Just make the markup beautiful. Make sure the structure is meaningful, and write only as much markup as you need, and no more. Writing really good semantic HTML is a fine art, a perfect balance between accuracy and simplicity.
Once the markup makes sense to you, grab a front-end buddy and get their opinion on things. Getting even a casual peer code review before you write any CSS can save you a lot of heartache down the line.
Talking through your markup decisions has additional benefits, too—it helps keep you and your team members on the same page about style choices. It gives you the benefit of each others’ experience, and naturally moves your team toward a consistent approach. Since you never know who’s going to be working on that code later, it really helps to have a common understanding of why you’re doing things the way you do.
Start your styling engines#section4
Once the content is marked up, you can move on to small screen styling with CSS. Keep the aesthetics to a minimum: a grayscale color palette, basic web-safe fonts, some rules, a generic interface icon set, and a handful of crossed-out FPO images. No need to get fancy, just make it obvious what everything is, and get that information hierarchy clear as a bell.
After you have the smallest screens looking good, moving to paper sketches can be an efficient way to iterate with wider-screen layouts. Quickly jot down how you think that mostly single-column mobile hierarchy is going to shift as the browser expands in width.
The grid system is your friend to aid in quick decisions and “trying things out.” Lots of people like off-the-shelf solutions like Zurb’s Foundation, or you can roll your own like we did at Bearded with our starter-kit, Stubble.
Implementing design patterns#section5
When thinking about what the design will do at various viewport widths, consider the groupings of elements in front of you. How does the navigation work? Is it all one thing, or is it broken into segments? Is it horizontal or vertical? How many nav items will you have to squeeze in there? What else will it be sharing real estate with?
Next you might consider if the site requires a search function. How does that work? Does it have filters, or is it a simple single-field search? Will users need a button to initiate the search request? These sorts of questions will help lead you to more natural, effective layout decisions.
Implementing these elements can be made easier with design patterns (something the ever-inquisitive Anna Debenham discussed recently in her post Getting Started with Pattern Libraries). And when you’re considering the many responsive design patterns that are at your disposal, you don’t have to recall the myriad options on your own. Brad Frost has you covered with his responsive pattern library.
Keep working your way through those groups of elements, and pretty soon you’ll find that they’re coalescing into a full-blown page layout. It may take a few iterations to get all the parts to jibe just right within the larger system, but that’s all part of the process.
One of the nice things about wireframes is that, because of their aesthetic predictability, lots of your styling and markup will be reusable from project to project. Get a few under your belt, and the next batch will be a breeze.1
Fear not, my code-averse friend#section6
If you’re a designer or UX professional, and you’ve never touched a lick of code in your life, fear not. There are resources out there to get you up and running. For beginners, there’s a swell new book simply called HTML & CSS that walks you through the basics while being exceptionally easy on the eyes. And let’s not forget the endless video tutorials of Lynda.com. New technologies can be daunting, but once you get going you’ll be glad you took the leap.
The other side#section7
Learning new skills and developing new processes is a lot of work. And with the web changing so rapidly, it can be tough to distinguish between passing fads and the developments that will help you take that next important step in your career. If you work with the web, however, and the question is whether or not to start coding—I can assure you that we are definitely talking about the latter.
When we build our wireframes in HTML/CSS, we can get a more accurate representation of a responsive web experience—because it is a responsive web experience! The code we generate lets us, our teammates, our clients, and our testing subjects judge our work more intuitively in its native environment.
In the process, you’ll be getting closer to the medium in which you work. The web is, after all, code. And understanding that code means better understanding the limitations and possibilities of your discipline. On top of that, working in HTML and CSS can create actual, useable code that will become the basis of the final web product. Losing those PDFs means one less throw-away deliverable (and less throw-away hours) in our lives. And who doesn’t want that?
I love this concept and the value proposition (we debate it often here at our shop). Our challenge is balancing speed and coding wireframes when it is most appropriate for fidelity, budget and workflow. Thanks for the encouragement!
Chris,
When you move to designing in the browser, too, the long-term benefits are obvious!
Also, there are many ways to raise efficiency with this process, some of which Patrick Fulton and I talk about here: http://www.creativebloq.com/web-design/three-ways-design-extensibility-21410721
I’ve been known to knock out a homepage wireframe in under 2 hours using our starter kit. 🙂
MG
Great article. I’ve always found it easier to demonstrate a concept through a functioning wireframe. In fact, it’s a great way to start usability testing ideas by validating working ideas so early on. I personally use the framework Wirefy but I definitely want to test out Stubble
Such a great read – we started doing this at Forty on our more complicated web-app projects and it’s like it was made for an agile shop; it’s so much easier to communicate functionality with our clients when they can actually click through the framework.
PS – I’m finding codeacademy.com to be an excellent resource for HTML and CSS as well!
Good point Larissa! Codecademy is great.
Also, for in-browser annotations, there’s metaframe: https://github.com/elliance/metaframe
MG
This is a nice reminder to focus on planning properly before coding. I’m looking to dive in with http://teamtreehouse.com/ myself and do this full time. Thanks.
Nice, another fine learning option with Treehouse. Good luck Marcos!
Hi Matt,
What the next step after we finish our wireframe in HTML code?Should we move to Photoshop to adjust the color, matching font style, etc? Or we can stay on the wireframe and make it looks good without moving to Photoshop?
I need your opinion how the next step should be. Because sometimes I need to go back to Photoshop after I finish my wireframe in HTML code to make it looks good as a real website. In Photoshop I feel confident to play with color, add some decorations, matching font-style before I apply them to my wireframe. But I know It can be done by adjust our CSS.
That’s why I need your opinion how the next step should be 🙂
Really great idea! Got quite sick of throwaways and the unicorns are coming. As someone who learns better from inspecting source rather than reading instructions, I’ve started to use Webflow to wireframe. I can export the code from there and inspect each section and element, gaining at least a semantic understanding of the code and markup.
I’ve read HTML & CSS, and it’s fantastic for those that retain ground-up instruction. Nice resources all around. Thanks a bunch.
Hear hear.
Been doing this for 2-3 years now, no throwaway psds, no inconsistencies, a REAL stylesheet, which actually serves as a stylesheet and even more important, made me think more about information architecture than I ever had when designing in Photoshop.
Triple win.
Combined with pre-processors, mixins, extends and sass placeholders: almost pure gold.
I don’t think that this is a good idea, as a designer you should focus on what really matters: colors, patterns, behaviors or interactions, not on writing code. I’m really supporting the idea that designers should know the web beyond the photoshop, but writing code for wireframes… I’m not sure that this is a good advice. Developing a html&css; prototype could be very time consuming process. Time is precious. There are a lot of great tools available on the market that can save our time and help us to deliver great prototypes at the same time. Why not to use these tools?
I’m sorry but this is going to sound snarky. In the year 2014, there is a job description for Web Designer, Interactive Designer, UX Designer, and at minimum it requires knowledge of HTML/CSS. I’m one of the web designers that had to cut a place for myself in the market from 1998 – 2006 or so when employers said, “but I already have a designer, what’s your value?” If you want to work the medium, know the tools. For pete’s sake, even Photoshop will write CSS for you now. It’s shocking that an article like this would appear on ALA today.
The article isn’t as shocking as realizing there are people that have managed to survive this long on the understanding of the theory of UX alone. If not for employment purposes, one would hope that an inquisitive disposition might lead to further exploration in one’s field. That’s like having an art teacher that never produced any work- can’t paint, draw, or sculpt, yet is considered to be an “expert,” and is trusted for their opinion. How can you value their critique completely if they don’t even understand how the parts function and come together?
If anything, a common base level of understanding or shared skills benefits all those involved. It’s key for any and everyone involved in design to at least dabble and experiment with development, programming, IT, etc. Also your team will be less likely to laugh at you when you request something that’s less feasible to implement- mainly because you’ll understand what’s feasible and what isn’t….
I’d been a print designer for, oh, ever, but started learning HTML/CSS as I began making websites. A basic knowledge of code is a must for designers, IMHO — especially on small or distributed teams. It is immensely helpful for brainstorming ideas with developers.
But I’m still building basic mockups in Adobe presentation software, and am finding it an increasingly kludgy way to work. Although it’s comfortable, I can’t show any interactivity and the process is time consuming. I think the time is better spent creating basic code and dynamic wireframes that can be expanded on later. With responsive design and gajillions of viewport sizes out there, this seems to be the most forward looking strategy, and still follows Design 101 “Form follows function.”
So thanks for the article and listing of various flavors of wireframe software — this plus a good text editor should help get me where I need to go.
This article isn’t actually about the merits of designers learning about html/css (despite the introduction), it’s a suggestion to wireframe in code. We all agree that some cross-discipline knowledge is beneficial.
Now, each to their own, but… As a UX designer and front-end coder (no graphics) I try and keep the ‘how’ part away from the wireframe stage as much as possible. Wireframing is about ‘what’, and tying that too closely with the ‘how’ of coding can stifle creativity.
While I can see this approach working for relatively standard website projects, for something like app design it seems way too cumbersome. I find prototyping in Omnigraffle very fast and Invision provides enough interaction for wireframes. A homepage mock-up using those tools can take a lot less than 2hrs.
In any case, thanks for the article Matt 🙂
Rizqi,
Take a look at a couple of my other articles for help with those steps:
http://alistapart.com/article/responsive-comping-obtaining-signoff-with-mockups
http://alistapart.com/article/client-relationships-and-the-multi-device-web
MG
Wow, thanks for all the feedback, folks! There are certainly many tools out there for use, and they all have their merits.
My advice would be this: don’t be dogmatic about your tools. Choose the right one for the job. There may be points where Omnigraffle is an efficient way to sketch out an app interaction (personally I use whiteboards, sketchpads, and then … HTML and CSS – which is really nice for user testing). But remember that Omnigraffle etc. files get thrown away sooner or later.
At a certain point, code must be written. And those 2 hours spent writing wireframe code means less hours spent later in the project. It’s important to consider project-scale efficiency, and not just the efficiency of a single deliverable in the process.
Ben Callahan at Sparkbox talks very eloquently about the path to fluency with a new tool. With any new approach there is a learning curve before we achieve fluency (and thus efficiency). It strikes me that tools go in and out of fashion (how are those Flash chops holding up now, amiright guys?). HTML and CSS, however, (being the primary building blocks of the web) will be around for a while yet. Whether you implement with HTML and CSS on any one part of the process or not – it seems like a wise investment of your time if you’re building web things.
MG
“and a handful of crossed-out FPO images.”
Or use dummyimage.com or any of the other dummy image services http://www.russellheimlich.com/blog/list-of-dummy-image-generators/
No need to waste time generating FPO images yourself.
Hey there Russell,
Personally I prefer my own images because they’re visually more unobtrusive. But if you are going to go the generator route, and need a little pizzazz in your life, don’t forget Nice Nice JPG:
http://www.nicenicejpg.com/
MG
I’m glad to see this concept catching on. I have been using this method for about 6 months, ever since I discovered Foundation by Zurb. Clients love seeing a functioning wireframe. It gets all the team members on the same page and moves the project along faster. Everybody wins.
After designing an entire responsive e-commerce website using only balsamiq and some grids to show breakpoints I discovered Adobe Edge Reflow. It’s currently a free beta so some functionality is TBD, but it can take a photoshop mock and output a decent starter in-browser mockup with custom fonts, then you can edit the css and html assets manually to create a final interactive responsive mockup. I think this workflow shows promise, and would encourage UX designers to try the program and inform Adobe about what works and what doesn’t so it can reach its full potential.
Hey Matt, great article. How do you suggest dealing with the problem that a lot of folks new to code might not be writing the most semantic markup? Or using pure CSS when a dev is using SASS/LESS. Do you feel that handing some OK code (wireframed or with aesthetic CSS) to a developer that might have to be re-written is still a better starting point than using a responsive wireframing tool like Axure? Been struggling with this for a while with an in-house team that’s stuck on outdated workflows.
I think there are two factors that make this approach more valid; responsive and AGILE. with PSDs, UI developers and UX we end up with Wgile, passing assets along each sprint to the next team. Blending asset creation across disciplines would allow for more agile collaborative approach.