Proposify lets you write and design beautiful proposals in half the time and get faster signoff from your client.
In January, my 30 day challenge was to limit my social media. That was a productive month.
In February, my 30 day challenge was to eat more slowly. I did that by counting to ten between chewing bites of my food. I tend to wolf down my food, which doesn’t give my stomach time to say “Hey, I’m full enough to stop.” I was also raised to finish everything on my plate, but sometimes it’s better to stop eating and leave leftovers on the plate. It’s actually been a really great challenge, and one I hope to keep doing in some form.
For March, my 30 day challenge will be not to reply to external emails. Email continues to be my nemesis. It’s so hard to prioritize important things over the pelting of lots of emails that claim to be urgent. Answering emails provides the illusion of progress, but it’s one of the least scalable ways to communicate. When you answer an external email, you’re usually helping one person in private, as opposed to helping many people at once like with a video. And of course when you’re answering emails, you’re usually reacting rather than plotting an active course forward.
Last night I got the chance to hear Fred Brooks talk about different aspects of software engineering and management. He told a story about the IBM System/360. Apparently a few months before the public launch, a smart manager concluded that the team need to focus on work with no distractions. So the manager decreed: no meetings with sales people or other non-related internal staff. What the team needed was to “just be mean” and buckle down and focus on the most important goal, which was meeting their launch deadline.
March is a great month to do some deep thinking about the future and various work and personal projects. So I’m going to try to do more of that and less answering email. Sorry in advance if you write but don’t get a reply from me.
Try Squarespace with a 14-day free trial, 24/7 support, and no credit card required.
A better web starts with your website. Create yours at Squarespace.com.
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!
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.
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.
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.
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
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.
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?
