Interaction Design Demystified

Interaction design is the process of defining your interface’s behavior. For form design, I can’t stress enough how important it is. Having a solid, user-centered plan for your forms’ designs is the best way to ensure that they’re a success. This is where the design helps support a relationship between the form and the user.

Defining the Goal

An important part of planning any project is to define what’s required. Writing up documentation, defining task flows, and performing testing may seem a dull, unexciting venture. However, some attention to detail can greatly improve and inform your design process; with a solid idea of what your forms ought to achieve, it’s easier to create the solution that best fits the needs of your users. Fancy effects and graphics can make a form look and feel beautiful, but if it fails to provide the solution needed, then the design falls flat.

Creating documentation to describe the expected behavior of a system is an important task, and the resulting material is quite handy when you’re working with others or for a client. This type of document is formally known as a functional specification.

Identify the Users

Who’s going to be using these forms? Are the users tech savvy? Will they benefit from the fancy, progressive enhancements you’re thinking about employing or will that actually be a hindrance for them? Some designers go as far as to create user personas, fictitious characters that help a designer define the needs and abilities of the kinds of people who’ll use the site.

For a discussion of user personas and how to create your own, visit https://www.hhs.gov/usability/analyze/personas.html

For my part, I prefer talking to real people that fit into the target audience. The following table contains a mini profile of four real people whose interests and abilities we’ll use as a benchmark when we plan and build our forms.

Persona	Profile
Derek Featherstone	Fitness Interests: Triathlons, cycle trainers Technical Level: Very comfortable with the Web
Jina Bolton	Fitness Interests: Gym, casual cycling, WiiFit Technical Level: Very comfortable with the Web
Kelly Steele	Fitness Interests: Casual cycling, tennis, gym Technical Level: Moderately comfortable with the Web
Mathew Walker	Fitness Interests: Basketball, golf Technical Level: New to the Web

Identify Use Cases and Scenarios

While considering the people that will be using your forms, you should think about the various use cases that go along with them: so as well as defining the people who’ll use your site and their goals, this is about how they can reach those goals using the forms on your site.

Use cases help you answer a number of important questions. What do you (or your client) require? How will the form’s data be used? For registering an account on a social network, will members be required to fill the form out in its entirety, or can they just fill out the basics and complete it at a later time? What information should remain public? Should certain kinds of information be kept private? Why would someone register in the first place, and what’s important to them?

Understand Platforms and Devices

You might be using the latest version of Safari on your nice big MacBook Air, but another user filling out the form could be an everyday commuter browsing on their Blackberry.

When you’re planning a form, it’s important to consider all the platforms and devices that may be used for your forms, or you might cause a lot of heartache! For instance, I use Yelp for looking up restaurants, and occasionally I submit reviews. I would love to write these reviews as soon as I’ve left the restaurant, but I never do. Why? Because the form is horribly annoying and tedious to use on my iPhone.

Below, we’ve specified a number of browsers which we’ll use to test and refine our form design.

• Desktop: Safari 3, Firefox 2, Internet Explorer 6+ (limited functionality)
• Mobile: Generic mobile CSS, iPhone-specific

Define Task Flows

Once you’ve given some careful consideration to the users, use cases, and platforms, you should have enough information to plot out the steps needed to complete each form—a task flow. It’s also time to think about alternate paths and error cases. Sketch it out visually, so that you have a clear idea of what your process looks like; the image below shows us an example of a task flow diagram for a sign-up and login form.

By this stage you should have a fairly solid idea of what’s required in your form. It’s now time to put pen to paper!

Paper Prototyping

Creating a paper prototype of your form is a quick and easy way to hash out your ideas and issues at the beginning of the form development process. Draw your forms on paper: keep it fast, lightweight, and simple, sketching out a basic idea of how each form would look. You can even use a quick and cheap option like a stack of sticky notes; if you use a note for each object in your form, it’s easy to experiment with different arrangements. Use this hand-drawn form to assess how your form looks so far. It’s amazing how much more clearer your decisions about form questions become when you see them in front of you.

Try the prototype out on your peers—they might see stuff you missed. If it’s okay to show your forms to the public at this stage, perhaps you could head over to the closest café and try them out on some complete strangers after buying them a cup of coffee.

For a great, detailed introduction to paper prototyping, check out Shawn Medero’s article in A List Apart.

Wireframing

Now that you’ve completed your planning, it’s time to start designing. Begin with rough diagrams or wireframes before obsessing over the shiny buttons. What we’re focusing on right now is the layout. The diagrams you’ll see below are wireframes for an example website.

Notice that they’re plain, clean, and simple—there’s no need for a lot of detail or intricate design work here. Right now, we’re only hashing out the basic flow and general layout.

Sign Up wireframe

Advanced Search wireframe

Change Password wireframe

Edit Profile wireframe

Feedback wireframe

Privacy Settings wireframe

Have you used this process for interaction design? How does your approach differ, and what advice can you add?