Design is important, no doubt about that. Design structures, creates character and improves usability. But no design – even the best – replaces functional specifications. And neither should it conflict with them. It goes without saying that you would like to see “something tangible” quickly. But hold on, this is not a good idea.
A common example in development projects: the functional specifications define the following: “Implementation of the separately contracted design work in templates. The design will be delivered latest by the end of phase 1.” In a later part of the specifications that deals with the concrete functional requirement for “contact person” we read: “Contacts (individually editable data sets) are listed on one page, sorted in alphabetical order. The following information is collected: Academic title, first name, last name, department, e-mail, phone number.” The contractor calculated the time that it would typically take to implement the above mentioned. The contract is signed. The deadline for phase 1 approaches, and passes. - It comes as no surprise that there is more need for discussion about the design than expected and that the designer needs to make several extra revisions (hopefully paid ones). The CMS experts/developers have to meet their own deadline and are already starting to configure the data sets.
We finish building the contact page - which is now ready to be styled – when, with several weeks delay, the screen design is submitted. The excuse: ”Unfortunately, it took longer because we weren’t entirely happy with the A-to-Z bar and the arrangement of the portrait images.” – Wait a second … A-to-Z bar? Are we talking about jump marks or filter functionality? And the technical specifications didn’t say anything about images either. Furthermore the layout file shows a (non-functional?) search field. What happened? Either the design agency didn’t receive or didn’t read the functional specifications. But true, the page looks better with images. We are reaching out to the client and explain that new elements and functionalities will cause additional charges. The reply: “There is no budget for additional costs.”
Oh well, no problem. We are just going to refocus on the design elements that correspond to the technical specifications in our contract and ignore the rest. The client disagrees: “The page has to be implemented as shown in the design file, the management already approved it.” The result: we are trying to avoid feature creep as well as maintaining a positive atmosphere. Both of which can be very time consuming.
By the way, our example is flawed: An experienced CMS agency knows this kind of pain and would have calculated a budget that includes these risks or made it clear that the implementation of the (unknown) design is not part of the contract but would need to be contracted additionally once the design actually exists.
Principles, not pixel
All of this shouldn’t be a problem if we assume that the design and CMS implementation are done by the same contractor, shouldn’t it? – Agreed. It makes things easier. But even then should the functional specifications remain binding. It is not the role of a designer to discuss functionalities with the client. The designer creates designs for certain elements but the question whether these elements are needed or which interaction they cause is part of the technical concept. Designers may come up with suggestions on how to visualize e. g. the look of the A-to-Z bar if such a bar is requested. They show how elements in a teaser are positioned to each other. But they cannot make the decision about whether teaser images are used or not. By the way, the design should offer options for teasers without images and show how the design behaves with texts of different lengths.
Comments