UIETips: Some Thoughts on “Designing in the Browser”

Jared Spool

January 28th, 2015

In this week’s UIEtips, we print an article from Stephen Hay. He shows what “designing in the browser” really means and how he implements it.

Here’s an excerpt from the article:

When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders. It’s not the only deliverable, but it’s the one that’s most important to show in the browser. Before that, I sketch. On paper. Other people I know who “design in the browser” actually use Photoshop. For sketching. But when we say “designing in the browser”, we mean the comp is in the browser.

Read the article: Some Thoughts on “Designing in the Browser

Do you design in the browser? Tell us about it below

3 Responses to “UIETips: Some Thoughts on “Designing in the Browser””

  1. Allen Shorter Says:

    I think the best reason to “design in the browser” is that a static comp cannot show animations and transitions which are really a key to making a design go from making 80% sense to 100% sense. An example of this…We recently did a full screen map interface where a modal dialog took over the screen and then afterward a small message popped up. We had a choice of putting that message at the top or bottom of the screen. Because the modal flew in from the top and flew out to the top, we naturally put the small message near the top. If we were using static comps, the better spot would have been obviously the bottom. It is not like this saved us a ton of time in the long run, but when trying to get client acceptance for a design, putting forth something that makes ultimate sense to them is key.

    The second best reason “Design in the Browser” helps us greatly is that we generally have VERY little time to get from accepted design to Developer ready “game surface”. While not everything we prototype is 100% developer ready, it is 500% more developer ready than a photoshop comp.

    Great article!

  2. Rob Says:

    I’ve always user browser based design for mockups, comps and wireframes, ever since I started way back in 1998. To me the medium in which we work is HTML and CSS, plus Javascript where necessary.

    Browser based design is quick, flexible and allows you to define page elements very quickly compared to an image editor.

    One area where it really shines is working with clients in *real time* to explore layout and presentation. If you have a working wireframe/mockup with a few key page types (eg home page, category page, single entry page) together with dummy text and images, you can tweak things in seconds, rather than wait 24 hours for someone to change and dozen PSD’s

    My clients have always loved this approach. I can go to a meeting (or via Skype) and we can discuss and test tweaks live.

    Recently I was at a meeting with a client showing them the latest HTML mockups for their ecommerce site. They were concerned that the display of product thumbnails weren’t right so using a few CSS tweaks I was able to show them several variations of size, square, horizontal, larger, smaller, all within a few minutes.

    That’s just one example. Having HTML/CSS mockups allows you to change virtually anything on the fly, fonts, colours, layout and so on. From the clients point of view their perception can be that development is faster and more cost effective.

    Finally, designing this way enables the designer to specify requirements for any graphical elements that need creating. For instance, if I’ve specified the logo needs to be 200×100 I then forward that information to the graphic designer to make.

    Each to their own.

  3. Philip Barnes Says:

    As a UX architect, I believe designing in the browser is the only true way to represent to the business how an interaction is going to look, feel and respond to the user. Without it there are too many of the “magic happens” here moments, or “just imagine we go from state A to state B, and it’s going to be great once it’s coded”

    If you can code all the better, i find it to be a good way to develop a great relationship with your dev team as it shows them exactly how the UI should respond and integrate with there back-end magic.

Add a Comment