The following conversation takes place between myself and Chris Earls, one of Stone Ward’s Senior Developers. Even though we come from different sides of the tracks, (job-function-wise) the conversation was quite civil.
In the early days of the internet, design was design and development was development. (Yes, I see the irony in calling 15 years ago “the early days.”) As a designer, my goals were essentially no different when designing for print or the web – the presentation of information, telling a story to make the viewer aware of something, affecting them emotionally. To do this, I employed tools such as balance and focal point, color and typography, positive and negative space. The only difference was that the web had buttons to toggle back-and-forth between the layouts. And we crafted and perfected those buttons in all their skeuomorphic glory. The tools used to create websites were similar to the ones we used to create printed pieces, as was our methodology. Designs were created in a vacuum and presented to our team and to our clients well before the developers knew the project existed. Their job was to take the approved layout and “slice” it into pieces. (Our amazing designs were too much for the browsers to load in a single chunk.)
In most cases, this was not a good way to make friends with developers. They were given a design and were told to make it work. Any back-and-forth conversation primarily consisted of snarky comments delivered with similar-but-opposite undertones:
“You just don’t understand technology at all, do you?”
“You just don’t understand design at all, do you?”
If there was anything neither camp understood, it was that we were desperately trying to master this brand new craft without even considering the most important thing: the user experience.
As a developer, I would produce a pixel-perfect reproduction of the designer’s vision in the browser. I used the latest web standards and mastered the myriad of web browsers. Each color was carefully sampled. Distances between objects were precisely measured. The website was beautifully and technologically executed. The designer did their part and I did mine.
The problem with that digital project is that it was designed and developed without any validation of its usefulness. Yes, the site was beautiful and worked, but could users quickly find the most important content? We should have let them validate our work at every step.
Our users have undergone a similar evolution. Now that the web is a useful part of daily life, it really is about content instead of flair. So we’re beginning to understand design’s role as a utilitarian service; helping them find and digest and share the content. Design will always be a vital tool for branding and positioning as well, but a good digital designer rarely starts there.
User testing takes the guesswork out of the process. We’re able to make informed decisions based on the feedback we receive. User tests come in many flavors. We use hallway, remote and A/B testing.
• Hallway testing is simply asking a random person to perform a task on a paper or digital prototype. We watch, learn and take notes.
• Remote testing is done using third party online services. A user is given a scenario and asked to complete the tasks while their screen and voice are recorded.
• A/B testing is done by showing two different versions of the same way to accomplish a task. You see which one performs better and make changes accordingly.
The result of these tests are increased conversions and interest in what our clients care about most.
The good news is that the design and development community are becoming more collaborative, and this will lead to digital communications and applications becoming ever more useful to those who use it. It also means our methods of working – and the ways we measure our progress – are changing. To use a metaphor, the designer now has to not only be the architect and draw up the plans, but also make important decisions about the light fixtures and the faucets. These are the REAL places where the user experience is determined. And the developer – usually concerned mostly with structural and engineering matters – will need to understand some of the more intuitive and emotional parts of the experience.
It also means the project is rarely “done.” It’s a stream, a flow that goes from design to testing to development to testing and back to design. It’s an iterative process, and – when the designer and developer are in sync – a rewarding one.