UX design – designing in browser

The current trend to ask designers to work directly in the browser (or to build their design in code) is in theory a brilliant idea from a UX design point of view and gives several advantages;

  • It allows the client to see a working HTML prototype rather than Photoshop layouts, removing any chance of disparity between the designs and the final code delivered
  • The whole process is sped up by not producing any ‘final’ PSD’s
  • It keeps the design and build process agile and user focussed

But in practice, here at Delineo we’ve found it more practical and efficient to take a slightly different approach.

We already have specialist digital designers, and dedicated front-end developers, so to make best use of their speciality and expertise in their respective fields, we deploy a 2 person team to work in tandem on UX projects.

Like the established creative teams of art director/copywriter, a ‘digital creative team’ approach of digital designer/frontend developer gives a combination of perspectives, with both disciplines contributing to the whole UX process.

Whilst the process itself varies from project to project, dependant on time scale, budget, client needs and the brief itself, our digital creative team is central from the first step until the last. Being involved in the early stages of the UX process keeps them invested in the project and focussed on the users’ needs, and as the project develops, their deep understanding of the issues and the user pays dividends.

Having both designer and developer working closely (ideally sat next to each other) is essential to the success of this approach. The designer can work up wireframes and style guides to give a visual direction to the project, whilst the developer is setting up the framework and building out the responsive HTML, simultaneously building the prototype and feeding into each other’s work. Questions can be batted back and forth, the designer influencing the code, and the developer helping refine the design.

In keeping with an agile workflow, there’s less resistance to change as there’s no need to push designs back to the studio to be reworked. Every element of the design and build remains malleable and interchangeable. Changes to the design or functionality can be built straight into the prototype keeping backtracking to a minimum.

This method of working requires the client to play an equally important role. As well as their on-going input in stakeholder meetings, the lack of polished final PSD’s takes a leap of faith, but once the HTML prototype is taking shape, that faith is quickly repaid. Having a working prototype that can be interacted with, renders in browser and can show the responsive design in action across devices is a more reassuring and accurate feedback to present, and we find results in happier clients.

All in all, as well as being a more efficient and dynamic way of working, “designing in browser” is a much more collaborative and inclusive approach, that doesn’t divide or segment designers, developers and clients.

Rather, it unities all parties to work together to one common goal, encouraging healthy debate and questioning, but never proportioning blame and culminating in an end result that feels like the shared success of all those involved.