Designing in the Browser: Why You Should Make the Leap

Hello, I'm a Web designer at Palantir, and I'm kicking off a series on designing in the browser. Nice to meet you. Designing in the browser can improve your process and make you and your client happier with the final product. This series is important to me because I feel like designing in the browser is an intimidating step for many designers to take. I wanted to do my part to make that transition a bit easier, while giving some insight on the benefits I've found along the way.

Let's get down to it

With introductions out of the way, let me convince you to relinquish your pixel-perfect PSD comps and dive into the browser. Don't worry; there is still plenty of room for sketching and static comps in the world of designing in the browser, but here are some reasons why you should transition into the browser faster:

Your designs will be more accurate and realistic.

On a real, living, breathing site not every image will be perfectly selected, not every title will be 1 or 2 lines long, and not every paragraph will rag perfectly. By working in the browser you can easily show variations in content without having to re-position the entire page. If you are working responsively, you'll actually be able to show how the page reflows rather than try and explain it with 3 different comps.

Not only that, but your client will be able to see how the colors and fonts render in their browser giving them a more realistic view of the final look and feel. Programs like photoshop, illustrator, etc. have specific color profiles and text rendering that will not always be a 1:1 relationship with every browser. To top it off, your page will be scaled appropriately so there will be no miscommunications about font size or zooming. Everything is as it will be* which leads into the next point.

Your clients will have a better understanding of the designs.

Clients won't be caught off guard if colors or fonts render differently once you your design moves to the browser. More importantly, clients will be able to see and play with the designs. You'll be able to show them a button's hover state in action, and how the drop down menu looks when opened and closed. For responsive design, they will be able to see the page reflow in action and they will be able to see how content shrinks and rearranges itself. Showing is the best way of telling in my experience.

You will be able to better communicate with your developers and reduce duplicated work.

Because you are implementing some of these behaviors into your css, you are already communicating better with your developers. You can add comments to your code to help describe how something works (IMO, much easier than marking up a PSD comp) and if you use semantic class names, you can help define the language around certain components early on.

Not only that, but your developer can just pull your code and see your intention exactly (or reuse it exactly). This increases your efficiency tenfold and could, in the end save you time and your client some dough.

Think of the additional control and benefits this could provide if you are a designer who typically sends your designs off to a dev firm, or the collaboration this can perpetuate if you work directly with your devs.

You can execute more control over the final designs.

If you are sending HTML, CSS, and js to your developers there isn't much room to "misinterpret" the designs. Your developers won't have to measure comps in pixels, and you won't have to markup your final comps.

What you created is pretty close to how the final site's markup and CSS will look and feel. Your devs may need to do some tweaking to get it to work within the CMS or to make your designs into templates, but now you have the knowledge and understanding of HTML and CSS. You can give relevant input on any tweaks. If something is deviating from your design, you can suggest an alternative way to mark it up.

You will be faster, especially when working responsively.

Instead of having to create 3 separate comps for every page, and THEN take that and create responsive html, you can just make one responsive prototype for each page.

You can set up base styles that will translate to all of your templates creating a cohesive base design at the core of your site. Imagine styling what a header will look like, and then every time you create that header, it is automagically styled correctly.

These are all things you can accomplish with just basic HTML and CSS, but once you start adding in other helpful tools, the possibilities of automation are limitless. Imagine setting up a base that scales your type AND line height as the font size changes, where your site responsively adjusts font sizes globally automatically at breakpoints. All of this and much more is possible with the tools that are available.

You will have reusable code in the form of either HTML snippets or CSS classes.

Some might argue that you can already copy something you created in photoshop to a new static comp, but what you can't do is maintain the spacing when you paste it, or automatically adjust the container when you make the title longer. You also can't convert a news sidebar into an event sidebar without taking substantial time to re-align everything. Guess what, you can do all of that with CSS and HTML. Being able to repurpose a whole component, or just reuse a class name is amazing, not only for your efficiency, but also for keeping your design cohesive.

You are self-documenting as you progress.

You can add notes to your HTML inline, and if you learn a bit of js or templating languages then you can add some logic to your code that not only tells, but shows how the final product should work. How nice would it be to hand over your designs and you've already written the font, font size, line height etc. You don't have to, after the fact, go back into photoshop and mark up your comps with padding/margin pixels or font details.

Don't worry, we aren't going to jump into the browser in stage one. I still start with sketches, wireframes, and maybe even a few static comps in order to get a basic look and feel down. But once that is settled, I'm itching to jump into the browser and get to work.

If you aren't at least partially designing in the browser, you are missing an opportunity to streamline your process, execute more control over the final designs, and improve your client's expectations and understanding of the design in context; all while working faster by harnessing the reusability of a system and creating a collaborative relationship with FEDs and Developers by providing a better documented design system for implementation.

Now, I can't lie to you and say that CSS and HTML will be easy to learn, but I hope I've convinced you that the effort is worth it in the end. In my next post, I'll provide an overview on where to start if you're interested in designing in the browser.

Here's Where You Come in

I have a lot of ideas to share, but ideally I'll be covering topics you're most interested in. So far, I've considered topics like an intro to basic CSS and HTML, semantic class naming with a quick introduction to SMACSS, BEM, and DRY, Responsive Web Design, working with developers, thinking in systems, leveraging site generators, and many more.

If there is some interest in the series I'd love to expand it, so give me some suggestions in the comments on what you would like to see!

Some of these posts will be write-ups of my—in my humble opinion—very important opinion, while others will just be a list of references and learning materials and why I think they are helpful.

Don't get me wrong: making the transition to designing in the browser won't exactly be painless, but as you learn more and improved your skills, you will work faster and more efficiently and it will all be worth it.

* For the most part.