Match the tool to the Problem

Our guest author this week is Daniel Ritzenthaler. Dan is a web design consultant based in Boston. He makes videos about common questions he hears from clients on Design Thoughts, and can always be reached on Twitter @danritz. Learn more about him at http://wurkit.com/.

How long has it been since you’ve heard designers argue about which method is better: sketches, wireframes, mock-ups, or HTML prototypes?

Probably not long enough…

One designer will claim that you shouldn’t do anything without sketching it out while another claims that doing anything less than full-on HTML prototypes is a waste of time. All of these tools have a special purpose so there’s no point in discussing which one is better. That would be a lot like an electrician saying his wire-cutters are better than the plumber’s pipe-cutters. Within the context of cutting wires it makes sense, but everywhere else it’s just silly.

There is one thing all these tools have in common: they help remove layers of ambiguity within a project. Think of them more as communication tools that help you clarify and demonstrate your intentions to other designers and to your clients. Occasionally they become deliverables, but it’s important to remember they can never provide the final answer.

This piece is about bringing clarity to this discussion. It will help you decide which tool to use without worrying what other designers are arguing about.

Match the tool to the problem

Sketches are usually hand-drawn graphics that contain screen ideas or explanatory graphics outlining the high-level problem or solution. They are the most valuable when the idea hasn’t been fully formed, explored, or realized in any way. Sketches will help you understand what general pieces are needed to accomplish your goals.

Wire-frames tend to be computer generated graphics illustrating the organization of content, features and functionality. Prioritizing the elements of a design and determining general page layout can be a very messy part of any project. A well built wire-frame will help you pull apart the individual pieces and make sure they are appropriate to the goal of the page.

Mock-ups are rich graphics intended to simulate the look and feel of a project so you can understand the impact visual elements have on the brand. A mock-up can set the right impression and communicate emotions and personality. Without actually building the website (which a lot of people do), there really isn’t any other way to concretely define what a website should look like.

HTML Prototypes are partially-complete versions of a website used to understand how pages interact with each other and flow from one area to another. More complicated interactions between sophisticated components might require a fully functional prototype to actually understand. When there are a lot of moving parts and goals have multiple steps involved, HTML prototypes can really help you find the gaps in your plans.

Let’s play with a few examples

You’re building a Basic Marketing Website and you already know the website’s goal, are confident in the assumed layout, and understand how the pages interact. Jumping directly into the mock-ups will be the best use of your time. That way you can get as close to the final result as possible in the least amount of time.

It’s the ninth time you’ve built a Well Understood Application and you deeply understand the goal and know how all the pages interact, but want to make it fit perfectly with your client’s team. This is where wireframes really make a difference. They can help you communicate how the application is organized and identify potential ways to make the interface more intuitive.

You’re starting a Brand New Idea, and the hardest parts are grasping the concept and determining how the pages will work together. For this to happen, you’ll probably need to jump back and forth between sketching and HTML prototypes until you’re confident the core purpose is captured. These initial HTML prototypes can also become great tools to illicit feedback from your team or potential customers (alpha/beta testers).

Now what?

Every project may need one or all of these tools in various order depending on the challenges you’re confronted with. So the discussion shouldn’t be about which tool is better or how to align them into a formal and rigid process. It should be about which one, at any given time, can give the most clarity and boost productivity.

Courtesy of : 52 weeks of UX