Possibly the biggest mistake in any development project is failure to plan. Recently, the owner of a prospective start-up told me that planning was unnecessary and a good developer could just start coding. This, I promise you, will end in tears.

Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones. This is when the idea starts to take shape as an application, becoming boxes and buttons that users will interact with. This article will take you through a wireframing process; who should be involved, the tools to use and tips to enable you to make better wireframes.

1) Be Clear About Your Objective
As a developer I can understand the temptation to jump in and start coding. Often the initial idea seems so simple that surely you could just sit down and bash it out? Unfortunately, projects are rarely simple and anyone with experience will know what a myriad of unforeseen issues and challenges await you if you go down this route.

A wireframe will help you identify many of these issues in a way that is time and cost effective. It is far easier to make changes to a collection of paper screens than after you have written a thousand lines of code.

The process also helps to create a better understanding of the application. Putting it down on paper raises questions and ideas and leads to changes.

The final output will be a blueprint from which designers, developers, architects and project managers will work and makes sure everyone is in sync.

2) Make it Functional, Not Pretty
There are variations in how wireframes are presented and this is reflected in the various tools available. Fundamentally it is about the functional parts of an application, e.g. that a page will have 3 text boxes and 2 buttons. It’s about function not form.

At Howard Baines we take an austere approach to this and our wireframes include nothing but the functional elements (boxes, buttons, dropdowns etc). We ignore anything that could be seen as design or layout. Others may go a little further and include layout and other visual elements. Whatever works for you.

3) Draw on Your Experience
You do not need skills in design or development. All anyone needs is experience in using web apps or websites. Of course the more experience the better but you don’t need to understand relational databases to wireframe.

4) Decide Who’s in Charge?
Make sure someone owns the wireframe process. They are responsible for keeping it up to date and managing feedback, changes etc. In the case of a start-up this is often the founders, the ones with the idea and vision who understand the end goal. In the case of our clients we often take on this role. It doesn’t matter who it is so long as ’someone’ is in charge.

5) Involve Everyone
Maybe not at the first meeting, that should focus on simply getting the idea on paper and involve the key stakeholders whose idea it is. Fewer, people involved makes this process quicker. As the wireframe develops involve other members of your team and your client’s team. For example, if you are integrating your app or site with existing databases then make sure the DB owner can check that all the data fields exist in their database before you add them to your wireframe. Collecting a user’s fax number is no good if there is nowhere to store it. Equally designers have a good understanding of user experience and can spot potential problems in the flow early on.

6) Set a Deadline for Completing the Wireframe
It is important to set aside predefined periods of time and deadlines for deliverables to keep a project moving. The initial wireframing session could be one day or several depending on the size of the application. But set a period and stick to it. Follow up review meetings can be much shorter or even done remotely.

7) Keep it clean
If a particular page requires two text boxes and a button then it should have just that, no more, no less.

8) Avoid Designing Your Wireframe Too Much
Wireframing is about the functional way in which something operates it’s nothing to do with presentation or design. We try to avoid anything that could be construed as design. This will almost always distract the audience. Add a little blue just to try and make it more interesting and you will have a half an hour conversation about the merits of blue. Design should be left to designers.

9) Remember that UI is not UX
It can be extremely tempting to start thinking about the use of presentation methods such as AJAX. Remember that a wireframe document is about the functional elements and not the way they are presented or users interact with them. For accessibility reasons applications need to work without features like AJAX and therefore more like the wireframe.

10) Think About the User
It sounds obvious but it’s so easy to get caught up in creating a wireframe and forget about the user. The functional is what we’re focused on but it is still important to consider the user experience that is being created. For example, if you create a registration form that is three pages long you probably won’t find that many people fill it in.

11) Don’t Get Lazy
It’s often easy to say “the login page is obvious let’s not include it in the wireframe”. Make sure you wireframe everything. At the end of this process you should have a document that can be stepped through just like the final website. Every step counts and none should be ignored.

12) Organise Your Wireframe into Sections
A website or app is often divided into sections such as news, products and user account. Break up your wireframe document accordingly for much easier reference.

13) Number Your Pages
A web application often consists of a number of processes; a checkout is a good example. Often these are linear but sometimes users can choose different paths such as skipping a step. Clearly number the pages in your document and then label which page a particular action (such as clicking a button) takes the user to.

14) Look for Repetition
Consistency within an application is helpful to users, developers and designers. Repetition of groups of elements can therefore be a good thing. For example, wherever a user enters an address it should be the same fields in the same order. Look for these areas of repetition as you wireframe.

15) Check it all Makes Sense
The final document should be easy for anyone to follow. If only a developer can understand your wireframe then something has gone wrong. Ask at least one person who has nothing to do with the project if they understand it.

16) Ads are Functional
Many sites include advertising for monetisation, this may be as simple as Google ads but it is functional and not design, so include it.

17) It’s Not Just the Public Site
Many sites have an administration area for managing content, viewing registered user profiles, resetting passwords etc. This may not be viewed by many people but it is still important. Sometimes it can contain data that is not publicly available (such as a user account enable button). This is important information to developers when designing the database.

18) Know When to Stop
Make sure all relevant stakeholders have the opportunity to give feedback but don’t turn this exercise into painting the Sistine Chapel. Typically I would say three drafts should get the job done. The first gets the idea onto paper. The second reflects feedback from other parties such as developers, and designers. The third should be the final polish.

19) Choose the Right Tools
Pen and paper is often the way to start. It is much easier and faster than using a computer and lets you get thoughts and ideas down as the concept evolves.

Once you start creating the document our advice would be to use the tool you’re most comfortable with. Developers for example may use Microsoft Visio, project managers PowerPoint, Designers Adobe Fireworks.

I think that the wireframe should be a document though rather than something interactive (like design, it can be a distraction) and therefore creating HTML may not be the best thing.

There are a number of specific tools for wireframing, for example Balsamiq provides an environment for quickly adding and customising common interface elements. They have given it a hand drawn feel to provide a visual lift while not actually being design.

20) Consider Dependencies
Everyone knows what a shopping cart process is, right? Therefore it’s easy to wireframe and put to one side. Not entirely. What if you’re using a third party payment provider such as PayPal? That may influence how parts of the site must work. Research the areas where there will be dependencies and make changes accordingly. It’s easier to do it now than later.

Hopefully this article has provided a clear sense of the wireframing process, who’s involved, how to approach it, the tools to use and what the final output should be. The most important thing to remember, however, is that a thorough and well put together wireframe can save you a lot of time later in dealing with issues later on down the line.

Do you have any tips for creating great, usable wireframes fast?

We live in an extremely exciting period of human history where it has never been easier or cheaper to start a web-based business. You just don’t need a bricks-and-mortar shop to make it big anymore.

However, there are still a massive number web start-ups that fail every year. How can you avoid becoming one of them and being plunged into the TechCrunch deadpool?

In this series for Vitamin, I’ll be sharing some of the valuable tips you’ll need to survive and thrive as a new web startup. I’ll also share some exclusive new content from our upcoming workshop, Start-up Clinic.

So if you’re itching to tell your boss where to stick it and start your own company, this series of articles is perfect for you.

You know those gossipy websites that show photos of celebrities without their makeup and fancy hairstyles? At Sparkplug we have a similar dirty secret — underneath the sexy exterior and suave feel of our websites lies a series of ugly, puffy, just-rolled-out-of-bed iterations that would make the paparazzi shriek for joy.

Getting the feel of a web application right – that careful balance of design, functionality and gleeful first impression – takes a lot of sweat, and often a number of false starts. If your final release looks anything like the first draft you doodled on a cocktail napkin, chances are you’re not putting in the time to get it right.

In this article we’ll look at the process we went through to design just one screen of our TeamSnap web app – and the long journey between “it functions” and “it feels right.”

Wireframe Schmireframe

In the past we tried wireframing websites to show our clients what we had in mind, dutifully drawing in little boxes to indicate what “pieces” would appear on each page. This turned out to be borderline useless:

• Our clients couldn’t look at a wireframe and imagine anything resembling an actual website.
• Actually, neither could we.
• What we thought should be on a Web page and what actually fit from a visual perspective often turned out to be completely different.
• It’s hard to get excited by a wireframe. (Don’t discount this; passion counts when you’re building something great.)

Pretty quickly we learned that the best way to start designing the look and functionality of a website was to actually start building the website. Sure, we end up doing a lot of redesigning, but experience has shown that we’re going to have to redesign anyway, so why waste time in the beginning trying to plan what we’ll inevitably end up throwing away?

Version 1: Ugly and Unusable

TeamSnap is a Web service that helps you to manage your recreational or youth sports teams. It came about because several people at Sparkplug play recreational sports and wanted a way to manage their own teams. The application lets you keep a roster and schedule, post and send messages, store and view game photos, assign who’s bringing refreshments and track player availability for each game. We’ll look at the Availability feature in this article, because it seemed exceedingly simple at first, but turned out to be quite complex once we dove into it.

Here’s what the Availability screen looked like in our very first design mock-up:

The concept is pretty simple: List the games, list the players, provide checkboxes to indicate who’s available to play. (Note that we’re showing Manager mode here, where the team manager can edit everyone’s availability. An individual player would only be able to edit their own availability.)

Right away you can see some serious problems:

• Edit mode yields a sea of checkboxes inside table grid boxes. The whole page is visually unpleasant, boxy and difficult to read.
• On submitting this form, the database is going to have to make a server-munching 160 or more updates to save all of this data.
• There’s key information missing, such as the times of the games or a way to display availability for practices.
• We hadn’t even figured out yet what to call this feature. (“Participation” was our first stab at a title, but it sounds like a ribbon you’d get for displaying a slightly-irregular sheep at the state fair.)

Version 2: Better, But Problems Remain

After a few more iterations, and a wholesale redesign of the top banner, we came up with this version:

There are several notable improvements:

• We only allow for editing one player’s availability at a time. This prevents the sea of checkboxes and cuts down on the database hit every time the manager makes an update.
• We break down availability by gender (for co-ed teams only).
• We added in availability tracking for practices and added subtle background highlighting to differentiate practices and games. We also added highlighting to show which player is currently being edited and included game and practice times.

Smugly, we started showing this version around to our early testers. Unsmugly, we returned to the drawing board after we discovered that problems remained:

• Visually, this is quite monochromatic and doesn’t subjectively “feel” very pleasant. To put it plainly, it’s kind of blah.
• We’re worried that users are going to forget to save their changes after clicking on the checkboxes. As a precautionary step we’ve disabled all the other navigation on the page so the user can’t click away, though we suspect this may be confusing.
• This screen is going to get very wide if a team has more than eight games and practices.

Version 3: A Prettier Face

Another few iterations later, after some heavy-duty design work and some re-jiggering of features, we came up with this version. We were pretty sure we had it perfect:

There’s a lot to like here:

• Better gradients and shading to break up the monochromatic feel, plus a distinctly shaded “Manager” column to distinguish the manager functions.
• Paging in the upper right to handle an unlimited number of games and practices, plus a filter in the upper left to allow the user to show all events, just games or just practices.
• Removal of some grid lines to open up the feel of the page and prevent it from being composed of nothing but tiny boxes.

We felt pretty good about this version. So good, in fact, that it became our operable template as we began building the Availability back-end in Rails. Soon, however, programming ground to a halt as we launched into what became known as The Great Debate.

The Great Debate

Our Creative Director felt very strongly that there should be only two states for Availability. Either you were available (green dot) or unavailable (no dot). He didn’t care if you were a “no,” a “maybe,” a “don’t know” or a “have to check with my spouse.” As a manager, he simply wanted to know: Can you commit to being at the game?

Our Development Director felt equally strongly that it was important to know if someone couldn’t be there. Without being able to distinguish between “no response” and “no,” you had no way of knowing who might show up and who wouldn’t.

After debating this internally for several days we did what we should have done in the first place: We called up a few team managers and asked them what they wanted. The results were unanimous. They wanted to know if someone wouldn’t be there. They wanted a red dot.

Victorious, we began to add this to the system, only to realize something very troubling: We now had three states (yes, no and unknown). Unfortunately, an HTML checkbox only has two states (on and off), so there was no way to represent the three possibilities. If a checked box meant “Yes, I’ll be there,” what did an unchecked box mean? It couldn’t both mean “I won’t be there” and “No response.”

For three-state choices, you need drop-down menus.

Bring on the Drop-downs

Frankly, we hated this next version. From a usability standpoint, drop-down menus require a lot of finicky pointing, clicking and dragging, which makes them slow to operate. They also require reading instead of iconic recognition, which makes them slow to parse. Functionally this worked. Feel-wise this was less than ideal:

We also explored the possibility of three radio buttons for each event, but rejected that as being absurdly cluttered, or in designer’s parlance “butt ugly”.

The Obvious Solution – Finally

What we needed was an HTML widget that didn’t exist – the multi-state checkbox. Luckily, with some graphics, some Javascript and a bit of pluck, we realized we could build our own. Our homegrown checkbox had three states – empty, yes and no. Just click to cycle through the three options:

Even better, by hooking the checkbox code directly to the database with some fancy AJAX wizardry, we completely eliminated the modal editing state. Instead, you are always in edit mode with no need for an Edit or Save button. Every time you click a checkbox your availability for that game or practice is immediately recorded to the database. It’s much simpler and goof-proof for users, yet these always-clickable checkboxes are so visually pleasing that they never feel overwhelming, even with many on the page.

We also use AJAX to immediately update the total available players count in the footer, adding a subtle blinking effect to visually confirm that the change has been recorded. Alas, a static screenshot can’t give you the emotional satisfaction of actually poking the AJAX widgetry yourself; if you want to try it out you can sign up your own sample TeamSnap team (for free) and give it a whirl.

This final version also has a few more visual tweaks:

• Player thumbnail photos, which make it much easier to visually parse who you’re looking at for each row.
• Some more visual and typographic changes to the list of games and practices in the header row, including colored flags to differentiate between games and practices/events.
• The inclusion of a help tip that appears when the user first visits the page (hidden in the screenshot above, but triggered by the blue “i” next to the paging icons).

Perfect? Hardly.

Happy as we are with this version, we know that in the coming months we’ll continue to tinker to improve this screen further. There’s no such thing as being “done” in a Web application. Our users have already suggested ways in which Availability could be improved, including:

• An additional state for the checkbox, to differentiate between “Not Sure” and “No Response.”
• The ability to use the information from this screen to set game lineups, allowing the manager to “lock” availability close to game time and assign positions, as well as export a printable lineup card.
• Allowing players to set their availability by clicking on a link in an email, bypassing this screen altogether

These are all good ideas, and in the coming weeks we’ll be evaluating them to decide which can be implemented without making the basic functionality of the Availability screen too complex. Before adding any feature we look for the right balance of simplicity, power, utility and feel. Because no matter how handy a feature is, if it doesn’t feel right people won’t use it.

Getting from functional to “feels great” can be a long process, and sometimes it’s frustrating to tinker with existing features when you want to be adding new ones. But the payoff – a page that just looks and feels right to the user – is worth the time spent on each revision.