Reducing the Variables

It's eleven in the evening, and the energy rush provided by the soda and pizza has begun to wane. The whiteboard is full of sketches detailing dozens of solutions to a particularly thorny piece of website functionality… but none of them seem to fit the client's need perfectly. The whole team is exhausted, but there are still at least twenty yards to sprint until the ideas in our minds make sense in some sort of material form.

When you're trying to solve really big UX problems—ones that hundreds of other designers have probably expended thousands of hours considering—you'll spend a good deal of time retreading similar ground to those of your peers. It's tempting to choose what seems like the most appropriate large-scale solution based on what you've seen out in the market, then fill in the details as you go. In some projects, that's the right approach to take.

But in these kinds of situations, it's very important to ask yourself: Am I trying to uncover some capital-S "Solution" to a big problem when actually I should be taking a series of small steps towards a subtle, more constrained approach? Am I pursuing the holy grail blindly instead of determining my path, each step forward, as I move towards that same big solution?

Often, you need to take each of those short steps, or iterations, before your smaller solutions add up into one that feels big (and appropriate). So if the task before you seems insurmountable, and you're totally stumped, change the problem's constraints. Throw out larger concerns, at least in the short term. You need a smaller box, and fewer variables to solve for (at first).

If you can start with solving for one aspect of a system, then slowly layering more functionality around it, you're more likely to evolve an elegant system than trying to solve for every architectural element from the very start. This would be the UX designer's equivalent of "thinking agile"—and being prepared to scrap your first ideas with every iteration, as the larger picture comes into focus.

I'm continually stunned by how really great design can come from choosing what tiny, modular bits should be reinvented—instead of completely overhauling every existing idiom within an interface. UX/UI designers thrive on identifying small patterns, then assembling and arranging them in ways that cater to user needs at a much larger scale. You aren't going to reinvent the radio button for a Yes/No question, or try a novel navigation scheme without at least considering horizontal or vertical navigation first. But questioning each small decision can open up pathways to ideas that have a major impact on your overall design. And users see how those ideas fit within contexts that aren't completely alien.

At the same time, we often work from specifications that say you have to include tons of functionality—much of which has a set of out-of-the-box features that are switched on and running when you plug them into your CMS. Turn it all off. Then, think through what's really necessary to make this experience great. Otherwise, you may just be shoehorning in functionality and content that takes up valuable screen real estate.

This advice may sound obvious, but we often get fooled by starting projects with a punchlist of what functionality is a "must have." We then end up with websites and applications that are bursting at the seams with features and content that one person out of a thousand will use once, then dismiss and forget about—often at the cost of dozens, if not hundreds of design and development hours. Sometimes it's a useful exercise to actually write out what functionality will be high-frequency use, then write on a separate sheet of paper what will probably be a low-priority to users. In the end, all of these features will need to be considered as an integrated whole—but at least you'll be clear-eyed as you move into formally designing your projects about what small details and system basics will need to be completely nailed—and potentially innovated.