As a digital designer, one hot topic which I find revisited again and again is the idea of 'designing in the browser'.
As we strive for ways to improve our processes, work more efficiently and deliver better products, designing in the browser has become a way of getting into the browser sooner and removing our dependency on signed-off PSD deliverables. There are plenty of positives to this approach, and I believe it highlights many of the problems with our reliance on graphics editing software. However, this practice leaves behind traditional methods of visualising design, which is something that many of us are not yet completely comfortable with. Also, we can't detach ourselves completely from the need to deliver the client something tangible and visible that demonstrates our intent.
But when it comes to working in Photoshop, we all know that our designs don't work the same as they do in the browser. Typefaces will not render the same, and we seldom replicate the level of perfection achieved in the PSD due to the greater control we have inside our graphics editor. We invest so much time perfecting every page and state, and this often ends up being wasted. The decisions should have been made in the browser.
Despite this, I believe that graphics editors still play an important role in how we visualise and deliver our websites. There is a way in which we can utilise the best of both approaches, allowing fluid transition between our graphics editor and the browser, where we can then make final decisions. For this approach, we need to start looking at our designs as 'elements' and 'modules'.
I propose that we begin to use our graphics editor to design 'elements' and 'modules' of the site. Elements are the buttons, forms, inputs, links and so on, and modules are groups of element and their means of interaction - along with areas of bespoke design.
We do this by creating a global style guide, a design of a single page, and then specific areas of interest on other pages.
The global style guide will outline all the form, input, link and button styling and common groupings. By designing one page we then demonstrate the overall feel of the site. We don't need to worry about designing every single page as the wireframes will dictate the intentions.
We've already seen front-end development take on a similar approach. Brad Frost argued in his article about 'Atomic Design' that we should look at modularising elements of our design. Similarly, Robin Rendle has discussed the subject. What I find poignant about Robin's article is that he discusses how making our code more object-oriented may create a risk of losing the "one-of-a-kind embellishments" that make a project unique.
I feel that designing straight into the browser can create the same risks. The moment you're in the browser, it becomes difficult to detach yourself from the development mindset. You begin to limit yourself according to the capabilities of the browser and your ability to code the intended visuals. To remedy this, I propose using a particular page to design specific areas of interest identified in the wireframes. We use this page to identify and design the unique embellishments we feel the page requires. Whether this be one-off styling, or a block of content we feel needs 'figuring out' before putting in the browser. Furthermore, if we use BEM principles for the naming conventions of the design, it also means there is clear dialogue across design, UX and development.
I have used this technique for a couple of projects now, and while there is still refinement needed, it has been successful for me. The time we spend in the graphics editor is significantly reduced, but it becomes more valuable. We let the wireframes dictate architectural decisions and spend more time in the browser much sooner. Most importantly, this approach has given the client tangible and clear documentation setting out what will be designed.
