This article will outline the reasons why design work is a crucial part of all cosmetic change control requests (and most others too). In summary:
- Signed-off designs provide a prescriptive scope which sets the expectation for exactly how the final product will appear and, in many cases, function.
- Our design prototypes contain everything a developer needs in order to build the change in code. This includes font, colour, sizing, positions, responsiveness and interactivity. Without these blueprints, development would otherwise contain a disconcerting amount of guesswork.
The difference
Let’s start with the first question: “What is the difference between design and build?”
In their purest forms, design and development are polar opposite skillsets, so much so that SMILE has separate teams for each discipline. The design team is concerned with creating beautiful bespoke and functional user interfaces. Designers are highly creative, ideas-led individuals who often have experience both inside and outside of the digital sector.
The development team, on the other hand, are highly technical individuals who can translate visual (and all sorts of other) information into code. Websites are written in code so that they can display uniformly across the many different browsers and operating systems in use by people around the world. There are also many unseen functions occurring behind the scenes that developers build, including things like search and integrations with external services such as course databases or social media.
It’s very important that our design and development teams communicate with clarity and regularity. However, we don’t expect designers to be able to work with code, any more than we expect our developers to make creative decisions.
The question we have to ask ourselves is: can we adequately describe to a developer, with no ambiguity, exactly the change we want to make?
But we can make creative decisions ourselves!
This is perfectly true. You wouldn’t be reaching out to us if you didn’t see problems with your current site and had ideas on how to improve it. And our designers certainly aren’t going to disregard all of your ideas and run riot with their own.
Let’s imagine we removed Designers from the process entirely. Could we make do? Where would the gaps be? Let’s take a step back for a moment and fast forward to the final concrete form that our changes are going to take: that’s code. And how do we achieve that code: through build.
So the question we have to ask ourselves is: can we adequately describe to a developer, with no ambiguity, exactly the change we want to make? Can we describe it in such a way that the developer will translate it into code correctly, no questions asked, no need for guesswork? Remember that the developer isn’t expected to make creative decisions here.
A simple change
If we take, as an example, a change we might want to make – something rudimental, something that seems uncomplicated. How about making the hero section at the top of our home page bigger and brighter? Nothing fancy. Surely it would be overkill to involve designers in such a simple task?
Decisions made in code are far more difficult to undo than those first prototyped in design.
While there is absolutely nothing wrong with these instructions as a conversation starter, they simply don’t provide the level of detail a developer would expect. “Bigger and brighter” is a brilliant primer to the beginning of a scoping session held with a designer. But remember, in our experiment, we’ve removed designers from the process. If a developer were to receive these instructions, they would likely respond with several anxious questions:
- How big should the section be? In pixels?
- How big should it be when viewed on a desktop computer? How about a mobile? A tablet?
- There’s text in that hero section. Should that also change size? And how does it re-size for different devices or when the user re-sizes their browser window?
- When the client says brighter, what do they mean? Isn’t this to do with image selection? Or is it to do with that opacity overlay we put in place so that the white text on top is legible? Are they aware that changing this opacity would make the text inaccessible?
It quickly becomes obvious what a headache this could potentially be. If it were left to a developer to assume the answers to these questions, we could find ourselves in a costly (time and money) back and forth. Decisions made in code are far more difficult to undo than those first prototyped in design.
Example Hero Section
This text may be inaccessible if the dark overlay here were removed or lightened.
Changing the size of the text here may also have unforeseen consequences on different devices, considering its length.
Dimensions of the current image could also restrict the scope of the enlargement.
A designer would help answer questions and provide solutions for all of the above.
What exactly is involved in the Design phase?
Design allows us to gradually edge closer to the decisions which answer the questions posed above. Whether it’s adding a button, removing a sidebar or making something bigger and brighter, the design phase aims to clarify the request, explore its ramifications and crystallise the final decision in a visual representation that fully satisfies the original brief.
More than pushing pixels around a screen, design is as much to do with exploration as creating nice-looking mock-ups. A typical design phase might follow this course:
- Internal review of original request
- Clarification and exploration calls with the client
- Initial wireframes or mock-ups
- Feedback call with client
- Amendments
- Further feedback with clients, possible stakeholder involvement
- Further amendment, possible clickable prototypes
- Final sign-off on designs which are marked ‘proceed to build’
- Handover to the development team
As the design forms the scope, if anything breaks at any time or fails to appear as agreed, it is the examination of the original designs which provides the supporting evidence required to verify bugs.
Why testing also needs design
The legacy of the original designs lasts long into the future. Signed-off designs actually form the agreement for how the final work should look and function. Therefore, once developers have made the designs a reality, our Operations team will scrutinise the work by cross-referencing it against the designs. If there are any discrepancies between the two, bug reports are written up and the project goes right back to build for fixing.
Even long after a feature is built, tested and released, designs will still form a lynchpin for SMILE’s relationship with our HappyPress clients. As the design forms the scope, if anything breaks at any time or fails to appear as agreed, it is the examination of the original designs which provides the supporting evidence required to verify bugs. Once verified, the onus is on SMILE to fix these bugs for our HappyPress customers for free.
Summary
Design is about far more than throwing wacky ideas at the wall and seeing what sticks. In reality, the outcome is a lot more technical than it is given credit for. The ultimate goal of the design phase is to arrive at a series of instructions that serve a dual purpose. These prototypes depict impressively accurate versions of the final product which give our clients the confidence to sign off on the work. But hidden in the prototypes are also the technical specifications that provide developers with everything they need to accurately realise the final product. Bespoke cosmetic changes on the web simply couldn’t be progressed without the crucial input of design teams.
