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