Skip to main content

https://gds.blog.gov.uk/2012/03/29/breaking-down-walls-designing-in-browser/

Throw away Photoshop and be true to your medium

Posted by: , Posted on: - Categories: Content design, Service design

At GDS, we have been building teams focused around product rather than teams focused solely on expertise and I am pretty typical of this ethos. My background is graphic design, so working on the web meant I needed to learn how to build websites as well as designing what they look like. It forced me to think about users’ interactions with, and their journeys through the sites I designed and built.

I found the best approach to allow me to do this was to design ‘in-browser’, i.e. express design in code from the off. Working with my colleagues, we have introduced this technique to the design process of GOV.UK in reaction to the rapid development cycles and number of iterations on the product. Working at this pace is a compelling reason to have a design process that generates as little friction in the overall delivery process as possible.

If you’re designing a truly user-centric product, nothing is ever ‘finished’. At GDS we’re geared up to constantly iterate so we can continue to meet user needs and react to them speedily. The idea is to release the minimum viable product and to test the assumptions we made during the build as quickly as possible. What worked stays, what doesn’t work gets ripped up and started again. Designing in-browser allows us to iterate quickly and easily.

The process we follow for GOV.UK begins with analysis of a need, then sketching a possible solution, whether in pencil and paper or a very rough screen mock-up in something like Illustrator or Photoshop. Once we’re convinced by the sketches we move straight onto prototyping, which often becomes the embryonic form of a new application or feature.

This mirrors the process of designing a new mobile phone. It is likely you will start with pencil and paper, creating the first draft in 2D which can easily be revised and amended. Once a final version emerges you can then quickly move on to card maquettes or even a 3D printed models. But you’ll probably work with metal and plastic as soon as possible to explore the the full capabilities of the materials required for the product, in terms of durability, finish, look and feel. Being able to hold something tangible in your hand means you can test whether your ideas create the feelings and user experience you’re aiming for.

It’s even simpler to test assumptions we’ve made with prototypes on the web. The advantage of building websites is that there isn’t the same material cost or overhead involved with working with physical products. Prototypes can be shared around and played with by other members of the team and on different devices in different environments. We can try out a multitude of ideas, some of which will develop into the product, some of which will be discarded. For example, on Smart Answers, we we created many potential paper prototypes before getting to the final one which then went into user testing.  Time is our only significant cost.

Traditionally, digital teams often have a separate design function and use software like Photoshop, Illustrator or InDesign to create visuals. These images are ‘thrown over the wall’ to a development team which writes code, in HTML, CSS, etc, to reproduce these designs. This is how I worked for years myself. But this lack of overlap between disciplines can lead to problems. Sometimes, if a developer doesn’t understand the thinking behind a design, when they run into constraints imposed by technology, they may not be fully able to resolve them in a way that is true to that design. This can lead to lower quality products or, even worse, painful or just plain ‘broken’ user experiences.

To help solve this we regard design, prototype and build as all part of the same process. It can become seamless by using the tools (HTML, CSS, Javascript, Ruby on Rails) and medium (the web, via the browser) that we use for the end product. This keeps us honest by fully exploring the possibilities and constraints of the constituent parts of the product that we’re building.

In-browser design also makes it easier to deal with the different ways browsers render web pages. It is impossible to replicate pixel perfect versions of the design across different browsers and devices. But more importantly, it is next to impossible to test user interactions with a web design in a static visual design.

Furthermore, designing in-browser exposes mistaken assumptions at the earliest possible stage in a build. This means we fail quickly rather than expending effort on high fidelity mock-ups that were based on mistaken assumptions. It can also generate further economies through re-usable components; design, code etc that stays up-to-date. Using a more traditional approach would mean extra time spent working in Photoshop or other design software simply to keep visuals up-to-date.

In-browser design may not be the right answer for everyone, but I think it’s worth challenging yourself to give it a go as there are so many potential benefits. For GDS it is the most logical process for us to follow, one that means we can deliver and iterate quality products in keeping with our design principles and agile working practices.

James Weiner (@jamesweiner) works on the front end for GOV.UK

Sharing and comments

Share this page

17 comments

  1. Comment by Ross Chapman posted on

    I can't shrug off the argument that we should be designing in the environment we're in - which I do agree with. Having done it a few times in the past, prototyping in HTML and CSS has obvious benefits and also serves as a usable deliverable to the development team to reference.

    I used to create designs in Photoshop, but the transition to Photoshop to coded site is marred with problems (things will look different on different browsers, different viewpoints and different technology).

    I'm currently creating a prototype in Powerpoint - it's low-fidelity, shows one user journey and the interactions required, so we can make key decisions early on. I've used Photoshop to put together a treatment for the design aesthetic. We have Axure as a more high-fidelity prototype (HTML + CSS could be used here, but lacks a quick build).

    These are all tools that do specific jobs and in my experience - there is no "one-way" to make a website.

  2. Comment by Pete posted on

    I've found that the designers who produce truly outstanding designs, intricate and exquisite designs with real deftness of touch and finesse know that their domain is design, not code. Anyone inhabiting the world of design operates on an intensely visual level where the choice of tool is key. It's difficult to see how the same can be achieved by jumping straight into a code editor. In a building engineering project, one wouldn't go to straight into construction without the architect's visual treatment. Italian car makers wouldn't dream of designing the bodywork in a moving conveyer belt on the production line. The relentless drive to operate more quickly and efficiently often overlooks an important truth: 20% of effort provides 80 of the value. More often than not, design is the sacred cow that makes up this 20%. For high-end work, I wouldn't put design in the hands of anyone who doesn't live, sleep, breathe design. For a low-cost, no-frills artefact, designing on the fly may be passable.

  3. Comment by Workflows In A Responsive World: From Waterfall To Agile - Vanseo Design posted on

    [...] yourself out designing as you always have, but as soon as possible push your design to a browser and having what’s in the browser be the [...]

  4. Comment by filip posted on

    Developers who find it difficult to translate great design to great code may just be poorly skilled or perhaps want an easy way out. Roughing in structure in code first is a great idea, but when brand differentiation is important, more time must be given to design exploration.

  5. Comment by Richard Dale (@Rickydale55) posted on

    I know Andy Clarke has advocated this way of working for quite a few years now. I can totally see the benefits and why it could be quicker but I just personally find it difficult to do in practise.

    I still use pen and paper initially then, sometimes Balsamiq Mockups but always end up in Photoshop. I don't design every pixel of every page but I do design the main elements this way. I just find it easier to make decisions on colour and typography this way.

    I perhaps need to force myself to try this way of working again and see how I and my clients get on with it.

    By the way when you start to code from sketches or ruff wireframes to what level do you code to? Just basic look and feel?

  6. Comment by Jackie Murdock posted on

    Sometimes you gotta break out of the tool and edit raw code, couldn't agree more

  7. Comment by Mike Atherton posted on

    As someone hiring designers, my only frustration is that more of them aren't working in this way. Working natively in web fabric means your designs take on the richness and subtlety that can't be captured in a static screenshot - especially in this age of rich transitions, modal popovers, asynchronous actions etc.

    Web design isn't DTP, it's interactive product design. Designers should always use the right tools for the job.

  8. Comment by Introducing the design principles alpha for GDS | Government Digital Service posted on

    [...] also essential we don’t design alone. As James has mentioned we can no longer work in a way where designs are ‘thrown over the wall’ [...]

  9. Comment by Russell posted on

    I'm a graphic designer who has been mainly working in local government web development and design for 10+years, strong photoshop and illustrator skills combined with css/html and a mixture of web technologies ASP, PHP, SQL etc. etc. etc.

    I'm the ONLY designer in a team of approximately 8 developers!

    It's very frustrating..... as everyone else REALLY undervalues design

  10. Comment by transportgovuk posted on

    Along the same line of thinking Ryan Singer does a great job of explaining his approach to designing an app and the merits of creating markup early.

    http://vimeo.com/16814487

    It works for him and it appears to be working well at GDS.

  11. Comment by Jud Jones posted on

    So now we know why the UI is so poor! Experience shows that poor developers always move to code rather than proper design. Your web site has exactly that feel to it - thrown together and a bit of a hack. Of course it's all right you've got the big Beta disclaimer all over it.

  12. Comment by maxw3st posted on

    I don't use a pencil and paper. I use Illustrator as my scratch pad. For me it's just a quicker way to "sketch". I have found however; that it has the added advantage of leaving me with screen designs that can be rapidly translated into HTML/CSS without wasting time on manual to digital conversion processes. It also has the advantage of letting me check out my typography selections at a very early stage so multiple options can be quickly reviewed and eliminated.

  13. Comment by Graham posted on

    Thanks James for a good article. I'm not ready to throw away Photoshop and probably never will, it's simply become a sub tool to support working in the browser.

    And we've not got to forget that when we're designing in the browser, we don't forget about 'Design', it's easy to think only of whats happening technically.

    I wonder if the latest design of the Starbucks site was designed this way, making for a very bland experience.

  14. Comment by Be True to the Web | Bob Martens posted on

    [...] James Weiner writes: Furthermore, designing in-browser exposes mistaken assumptions at the earliest possible stage in a build. This means we fail quickly rather than expending effort on high fidelity mock-ups that were based on mistaken assumptions. [...]

  15. Comment by Alex Hansford (@alexhansford) posted on

    In-browser design should work well for products or websites that are undergoing continuous development.
    There's still a place for conceptual-design in order to help give features some 'polish'. Perhaps that could be added once the information and functional needs have been met?
    In short sprints, it can be easy to ignore this after the product us 'done' - but it really depends on whether you consider the design part of the 'done' criteria.

  16. Comment by William Avery posted on

    I'm interested that you don't use the term 'wireframe' once.

  17. Comment by outrunthewolf (@outrunthewolf) posted on

    A couple of questions:

    I work with some great designers, but their HTML, CSS skills are no way up to par. How do you account for that in your design stages? Or does every designer have good markup experience?

    Do you design in your browser (through firebug, or developer tools)? Or just design on the fly, working your designs straight into a working page without a PSD?