Why designing in the browser is the way forward

We love designing in the browser and believe it’s a far more efficient way to build websites and applications for our clients. Here’s why…

In the last 3 years, while working on large-scale applications, I spent a lot of my time producing wireframes and final designs in Photoshop/Sketch, before working through several rounds of reviews and user tests.

As a newer member of the Hanno team, and someone new to the process of designing in the browser, I was a bit sceptical about this approach.

But in the past 6 months that I’ve been working with Hanno, the method has undoubtedly proven itself as the fastest and most logical way to build great apps and websites.

Since this is still a relatively new approach in the industry, I want to give a better insight into the workflow, and why we’re using it.

The way of the past

Before tools came along to help us design via rapid prototyping, designing in Photoshop, Illustrator or Fireworks was easily the most efficient option. But nowadays, with frameworks like Bootstrap, educational websites for HTML/CSS on every corner, and excellent development tools like Sublime Text, and its powerful packages, it is very easy to get into prototyping and switch to designing in the browser.

By now, building a design in Photoshop feels like an anachronism, screaming for a resolution.

Let’s consider some of the weaknesses of the traditional way of designing websites, each of which can significantly limit the success of your final product:

  • In a project’s life cycle, talking about aesthetics should be one of the final items on the agenda. It’s simply not that important at the beginning (or even the middle) of the UX design process.
  • Ultimately, Photoshop mockups are just static, unclickable images, which leave all the interactions and effects to the viewer’s imagination.
  • Creating a design from the ground up requires a significant amount of time. You have to define colours, typography, form elements, different assets, etc. And if you’re designing a single page of a mockup, it’s almost impossible for you to consider the wider context that these elements will be used in — you’re just moving pixels around the canvas, rather than considering the UX of the product as a whole.
  • The final mockup simply won’t look the same in a browser, since different browsers render things very differently to each other, and to Photoshop (particularly when it comes to fonts, borders and colours).
  • Even when you’re satisfied with the design, you’ll then need to recreate the entire thing again, this time with HTML+CSS. Even pulling out colours, fonts, borders, widths for the development stage, is a painful process.
  • While we’re heading to a multi-device, multi-width world (OK, we’re actually there, right now), the design mockup you’ve produced is still just a fixed width layout. Designing for different devices is a painfully slow process.
  • Producing ‘final-looking’ visual assets and final mockups early on the design process can require significant time and budget spend, and equally importantly, can often remove the creative drive and freedom to iterate and improve the design further as we discover new information later on in the process.

Why designing in the browser is the best way to fix this

The main benefit of switching to designing in the browser is that we can deliver better results much faster, and speed up the development process significantly:

  • Rapid prototyping with Foundation or Bootstrap allows us to set up website skeletons in hours, rather than days.
  • We can see the content in context and decide if it’s the right place at the right time. Content strategy decisions take place at the same time (or earlier) as design decisions — this is the way it should be, but rarely is, when we work with static mockups.
  • Since we’re building an interactive prototype, the client can actually click and browse through pages, experience interactions, and give feedback based on real user experience, not a hypothetical end-result.
  • Since you are building your application to a fluid grid (and ideally, working mobile-first), you can instantly check and design for different devices: mobile and tablet views.
  • It’s extremely fast to explore different colour, layout and typography variations across a whole product. By writing HTML and CSS (Sass, frequently) with frequent code reviews, the prototype’s code can go directly into production — no duplicate effort is required!

When we do this at Hanno, our goal with this process is to maximise the UX output we can deliver, and ask serious questions about the content strategy along the way.

We work with a framework like Bootstrap or Foundation, and even avoid adding additional brand and custom styling while we initially prototype. This lets us focus on the important stuff and iterate fast. We can discover, analyse, and discard ineffective or flawed directions much quicker.

It’s safe to say that as a client, while this is definitely a shift away from the old, waterfall approach. But to go even further…

If you still request final mockups as early-stage deliverables in the design process, you’re leaving yourself at a serious disadvantage, inflating a project budget and killing momentum at the same time.

There’s of course, plenty more to discuss, and I’ll be explaining more about how we integrated this way of working into our design process at Hanno, in my next post.

This post was originally written for Hanno Logbook.

Thinking about jumping into design in the browser?

Great! Here are a couple of other posts to help you get started: