The first thing I do when building any new piece of software is build a prototype. Many times, though, that prototype is on paper, not on the the computer. I’d much rather get all the kinks worked out before investing any time staring at a glowing screen wondering why X doesn’t do Y like it’s supposed to.
When you’re developing a highly interactive user interface, it can be useful to mock-up the layout on paper first. Then put the wireframe in front of a user and ask them to demonstrate how they’d actually use it. Do they click where you expect them to click? Do they try to drag elements you expect them to drag? If anything they do seems odd, it’s a simple matter to cut up the sheet of paper and re-organize it.
Lately, I built a functional (coded) prototype without the benefit of a use case study or a paper prototyping session. The result was hideous. I ended up spending almost a month reworking elements of the UI to put them in the appropriate places before my client was satisfied – all of this work could have been minimized by sitting down with a user or two and walking through a paper mock-up. It would have been more efficient on the coding side and, more importantly, cheaper on the client’s side.
The last project I worked on, though, started out as a sketch in my notepad. I drew out what I thought the layout should be and spent a few days pretending to use it. Over time, I quickly realized my buttons should really be categorical tabs and that a minor element that sat in the middle of the screen should rightfully be hidden at the bottom. It took me about 2 hours of poking at a legal pad with a ballpoint pen to flesh out the operability of my new system, leaving the rest of my time available to actually build it.
Things run so much more smoothly when you thoroughly plan things out in the beginning rather than go off half-cocked with an idea that turns out to be flawed.
So the next time you’re planning a UI, build a paper prototype. Draw out what it will look like and make a mock-up of each successive screen and animated element. If a box on the screen expands, make both a small and expanded version. If a section has tabs, mock up both tabs. Then, sit down with a prospective user and have them talk through how they’d use the UI. Where would they click? What’s the first thing they see on the page? Give them a specific task and ask how they’d navigate to the appropriate menu or form to perform it.
I guarantee you’ll have loads of information to work with. You might even change your design completely. But one thing you won’t have to do is re-code a poorly planned design.