Rarely are design problems just about design–and it’s a challenge getting clients to understand that. At the 2007 User Experience Week after party, Doug LeMoine and I had a long discussion about how clients don’t see the functional/engineering/technical components involved in making something “attractive.” While my company is solving design problems on a much smaller scale than his (Doug’s the Director of Design Communication at Cooper), it’s clear to me that this is a systemic misunderstanding throughout the business community.
For just over a year I’ve been lucky enough to have an incredible graphic designer working with me, and that’s led our company to be solicited as much for design as for development and training. Quite frequently we’re asked to “give a facelift” to some Excel report, PowerPoint template, or Word proposal. But while aesthetics may be what they’d like at the end of the day, there are a number of steps to getting there. Giving the client what they want in a design requires helping them to understand what they really need.
Let’s take an Excel project we’ve recently completed. The client sought to illustrate to their prospects the advantages and disadvantages of various employee benefits packages. Their existing report creation process was as follows:
- Take data from a number of places and paste it into various cells and formulas throughout an existing Excel workbook
- Edit a few formulas to address some of the variations in this new set of data
- Edit the source range of the Excel charts and graphs to the newly pasted data so as to fit it within an appropriate range
- Reposition the graphs as Excel often moved them around in the process of updating
- Print or email the reports to clients
The existing process required deep knowledge of what the input data meant, of how Excel formulas worked, of how the final design should look, and of how a mistake in the reports might appear (manual processes like these rarely work on the first try). In short, it required a lot of expertise and a few hours worth of time.
Could we improve the attractiveness of their reports? Sure. Would that design hold up as their data shifted? Not so fast… If we stuck with their existing process, we’d essentially be relying not only on the analytic and industry-specific skills they already needed, but on a deeper understanding of design. The last thing I want is to make my clients lives more difficult–because that would ensure that our efforts were unlikely to be used (or used well).
So we did what we had to do: we spent many hours understanding the possible permutations of input data and output reports. We then created a userform that took all the input data, and developed a series of reports on separate worksheets. When all was said and done, the clients process became:
- Take data from a number of places and paste it into cells that are clearly labeled
- Print or email the reports to clients
No longer was Excel knowledge or industry-expertise required. And, of course, the reports were attractive and have already begun winning them more business (after all, they can now use them with all their prospects instead of just the bigger deals).
But this isn’t meant to be a case study of my business. It’s to illustrate that many of the smallest design challenges (a small Excel spreadsheet project) are not just about printing something once but about the life of the design–a life where elements change and the people who touch it aren’t necessarily brilliant designers or industry experts.
If someone thinks the half-dozen hours it may take to choose colors, fonts, and layout are all a design process involves, then they’re sorely mistaken. As soon as someone is going to touch a design, it now becomes a question of how to architect the design.
Once upon a time a designer’s role was to paint the door. Now we’re asked to prevent the door from being too heavy and not to bang into the wall. Even the smallest projects require time and thought that are not just about the basic colors, fonts, and layout. In the coming years I hope that more businesspeople will begin to understand, respect, and value that.
You should really subscribe to Technotheory via email or rss.
Oftentimes, the role of the designer is similar to that of a doctor. When a patient visits the doctor with stomach pain, the patient is not expected to know what the root of the problem is, i.e. “I think it’s because my gall bladder needs to be removed.”. That’s for the doctor to figure out.
Design projects usually begin at the clients’ hypotheses for their problems, their own interpretations of symptoms that they’ve identified. As we do research, we test these hypotheses and attempt to determine whether they’re sound and complete. If they aren’t, we have to break the news to them: The problem isn’t actually what you think it is, i.e. “It’s not your gall bladder; it’s the junk food you’ve been eating.”
The best results in delivering this (sometimes bad, sometimes hard-to-swallow) news are achieved by notifying clients up front when you notice a hypothesis in place of a symptom. “You’re telling me that you think the registration process is too complicated; where is this coming from? Describe what you’ve seen that makes you think this.” By representing to them that your ultimate goal is to determine the root of the problem, you’re positioning them to absorb and act on your analysis.
Of course, some clients just want you to remove their gall bladders anyway, and you always need to be prepared to do what’s right in those cases.