Designing it better in the browser

A 10 minute read written by Sam January 6, 2016

An illustration of a website in a browser window

Over the past few years, designing directly in the browser has been a growing trend, particularly amongst designers who also code (or developers who also design).

As with any approach, there are both benefits and limitations. In this article, I’ll go over why we’ve adopted this technique at Yellow Pencil, where we’ve found some of its pros and cons, and offer some tips on how you can tune your in-browser design process to get better results.

First, let’s have a quick dip into the history of the web design process.

A graphic of a pencil that illustrates a waterfall design process

This cheesy pencil graphic was one of the things I made back in my intern days at Yellow Pencil. You’ve probably seen something like it before: some sort of visual metaphor illustrating a linear process in making a website. From research and planning, to ideation, iteration, development, and finally, through to launch. This “waterfall” method was an approach that many of us had used, or still use today.

Sticking to this process as designers, we would typically start in our discovery mode. We’d perform competitive audits, stakeholder interviews, etc… and one of the earliest tangible deliverable we’d create was wireframes: to communicate the structure and layout of the content.

Once the initial round of wireframes was completed, we’d get feedback from our clients and go through a few rounds of iteration and testing. After the wireframes had been approved, we’d start on our visual designs by creating several high-fidelity mockup templates in Photoshop (or Fireworks.. some people still swear by it).

A graphic of several screens from wireframes to designs

Again, we would go through the same rounds of feedback and revision, until we had approved and polished designs. From there, we would hand off our static design comps to our trusty front-end developers who’ll transcribe it all into HTML and CSS templates. And like a well oiled machine, this assembly line process kept things relatively simple and efficient… or so we thought.

Things took a turn in 2007. The iPhone was birthed to the world and three years later, in 2010, the iPad followed, and Ethan Marcotte famously coined the term “Responsive web design” in that one article on a list apart.

A timeline depicting apple device history

Now, if we’re to make a responsive website, we’ll need to make two, or even three versions of every page in our wireframes AND our static designs - One for each screen size: smartphone, tablet, and desktop.

A graphic of several screens from wireframes to designs along with mobile screens

Responsive web design also presented itself as a new challenge for front-end developers - who have always been proud of their knack for pixel perfection - because we weren’t actually dealing with three set screen widths. Our new layouts needed to be fluid width. Essentially, a lot more UX and design thinking goes into the making of a fluid width page template.

So what is in-browser design?

In-browser design generally refers to an approach where instead of spending large amounts of time refining pixel-perfect comps in photoshop, illustrator, or fireworks, we use a different tool: HTML & CSS markup to mock-up our designs.

It’s important to note though that designing in browser isn’t going to solve everything. As with any method, there are always pros and cons. There are also alternative tools you can use that allow you to design for a fluid width layout such as Macaw or Adobe Muse. However, these tools have their limits as well.

Since I’m convinced that responsive web design is here to stay, I believe that designing directly in browser through good ol’ HTML & CSS can give you more precise results.

The limits of designing in browser

While this technique does solve a lot of problems, it’s not without weaknesses. Here are three of the most recurring issues that I’ve recognized:

  1. Technology: Some content management systems aren’t entirely compatible with an in-browser design workflow. If we’re working off of an existing Wordpress or Drupal theme - it may be less efficient for developers to transcribe our front-end templates.

  2. Clients: Since most clients don’t quite get UX sketches or wireframes and prefer visual design, it may take longer for them to see results. Also, it normally takes longer to finish one in-browser comp than a static one.

  3. Painting by the numbers: When we’re confined to using CSS as a means to add a layer of design over HTML - I find that it can often become difficult to be more inventive with our designs and that we lose more of that “originality” that came with using photoshop as a “canvas” to experiment in.

The benefits of designing in browser

  1. Clients: On the other side of the coin, seeing working mockups in-browser leaves less to your client’s imagination. Websites are interactive, and while showing static comps will give them a good idea of how it will look, showing them in-browser comps will give them an even better idea of how it will work.

  2. Designers: Your clients aren’t the only ones who will benefit from seeing your designs in context. Having the ability to test on multiple screens and devices earlier will save you a lot of frustration down the line. Especially when these small changes and fixes will take much more time once we’re developing in the CMS.

  3. Time: HTML/CSS/JS is just an alternative tool to designing a website. When we don’t need to create final looking, static designs for multiple screens and breakpoints - we can shave off a lot of time spent on pushing pixels in photoshop… Pixels that would need to be revised in the front-end. And while it may take more effort to make an initial in-browser design comp, it’s way more efficient to iterate and make small adjustments to the designs through HTML and CSS.

So what does an in-browser design workflow look like at Yellow Pencil anyways?

Well, at YP, we don’t have a prescribed process for every project, since each customer presents us with a unique situation. But, like most projects: it all starts at research and discovery. We might start by working closely with our clients on a competitive audit and look at examples of other sites that we like/dislike. We can also ask our stakeholders to come up with some adjectives to describe their brand and what they’re looking for in their new site.

We can ask semantic differential scale questions to help us understand what our clients are looking for at a more specific level. It’s important to keep in mind that the way you interpret a certain adjective can be subjective.. In order to better capture what our clients are looking for in terms of visual branding for their new site, we like to show varying degrees of these adjectives by casting a wide net through our style tiles.

Style tiles are static deliverables that we make in Photoshop, and even though our end goal is to design a brilliant site in-browser, we should never start from scratch. We need a way to iterate our visual designs independent of structure, content, and layout.

Three screenshots of ACAD style tiles

Here’s an example of the style tiles we made for the Alberta College of Art and Design. In our early research sessions, our stakeholders decided that they wanted to appear “bold and professional”, but were also looking for an “easy-going, and casual” feel to improve their “approachability” factor. So, we put our visuals on a scale in our style tiles: from bold, sharp, and strong on the left, to soft, light, and free-flowing on the right.

Screenshot of the Final ACAD style tile

Once we had an idea of what our clients liked (and didn’t like) about each of our style variants, we compiled one final tile that represented the visual design direction for the project going forwards.

Style tiles are crucial to our design process because they reduce the risk involved with generating our visual designs directly in-browser.

At the same time that we’re sorting out our style tiles, we can start wireframing our site structure. As always, we usually start by sketching out layouts with pencil and paper (or marker and whiteboard). We’d show these early sketches to our clients, and walk them through the rationales to make sure we’re meeting their expectations around functional requirements.

A GIF animation of ACAD's in-browser wireframes

Once we’ve shared our initial ideas, we can start building our in-browser wireframes. For these, we’ll use certain features and components from the Foundation framework - again, never start from scratch because ideally, these will also be our base front-end templates.

This is also a good point in the process to test our layout and structure. We sit some testers in front of a computer, tablet or mobile phone - and see if there are any changes we need to make. And much like our style tiles: it’s all about eliminating the risk commonly associated with that “big reveal” early on.

Once we have both our style tiles and in-browser wireframes approved by the client, we can start coding in the visual designs directly in-browser.

Our first step in integrating the designs with the wireframes is to “go back to the drawing board” and sketch things out. We look at the structure and ask ourselves questions like, how does the HTML need to change? What divs/sections need to be nested where? How can we add certain visual treatments to an element through CSS?

If you’re trying out this technique for the first time, here are some tips and tricks I’ve found that can shave off precious time and make your coding more efficient.

1. Organizing your SASS partials

Folder structure of my SASS files

This one is a must have on any web project. I like to loosely model my SASS folder structure after the “atomic web design” system. My components folder will contain all of the smaller, repeatable elements such as forms, tables, buttons, and images etc. My modules folder will contain files that group unique components that perform a specific function such as a news feed or an image slider. Finally, my layout folder will contain all my SCSS partials relating to my page templates. You get the idea :)

This way, you can find the pieces of CSS that you need to edit for a particular element, component, or module faster.

2. Add media queries inside of your class selectors

Screenshot showing how I've nested my sass rules

…Instead of the other way around. This way, you’re not scrolling back and forth between different media query sections in a file to style the same element.

3. Progressive enhancement

It’s important to always build with progressive enhancement in mind, starting with your small screens or minimum browser requirements first.

I find that this helps me write less redundant CSS rules that may get pulled in by mobile devices. For example, if you write a fancy animation rule for an element in a large screen before considering how this works in smaller screens, it’s easy to forget to ensure that this rule is only parsed by a desktop sized device.

4. Don’t forget about best practices

It seems pretty obvious, but there will be situations where tight timelines can lead to “hacky” code. Building things right the first time will take more time, but also saves you heaps of time down the line when simple HTML/CSS fixes may take much longer in development.

In a way, it becomes a lot like sculpting with clay. You start by finding inspiration for what you want to make and pick a style direction. You define your structure by building an armature. You throw on clay and begin shaping out your form - stepping back at certain points to ensure that all the pieces are in proportion. From there - you continually refine the details until you’re done!

Just remember these key things when designing in-browser.

Never start from scratch

Use photoshop, or whichever tool you like, as a canvas for iterating your visual styles (not your static comps). Then use existing pattern libraries or frameworks, like Foundation or Bootstrap, to quickly iterate your wireframes.

Eliminate risk early

Set a direction for your visual designs and test your structure and layout before you begin designing in code. Avoid the “big reveal” at all costs.


Always be sketching. It’s the simplest way of expressing your ideas, and also a great way to avoid that “painting by the numbers” problem.

Once again…

Designing in-browser isn’t the solution to all situations - but - it may be the most precise and efficient way to produce a responsive website from start to finish.

So, if you’re undertaking a fresh web project - give this approach a try. Experiment with it. Try new things and make the process your own. If you’re a designer or developer interested in learning HTML/CSS, do it! …and start coding. As designers, we all had to learn photoshop basics at some point.. so now, let’s learn some new tricks to help us add more beauty to our designs.

While I’ve found many of the ideas and examples covered here fit quite well with smaller, more nimble web projects, scaling them to fit the needs of much bigger websites tends to add new layers of complexity to the mix. Please stay tuned to our blog, where I’ll ramble on about how we can adapt some of these techniques for working in bigger teams and on much larger sites in a future post. :)

Have any thoughts or questions around designing in browser? Send me an email or leave a comment below!