Generally, the renewal of web services begins by ordering a concept and a visual design from a creative agency. The agency is briefed on the goals of the new web service or website. After a few workshops, and after the concept has been clarified, the web service is illustrated by pixel perfect graphics. The client views and accepts the graphics, after which they are handed over to the development project team implementing the web service.
When the client and graphic designer see the first version of the implemented web service, they might wonder “What on earth happened to the design?”
What happened?
Why does the graphic designer’s awesome creation turn into a web service that just looks off?
Web browsers are a significantly more hostile environment than Photoshop, Sketch, or InDesign. While an image looks always the same in different programs, browsers have limitations and even bugs, and they often present the same element in different ways. A one-line header in English looks fine on the screen of a desktop, but is divided into three lines on a tablet in Finnish. The font, which looked good as 12 pixels tall in the illustration tool, looks quite different in the browser. In addition, certain layouts and shapes are harder to reproduce with the browser. Recognizing these problems is not necessarily obvious, unless you have done web development.
Web pages are much more than static content. Many items, which are important from a user experience point of view, cannot be communicated through static graphics. Let’s take e-commerce filters as an example. Does the filter list open when you move the cursor onto the filter, or when you click the filter? Does the list open as an animation, or is it immediately visible? Is the user shown an animated icon while the product list is updated? These are all matters that cannot be specified with static graphics. It’s not unusual for the site to have five different layouts and style sets, depending on browser screen size. Should the graphic designer then produce five different versions of each page? Of course they could produce just one version in high resolution graphics and the rest as wire frames, but that would leave the visualization of the other versions up to the imagination of the client.
How can this wasteful process be improved?
Design by prototyping
The only way to achieve a user interface definition that is both accurate and definitely implementable is to do it in its natural environment, as code in the browser. Very often, the platform for the service has not been selected at this phase of the project. That is why the specs are done as a static page, i.e. a prototype.
A prototype is a user interface that is used with a browser and is comparable in functionality to the intended web service. It illustrates how the service will look and feel in various devices, without being connected to backend systems. With a prototype, you can address every detail, from the visual look and feel to animation speeds and screen reader behaviour. Thanks to this, the client can already see at an early phase of the project what the end result will be.
Like the prototype, the final pages are mostly just HTML, CSS, and JavaScript code. This enables the re-use of the prototype code in the actual implementation. Creating the prototype is not, therefore, wasted work. The re-use of the prototype code is not only possible, but should also be mandatory. Code re-use should also be part of the contract, meaning the vendor should not have to re-code what has already been coded, and the client should not have to pay twice for the same work.
Because of intended code re-use, the same browser requirements must be set for the prototype, and the final production user interface. Typically, though, in early explorative stages, the prototype only works in the desired manner in one browser. As the definition work progresses, the maturity of the prototype grows, until–one feature at a time–production-level quality is achieved, at which point that particular feature or component is ready for implementation.
If the prototyping is done in an agile way, in sync with the development project, e.g. a sprint before the actual application development work, the prototype can work as the user interface requirements for that particular sprint. This way, visual design does not require a separate project phase, lasting several months. Also, user feedback and iterating the design is faster, since the visual design is adjusted in sync with the development work.
Is a graphic designer needed at all then?
Prototyping by no means makes graphic designers redundant. Quite the contrary. Web developers with visual design skills are about as rare breed as graphic designers who write code. In the perfect proto-team, there are both graphic designers and web developers, working together.
The web developer ensures that the designs the graphic designer produces are implementable, before any high resolution designs are produced. The graphic designer, for their part, ensures that the end result is visually correct. Problems typically arise if there is little or no collaboration between a graphic designer and a web developer, or if the development project is missing one of these roles.
When is a prototype not needed?
The creation of a coded prototype is unnecessary, if you know: a) which software product the service will be implemented with and b) if the product in question already has an established user interface. CRM systems, among others, fall into this category. Even in such cases, the creation of wire frames or model images helps us understand how the service will look, when completed.
Continuing the development of a prototype is not always necessary as the project matures. It is, after all, one more item to maintain. Typically, the prototype can be discontinued when the system will no longer have new major features added which require iteration, and is starting to be more in the maintenance phase.