Our Process Should Be As Responsive As Our Designs

The more I design, the more I find myself questioning the traditional design process, especially when in comes to designing for web. As the landscape of the internet has changed, the process of designing for web has become incompatible with the way websites are built.

Designing for web has long been about designers considering and organizing components, then conveying their solutions to the developer. Developing, however, has been about understanding that design solution and translating it into something that browsers can understand. I'm not sure that we have ever nailed down the perfect method of communication, but that's not really the nature of the web anyway. The web is about things constantly evolving and improving, so why should we view our web design process any differently?

Lately I've been thinking (and reading a lot of other thoughts like Typecast's recent newsletter on team working tips) about how to get from the design comp phase to the build phase in a more effective way. 

Design Comps

Design comps are taken too seriously. Too often they are used as the one and only master document for determining what the final product will look like. Clients like them because they can see exactly what they are going to get (so they think). Designers like them because they can design something and then hand it over to someone else. But the behaviour of websites has changed and the behaviour of the design comp has not followed suit. It no longer works as an effective communication tool between designer and developer. Design comps can't efficiently describe what a responsive site will look like at different sizes, and it takes too long for developers to sift through them and extract the information they need to build the site. 

Design comps need to be slapped off of their pixel-perfect pedestal and be considered as more of a guide or a sketch than final artwork. They need to be divided into their separate components and explained clearly in a way that developers and designers can both understand. I separate a design comp into Dimensions, Typography & Styles, and Content & Assets.

design-comp-700.png

Dimensions 

Finding an effective method for communicating dimensions is admittedly the area where I haven't found an ideal solution yet. There are a few things that can help though. For example, the dimensions of the site can be greatly simplified by using a cohesive system of measurements (which also creates a greater sense of unity in the design). Having a grid system or working with a modular scale can speed up the time it takes for a developer to interpret and implement the design because there is a limited set of numbers they are working with.

Another solution for communicating dimensions could involve figuring them out together in a workflow that includes a prototype at an earlier stage. If the prototype is built well, it can serve as a base for the dimensions keeping everyone on the same page. 

Typography & Styles

Typography should not ever be designed exclusively in a design comp – the difference between type rendering in a design program and in a web browser can be astoundingly different. Typecast is my favourite tool for overcoming this as it allows the designer to set up a style sheet right in the browser (and also give access to huge libraries of fonts that can be licensed for web). The styles can then be exported as CSS, giving the developer a very accurate idea of what the designer intended, at least as a good starting point.

A designer that knows a bit about coding can be a huge advantage to the team because they can pass their ideas on quicker and free up the developer's time for the hard stuff. For example, the designer may intend that all buttons are 44px high with a 2px border-radius and all of the colours are of a specific palette. If the designer can jot these attributes down in CSS to give to the developer, the developer spends less time measuring things in the comp and more time putting the site together.

Content & Assets

Content and other assets are often the last pieces to go into the site. The content is unfortunately usually out of the designers control (which is a topic for a whole other post) but designers can certainly help prepare assets. Developers have traditionally held the responsibility of pulling assets out of the comp files, but a good web designer should know how to export files for web like a pro. Having a team that can ask each other for help with assets is a huge advantage.  Exporting graphics as svgs, compiling icons into icon fonts with services like Fontastic, and exporting photos in the proper sizes are all things that designers can do to help development go smoother.

It's About Trust And Communication

As long as the web is changing the way it behaves, we need to change the way we design. That means that our process needs to evolve in a way that gives us better tools for problem-solving and communication between teams. Maybe someday, someone will make a well-designed program that is made specifically for web design that doesn't restrict the designer or the developer, but until then, we will have to make due with combining the programs we have, in the most effective way possible. And designers need to learn more about the medium for which we are designing, and be able to communicate with our development teams in a way that everyone understands – because that's what designers are good at. The design comp is king no more, let's treat our process as responsively as we do our designs!