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

Throw away Photoshop and be true to your medium

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

17 comments

  1. outrunthewolf (@outrunthewolf)

    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?

    Reply
  2. William Avery

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

    Reply
  3. Alex Hansford (@alexhansford)

    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.

    Reply
  4. Be True to the Web | Bob Martens

    [...] 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. [...]

    Reply
  5. Graham

    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.

    Reply
  6. maxw3st

    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.

    Reply
  7. Jud Jones

    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.

    Reply
  8. transportgovuk

    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.

    Reply
  9. Russell

    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

    Reply
  10. Introducing the design principles alpha for GDS | Government Digital Service

    [...] 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’ [...]

    Reply
  11. Mike Atherton

    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.

    Reply
  12. Jackie Murdock

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

    Reply
  13. Richard Dale (@Rickydale55)

    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?

    Reply
  14. filip

    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.

    Reply
  15. Workflows In A Responsive World: From Waterfall To Agile - Vanseo Design

    [...] 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 [...]

    Reply
  16. Pete

    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.

    Reply
  17. Ross Chapman

    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.

    Reply

Leave a comment