Unless you’re designing things for fun, someone’s paying the bill.
When I’m working with early career designers, I spend a lot of time explaining to them in various ways that the work they are doing is not for them, but for the customer. That customer can be internal—a project manager, account manager, or their creative director—or external, in the form of a direct client or an end user of a software application.
There are a lot of ways to approach this subject of pleasing the party who is paying the bills, but today I want to write about user interface design. In this case, the user in question is the end user of the software product (or web application).
I did my first online UI design work when social networks on the Internet were character-based, and called USENET. At that time, working on the Windows platform, there were specific UI standards for the work we were doing (help pages and tutorials for Microsoft’s Exchange/Outlook products). This meant that a large number of interface questions had already been answered by developers and users of previous versions of the products and by rigorous user testing of new features and interfaces. As a designer, once I internalized those rules—a task similar to learning to work with a set of corporate branding guidelines—the task became easier, and I was able to guide users from one area to another using the standardized language of that interface.
Designing for the web, every designer became an interface designer, with varying results. The web’s been around long enough now for us to identify different eras of interface theory and trend. Sometimes these trends have been driven by tools, sometimes by technology, and sometimes the reverse. A great example is the late nineties’ conceit of having a curled-down corner in the upper right hand of a page, generally (but not always!) indicating that there was more content available. The first few times this turned up, it was a neat trick. Then it got kind of boring. Then there was a Photoshop plug-in that automatically generated the curl and the shading for you. At that point, or well before, most professional designers abandoned that particular graphic quirk.
So the web rolled on, with technology driving design, and design driving technology. As web technology has become more sophisticated, we’ve been able to do more and more interesting things on web platforms.
As new applications rolled out, the tasks of devising interfaces became more egalitarian. Instead of a bunch of specialists in information architecture working with a team of user specialists in a test lab in Redmond, designers were winging it (regardless of their training or experience in UI). Designers (part of the wave of folks coming out of art schools trained in software operation, rather than traditional design) were tasked with creating front ends for complex back end functionality. Often, in the name of expediency, software developers were spent a few extra hours designing interfaces for their work. As egalitarian and exciting as this may sound, it meant that there were a lot of interfaces being released that were based on convenience, a partial view of an application or task, or inexperience. Worse, the nature of iterative, agile development meant that mistakes or poor choices early on often became so ingrained in a product that it may never be changed.
Generally, the more important the task is, the better the interface and user flow tends to be. Banks and financial institutions tend to do pretty well with user interface—an understandable thing, since they and their users need to be accurate all of the time. Sites that involve uploading or sharing files tend to be hit and miss. This is likely a function of budget, which brings me back around to my opening statement.
As an interface designer, whatever you’re building needs to serve your customer. Whether you’re an experienced designer working on a front end for hot technology, or an experienced developer who needs to figure out what the user of your new software will be looking at, it behooves you to think about who your customers are, internally and externally. Test it as you go—show it to the various users, customers, and stakeholders in the project, and make changes as needed to develop it as a real, usable application.
Begin by thinking about what the various participants are trying to accomplish when they’re using your application. Talk to the development team. Talk to the marketers. Talk to the people who conceived a need for the software, and find out what their vision is for its functionality. Find out who will be using the tool, and why, and talk to them, or study what they do and how they do it. Find out what environment they’ll be in when they use your software. If you can, find out about other tools that perform similar tasks, and find out what works well, what works poorly for them. If you’re working on a site that generates income, find out what user behaviors maximize income, and then figure out how to replicate those behaviors throughout the site.
With any luck, the preceding work will have happened before the product was developed, and is enshrined in a spec or at least a roadmap of some sort. More and more, though, designers and developers are tasked with making improvements and changes to product on the fly, without interrupting use of the project (an excellent example of this is the slow rollout of the recent Twitter facelift and feature upgrade). This requires a new approach to the software and interface t, likened by those doing this work to performing mechanical work on a moving automobile.
It’s a cliché that good design doesn’t happen in a vacuum, and that may be truer of interface design. Good software needs a good front end to function well—and good design isn’t doing its whole job if it doesn’t allow the user to make the best use of the software.