Designing in the Browser

Once upon a very long time ago (at least long ago in web years), all websites were designed twice. First, a visual designer would open Photoshop and carefully lay out beautiful images, fonts, colors and blocks of Lorem Ipsum with ideally-sized chunks of nonsense meant to represent future content.

Desk with computer, pencils, and lots of cords

The design comps would go to the client for approval, and after much applause and many encomiums (hopefully), the comps would be handed off to be turned into a live website. The coder(s) would then face the Herculean challenge of trying to spin a golden site, pixel by pixel, from the strawman comps.

And we did it. Or tried really, really hard. And when clients emailed us to ask why their beautiful comp looked different as a website (thanks, Internet Explorer), we bravely battled the technology in hopes to make it look more like what the more sophisticated Photoshop files had promised to be possible.

But technology changed, screen sizes began to vary, CSS matured from infancy, folks discovered news ways to be clever, and folks began to realize that we had a new option. Those who could design AND code (sometimes called Unicorns) could skip Photoshop all together.

So how does it work?

Well, just how it sounds. You take raw HTML page and start laying on the CSS to create your design. An overview of our process is below, if you want to skip ahead. But creating website designs in the medium they are meant to be used in can allow for greater efficiency and flexibility.

Of course, not everyone is in love with this process, so let’s break down both sides of the story:

Pros

It’s efficient. Time spent designing is the same time spent coding: we build once, not twice.

Client communication is smoother. Realistic expectations are set as we go and browser funk is addressed as an integral part of the design process rather than an afterthought.

Responsive design is empowered. Each screen size is addressed as we go: there’s no need to mock up pages in three sizes each.

It’s flexible. Rapid changes are easy to implement. We often invite clients to live-edit design sessions to power through those final, fidgety design choices.

The CSS is done when the design is done. Yes, this is just restating the first pro, but we’re a small design team, so we can’t over emphasize how much efficiency matters to our business.

Cons

The designer needs to be good with CSS and HTML and design. No ifs, ands, or buts about it – if your designer doesn’t have the code chops, this method will not be an efficient model for your team.

Not everyone can be creative with code. Many folks who are designers and coding whizzes still like the blank canvas feel of starting a design in Photoshop. It is the medium they are the most creative in.

You’ll write CSS that will never be used. If you need to present more than one design concept to a client, it can mean writing CSS that will never see the light of day. It can be frustrating and feel like a waste of time, but I might argue that the more CSS you write, the better you get. :)

Our Process

  1. Research: We spend some time looking at the client’s current site, other similar sites, the company’s competition, and other places where various design elements are done well or poorly.
  2. Wireframes: Or sketches. We start with the rough content that the client wants to include and sketch out some ways that the content blocks will relate to one another on the site.
  3. Design Brief: We put together an overview of what the client is looking for in regards to design, and gather the company’s style guides, logos, images, color, fonts, etc.
  4. Mood board: Or style tiles. Or element collages. This is a technique we more frequently use with larger projects, particularly when helping a large committee or group of stakeholders find consensus about the squishy issues of design.
  5. Color & fonts: Warm or cold? Modern or serif? The web is super type heavy, so fonts and moods are vital in site design.
  6. Mobile first: We start with the simplest layout (mobile) and use an additive approach to build up to the desktop layout.
  7. Patterns & illustrations: The design may be flat at this point, so this is where gradients, shadows, patterns, icons, etc. come in. For us, this is where Illustrator or Photoshop might come into play to create graphics to add detail to the design.
  8. Demonstrate to client: Showing the design in browser helps to manage expectations, and working directly with the code makes it straightforward to demo different fonts, colors, and layouts on the fly.
  9. Style guides: Web style guides and component libraries are becoming more popular – especially for larger sites and apps developed and maintained by a team. These are basically libraries of markup and CSS that can be used repeatedly. Generally, this is a living document where a team can reference element styles and code.
  10. And THINK: This step often gets overlooked in similar write-ups, we’ve noticed, but for me it’s is pretty important. A lot of the design process is having the site in the back of my mind. For me, good design requires a lot of ruminating.

Conclusion

Designing in the browser is an excellent option if you have the right skill set as a designer, but learning code isn’t for everyone, we know. There are some cool tools for designing in-browser without knowing code, though, so do some exploring. Do what works for you, but always be learning and trying something new. And whatever you do, don’t get too hooked on any one tool or method…designing in the browser today may very easily give way to something more efficient and lovely tomorrow.

Further Reading