LUA CHEIA

  

Interaction designers create wireframes in tools such as Adobe Illustrator, OmniGraffle and Microsoft Visio. Originally, these wireframes were primitive shapes drawn to represent various UI elements. Many of us cannot imagine life without them.

There are, however, reasons to consider moving to the cloud to do interaction design. In short, today’s cloud-based tools are:

• Optimized for collaboration,
• Editable anywhere,
• Interactive,
• Published in real time,
• Self-maintaing (the user doesn’t need to update software),
• Payable monthly,

Emailing your old static designs will feel old fashioned once you see what these tools can do. Going a step further, there are tools for the user review process, too. Just upload your ideas, from simple mockups to final layouts, link them together, and share them for comment.

(Image credit: baldiri)

This article walks you through the current selection of cloud-based tools and provides some recommendations. The number of offerings and amount of functionality are pretty vast. For the sake of brevity, we’ll address two functions: prototyping and wireframing. But if you’re intrigued, you might want to explore cloud-based image editing, mind-mapping tools and other UX activities. These tools are already out there, and surprisingly good.

Prototyping

For our purposes, prototyping involves uploading images (screens) and linking them together via hotspots. Once these are set up, the prototype is published and available to reviewers for usability testing, commenting or both.

Review criteria
Here are the fundamentals that a product should support in order to compete in this space:

• Quick uploading process,
• Support for several source image file formats,
• Easy linking between pages,
• Support for feedback from end users.

Some items aren’t available as of this writing:

• The ability to nudge images in line without having to recreate them;
• The ability to create interactive objects and layer them (such as a menu bar that appears on every page).

InVision

What it does
Create your screens in your favorite tool and upload them to InVision. Then add hotspots; a hotspot links to another page. This is great if you live and die by the comp (Photoshop file). For example:

1. Create a new project. Think of a project as a collection of previously generated comps that you are going to tie together as a prototype via InVision.



2. Upload your files to this new project (the images in this article are PNGs).



3. In “Build” mode, create the hotspots. Basically, you are linking together the prototype. If you have all of the collateral that you need, this will go quite fast — exactly as you’d want it to work.

Observations
The application works as advertised. It enables the user to quickly wire up prebuilt comps, wireframes and sketches. The tutorials also explain useful actions, such as creating hotspots that will be the same on multiple pages (these are called “templates” in InVision).

Speaking of templates, they expose both a major advantage and a major disadvantage of this tool: if the uploaded images are not placed perfectly, then the templates will not line up properly. One would want the ability to adjust the x and y coordinates of any image so that they line up perfectly without having to change the source files. On the upside, if you’ve done the prep work right or you’ve made your hotspots large enough, you can fudge this a bit, and the templates really accelerate the build process.

A number of usability issues have made me scratch my head. For example, the first time I tried adding a hotspot to the search input field, the “Link to…” modal dialog was off to the left side of the browser, which made it impossible to save or cancel the dialog. I then tapped the “Update screen” at the bottom of app to refresh the screen. It turns out that in InVision speak, “Update” = “Replace.” I was afraid to refresh the browser because there is no indication of whether the application saves automatically. So, in the end, I switched to “Preview” and then back to “Build.”

Once you’re familiar with the quirks, however, the application is useful. If you’re a designer or want to work offline to generate wireframes, then give this app a hard look.

• Upload process
  Drag and drop, or browse the file system
• Supported file formats
  JPG, PNG and GIF
• Linking pages
  Easier than the others tested because of templates
• User feedback
  Easy, nested
• Marquee clients
  eBay, Google, Intuit, Whole Foods and many others. Very impressive.

FieldTest

In spirit, FieldTest (in private beta) serves the same space as InVision. The designer uploads prebuilt comps, wireframes and the like to FieldTest, ties them together, and then publishes them for review. One advantage is that FieldTest leverages device gestures. In short, you can “play” FieldTest prototypes on your iOS, Android or Windows Phone 7 device and have it respond to gestures. Combined with the built-in screen transitions, this is a powerful function for mobile app designers.

As with InVision, screens are grouped into “prototypes” (projects). Including them in a project means that they can be linked to and from other screens. The process is the same, too: create the prototype collateral, link it together via hotspots, and publish it for review. For comparison’s sake, here are the hotspot configurations for the two apps.

This demonstrates the differences in approach. On the top is FieldTest. It allows a user to choose between gestures (the prototype I built was an iPhone app). The gestures are tap, long tap, swipe, swipe left and swipe right. Multiple gestures can be active for the same hotspot, which is particularly cool and gives a realistic experience of various actions. On the bottom is InVision, whose ace is templates. The author can create a template for several controls that appear together, and they can reuse that template on several screens.

Observations
If I were to choose between these prototyping tools, FieldTest would be my choice, largely because I build mobile applications. Having listeners for multiple gesture types makes for a more realistic prototype. If the app were Web-based, then InVision is more mature.

FieldTest still has work to do, though. In the beta, gestures such as up and down are missing. Templating as InVision does is really useful. It streamlines the addition of hotspots. Another area for improvement is in comments, and allowing a prototype’s end user to provide feedback.

There are other usability nits. For example, FieldTest includes a status bar at the top of each screen. I have yet to figure out why someone would want this, and it’s not optional. So, if you take a screenshot on an iPhone, you’ll have to edit it to remove this status bar, only for FieldTest to put it back.

Try it out for yourself on the prototype built for this review. Please note, there is no down gesture, so if you want to try that, gesture from right to left (like when advancing through pictures in iPhoto).

• Upload process
  Browse the file system
• Supported file formats
  JPG, PNG and GIF
• Linking pages
  Fairly easy
• User feedback
  Enables gestures on the device, which is great.
• Marquee clients
  In private beta

ClickDummy

ClickDummy is another competitor in this space and has the same process as the others. The user uploads materials and then links them together through hotspots. The link function is a “tool” contained in a drawer (i.e. a UI element that slides in and out from one side of the screen).

Observations
This drawer seems innocent enough, but it creates unnecessary hurdles for the user. In an attempt to simplify the problem, it has added confusion and multiple steps to an easy process. How? The user has to toggle between this tool drawer and the page-picker drawer a lot. The page picker also has to be overloaded in order to provide both functions (selecting a page, as in navigation, and selecting a page, as in a hotspot target).

A second issue: the website says that the user can drag and drop images onto the pages drawer. This doesn’t work in my (Chrome) browser. It instead replaces the current page with the image. After a panicked “Backspace,” the user is restored to their project but has lost their location and has to start over.

Another point: this all-important drawer is closed when the app launches. It took about five minutes to determine that the app was working, and this after weeks of looking at apps in this space.

Lastly, unlike both of the apps reviewed above, this one has no compelling feature that makes the additional effort worth the time. In future, hopefully, the addition of some product differentiation, combined with a rework of the primary use case, would make this application worth another look.

You can see the output from this exploration for yourself.

• Upload process
  Drag and drop, or browse the file system.
• Supported file formats
  JPG, PNG and GIF
• Linking pages
  Most difficult of those tested
• User feedback
  Easy to test, but comments require registration
• Marquee clients
  Not provided

Wireframes

Think of a wireframe as a black and white low-fidelity screen mockup. The mockups I create also include call-outs to give the development team additional context.

In the process, the user will create an account, create a project, and then land on a blank screen. The user then drag and drops UI controls (radio buttons, text input fields and so forth) onto the page.

Once the project is saved, a permalink can be given out for people to see your work. If you change a screen, it will auto-magically show your updates the next time that URL is opened (or refreshed) by a team member. This last point is what the cloud is all about: everyone always has the same (i.e. current) version of your work. Changes are instantaneously available whenever the wireframe is saved.

Compared to most offline tools, the library of available objects is focused on low-fidelity UX. Don’t expect to create gradients or to use a pencil tool.

Review criteria
Here are some basics that are fairly universal in my experience:

• Robust set of standard UI controls
  If the tool doesn’t have off-the-shelf drop-downs, toggles, cover flows and the rest, then creating those controls will require additional work.
• Good as a documentation medium
  Plan on your development team using your wireframes to dictate the logic and layout of the application.
• Good for making wireframe clones, templates or whatever you want to call them
  Not surprisingly, all of the iPhone wireframes I create have the app’s name at the top. I want to do this on the first wireframe and not have to do it again.
• Responsive
  It all takes place in a Web browser. If the application is slower than a locally running application, then your productivity will suffer. Case in point: a year or two ago, I created about 50 wireframes for a project. Each page took a minute to load. To see my changes reflected, another minute. Trust me, this gets old quickly.
• Not written in Flash
  “Dear development teams who write these tools: I love Flash, Flex and the rest. Not as much as I love my iPad, however. I want to edit my work across form factors. It’s all drag and drop, right?”

Here’s what you won’t see right away from the tools out there:

• An extensive stencil library or the ability to easily create and reuse stencils
  OmniGraffle excels at this. Don’t expect Yahoo to create a stencil library for Mockingbird anytime soon.
• A wide user base
  Momentum is building, and there are believers. This is still a minority position and will be for some time. I would say customer support is great, but the more people use these tools, the better the tools will become.
• Font selection
  I won’t dwell on this, but you can tell there is still some lively debate about what a wireframe should and should not communicate just by looking at what features are included in any given product.

Balsamiq

As with the prototyping tools, wireframes — or “mockups” in Balsamiq-speak — are organized into projects. From there, things change. Tools like InVision and FieldTest assume that you have created your pages or screens in another tool. In Balsamiq (and Mockingbird, discussed next), the tool is designed for wireframe creation, with extremely limited functionality for prototyping.

1. Create a new mockup.



2. Drag and drop an off-the-shelf UI control from the ones available.



3. Configure the control to your needs. This is noteworthy, because Balsamiq provides a number of important options. For example, there is one toggle to put the iPhone in landscape orientation instead of portrait.



4. Add the rest of your UI controls; document for the development team; and publish.

Observations
Having worked with some other tools, I’ve become a fan of Balsamiq. A great UI control library and easy object configuration are two areas where this tool excels. There are some areas for improvement, though. First, and I’m sure the development team is tired of hearing it, the sketching style is fine for those who understand low-fidelity mockups, but you probably wouldn’t want to show the mockups to your CEO.

A second gripe is that the editing tool is built in Flash, so work is limited to platforms that support it.

On the upside, a few non-obvious pros:

• The icon set is great. I’ve noticed that only one icon is not in the box: Bluetooth. Anything else I’ve needed has been available.
• In addition to drag and drop, there’s a great quick-add feature. After typing in a few characters of the name of a UI control, a filtered list appears, allowing you to add controls quickly.
• Balsamiq has an odd markup language that, once mastered, allows the user to add common things. For example, + Add and sub-menu, > translates to:

And here’s the rundown:

• UI controls
  More than 70, including iPhone-specific
• Good for documentation?
  Call-outs are one of the controls; drag and drop them onto the canvas.
• Good at duplicating screens?
  Yes.
• Responsive?
  Yes. You will forget you are working in the cloud.
• Written in Flash?
  Yes.

Mockingbird

Mockingbird is also a wireframing tool, and a good one at that. In some ways, it compares favorably to Balsamiq: Mockingbird’s editor isn’t Flash-based; it uses an unobtrusive font; and adding UI controls is (almost) comparable to Balsamiq.

The process is similar, too. Here’s the outcome:

Observations
More professional, right? On the surface, it is more polished, but there are some subtle shortcomings. For example, one cannot left-justify text in an input field. Also, I couldn’t get the icons to all be exactly the same size (36 pixels). And so forth.

There are some logistical hurdles as well. Many of the controls are primitive. To add a call-out, like ones in yellow above, you actually have to add two objects: the yellow circle and the black text. And when a control is added via the quick-add function, the filtering text is not cleared, so after every addition, one has to clear the previous query. Put practically, this mockup took about four times as long to create as the Balsamiq version.

• UI controls
  Fewer than Balsamiq, and no mobile-specific controls.
• Good for documentation?
  Call-outs are created with circles and overlaid text.
• Good at duplicating screens?
  Yes.
• Responsive?
  Mostly — don’t use Chrome.
• Written in Flash?
  No.

Mockup Builder

Another entry in the wireframing space is Mockup Builder. Functionally, it lies somewhere between Mockingbird and Balsamiq. It has a fairly good library of controls — in fact, it’s the only cloud-based solution with native Android controls (Ha!). Moreover, I find its aesthetic better than that of competitors.

Like the others, Mockup Builder starts with a blank canvas, and the user drag and drops controls onto the canvas for configuration.

Here’s the mockup created for this review:

Again, the mockup is fairly clean, but there are some issues: the icons use some funny clipping, and they do not scale properly. The user cannot toggle the various defaults for the iPhone, such as the gray bars at the top and bottom of the screen.

Observations
This tool is a little too buggy for everyday use. For example, the notes to accompany illustrations are in Lorem Ipsum text. Also, when copying text from the Web and pasting into a multi-line text area, the text does not wrap to the control’s width — meaning that the text shows exactly one line, and the user has to use the control’s handles to wrap it. I also wanted to show two paragraphs of text but could not figure out how to insert a “Return” in the text.

Another grievance: the tool could use more polish. For example, the screen surface on the iPhone control is narrower than the keyboard, so the user has to resize the keyboard by hand. When that’s done, the “e” is missing in the button. I understand that these are minor, but one would expect these t’s to be crossed off before moving away from a beloved tool like OmniGraffle.

• UI controls
  More than the others, including iPhone- and Android-specific ones
• Good for documentation?
  Call-outs are one of the controls; drag and drop them onto the canvas.
• Good at duplicating screens?
  Yes.
• Responsive?
  Yes.
• Written in Flash?
  No.

Conclusion

Cloud-based tools are now available and well designed for UX work. Many of the features in the offerings above are not available in software running locally on your machine. While this space is still growing, I’ve been working in the cloud for the past two years and cannot imagine going back.

Collaboration is instantaneous, and the tools are optimized for the right activities: wireframing and testing with users. In fact, these apps have several unexpected and delightful features, and you might find yourself walking away from your favorites, too.

Of course, there are valid reasons to avoid working in the cloud. Stay with your old standbys if any of the following apply:

• Your IT department disapproves.
  This is a hot-button issue. All of these tools protect your information, but this is still worth considering.
• You expect the polish of offline tools.
  These tools are for early adopters. Still, they are Web applications, so they will evolve. That’s what happens on the Web. You’ll just wake up one morning to find some annoyance removed or a key feature added.
• Your project is big.
  If you plan on a 200-screen flow, you will feel a steady degradation in performance. That said, I’ve just completed a 70-pager with one of these tools and was just starting to notice some minor falloff.
• You think in terms of “deliverables,” with a complete set of create-once mockups.
  Many of these tools have coauthoring functionality (if the roles are set up that way). In my experience, however, no one has actually changed anything, even if I wanted them to.
• Your Internet connection is a problem.
  But that’s not to say that you’ll lose data whenever the network is interrupted.

These could be a deal-breaker for some. But these tools are free to try, and some are so simple that you might get hooked in five minutes (as I did a few years ago). Almost all of the research for this article was done with free trials. Given the ease with which you can try these out, you have every reason to go out and see whether one or more is right for you.

If you have another favorite, we’d love to learn about it. The space is ever changing!

(al)

© Erik Perotti for Smashing Magazine, 2012.

  

A few weeks ago, I was quite surprised when I saw the pavement quickly approaching while I was out for a walk. Laying there stunned, I soon realized what had happened: I fell. Ouch. B-minus. I normally try to be as attentive as possible, but this time a big crack in the pavement caught my shoe and threw me completely off balance.

After reporting my clumsy accident to friends and family, I instantly received comments like: “be more careful” or “better watch out next time”. In the end, I started to defend myself—if that crack would not have been there, I most likely would not have been face-planted.

When it comes to filling out forms on a mobile phone, I have observed many users running into a similar experience, merely less painful in its physical aspect. Many elements within a mobile form affect how smoothly users will get to a service or product hiding behind a form of any kind.

There are several factors that can be considered to be stumbling blocks throughout the journey of filling out a form. Specifically on a portable device, this journey is complicated by the fact that we have to consider contextual parameters such as time, location, or limited input options, in comparison to a firm desktop experience. In this post we will look at the most common stumbling blocks for mobile devices. Moreover, I will discuss design strategies to avoid stumbling blocks and to facilitate a safe and quick stroll through forms for mobile users.

Help Users Stay On The Right Path

Some might say that elegantly designed forms can be compared to the likes of an efficient traffic system—as soon as you enter the road, you also enter a world of permanent and dynamic guidance that helps navigate you safely to your final destination. For example, the crosswalk signals tell you when it is okay to cross the street, just as the street signs signal the names of the streets that you are on.

Street lights are also provided to help you navigate through difficult terrain in the dark. Keeping in mind your ultimate destination, you ultimately decide where to go, step by step. Road signs present your options and point out limitations. You can follow the traffic, take a short cut, or obey the navigation system on your phone.

In this situation, comprehensible and timely feedback is vital. The same applies to mobile form design. Signposts and immediate feedback encourage users to complete a form. Although inputting data on a mobile device can be very cumbersome, many people happily key in vast amounts of information when using services such as Twitter, Facebook, or text messaging on their mobile devices. Such services are good examples of how seemingly poor interfaces will not stop people from using a much wanted service, as long as the return of their effort is evident. People who understand and trust the outcome of their journey are less likely to hesitate about wandering even down a difficult path.

However evident the effort of typing on a mobile device might be, inputting data can take some time and can also become frustrating very quickly. Letting your users know almost instantly that they provide data in the wrong format, or that their username is already taken, is important. In the same way, a form can tell them where they are within the form, to make sure they don’t type the right data into the wrong field.

Furthermore, portable devices are more likely to suffer from connection errors and slow connections than desktop devices. Client-side validation techniques, such as HTML5/CSS based or optimized JavaScript approaches, have proven to be advantageous in this case, as they reduce the amount of data transfer to easily allow UI enhancements while coping with less stable connections. But keep in mind when using JavaScript for form validation, that some mobile browsers (such as the Blackberry OS browsers—except of the most recent one), are not JavaScript enabled per default. Therefore, users who are unable or uninformed about how to change their settings will benefit from implementations following the concept of progressive enhancement. The less time users spend on retyping data or waiting for data to be validated the quicker and happier they will get through a form.

Minimize Steps And Crossroads

One of the biggest take-aways from the Keystroke-level model in form design is that navigating along interactive elements requires both physical as well as mental activity. This can have a severe impact, especially on a mobile phone, based on the natural way of interacting with a portable device. Every input field within a form requires users to scroll through it, understand its meaning, focus on it, and then provide the correct information.

Due to the fact that people use their devices in a lot of different ways and these devices vary “greatly”, form elements that are spread over several input fields are prone to be rendered on a mobile device in a way unintended by the designers. As an example, during user testing sessions, I sometimes see users getting stuck on providing their phone numbers when having zoomed in on the form. The typical behavior is to enter their entire number into the first box provided for the area-code, completely missing the second input field. After submitting the form, they are puzzled about why there are two fields and the corresponding error message.

Separated telephone number fields (left) in comparison to a unified field (right) with optmized input type and a label within the field to remind users about the area code.

To allow users to get through a form quickly, there are a variety of compression techniques to reduce the amount of fields needed to provide certain data. Many of them require more post-processing on the back-end. If you can’t dissect numbers on the back-end, smart defaults or clever instructions work just as good. Some of them simply require a thought about the way of keying information into a field. For example, using a predefined drop down to provide the date of birth, rather than a loose input field or htlm5 optimized input fields for numbers, mail addresses, or other types of data, when appropriate. Dynamic input masks can help users to provide even quite complicated types of data with ease. Moreover, it will just take you a minimal effort of scripting.

At other times, forms might benefit from rather unconventional approaches such as text input fields for a quick and easy country selection. Furthermore, there are a variety of libaries such as jQuery mobile to optimize input fields and to ease validation, even for complex data.

Overall, our goal is to allow people to navigate through the form, achieving the quickest possible success with the least necessary effort. At all times we want them to feel that they are doing the right thing, and that their time is well spent. Brevity is crucial. Some people get stressed when spending too much time on trying to find hidden checkboxes, switching between keyboard layouts, or attempting to understand skewed marketing questions. Some people get physically tired answering redundant questions, filling unnecessary blanks, or scrolling up and down to find a required field that they just missed. To reduce cognitive load as well as physical effort it is important to remove optional steps from a user’s radar of attention, simplify the way of inputting information wherever possible, and to create a comprehensible flow throughout the form. If the process is too complicated (or the effort too high) a dropout is quite likely.

In the end, fine-tuned and streamlined forms will save your company phone calls from frustrated users and lead to more and more happy ones as it requires them to spend less time navigating through input fields and figuring out their meanings.

Uitilize Signposts And Mark Paths Clearly

Another great design concept to exploit for form designs are the Gestalt laws of grouping to help support the orientation of users. Applying grouping principles to a multiple questions form allows us to structure content, to create a visual flow, and to group related form elements.

In many projects I have seen design teams arguing about whether to break down a rather long form for mobile devices into several short pages or rather for one long page. Either way, there are endless possibilities for both design approaches to elegantly confirm users about their progress. This helps them recover from their errors, and to make them feel confident that the data being saved will not have to be reentered (in case they loose the connection, or accidentily close the application).

Both design approaches have their individual benefits, the only spanning factor here is the breakdown of the long form into meaningful and manageable chunks. For single-page designs, this means that it should even be possible to visually distinguish the single steps from one another. Especially with portable devices, the longer a form page is, the faster users will be able to scroll through, in case they have to jump between fields. Poor visual guidance in this way will result in users missing to fill out fields, losing sight of fields, and/or getting frustrated by searching for them after being presented error messages. White space and general grouping techniques are therefore vital to create visual guidance throughout a form.

Using color coding to highlight the active input field from other input fields (left) or to visually differentiate sections from one another in a long form (right).

Distinct grouping in interface design is a basic exercise because of its power for reducing processing speed and cognitive load. A while back, Matteo Penzo investigated the effect of different visual grouping techniques for a typical sign-up process. In his eye-tracking study, he analyzed the importance of label alignment for input fields and highlighted the superiority of top-aligned labels in many cases. Easy to distinguish input fields with top-aligned labels in close distance to one another allowed users to look at the label and the field in one go.

Other techniques required higher processing efforts, thus increasing the coginitve load and the time it takes to process the entire form. Less effort is good, and despite the granular example, we have to keep in mind that all these factors add up through input elements, the different sections, and the form as a whole within the website. The more complex the form, the bigger the effects of distinct grouping. Reducing the need for visual fixations allows a reduction in cognitive load, helping users to focus on their task and allowing your form to function almost like a navigation system—helping users to find their way to the goal.

By considering the effects of distinct groupings, we support our human capability to naturally perceive objects as organized patterns and take away the need for users to create an understanding about the form by reading the questions in depth, relating to the elements mentally. Naturally we want users to read through the questions. But similar to a vis-à-vis conversation, we can use facial expressions in combination with the words we say to underline our message and to get it across more easily.

Allow For Platform-Dependent Shortcuts

One of the major reasons that users get stuck on forms when filling them out on portable devices is limited visibility. Users, who are entering key information into a form’s field, usually have more than half of their screens covered with the keyboard, input suggestions, and other status information. To navigate between fields, and for general orientation, I see in many testing sessions where participants frequently try to disengage the onscreen keyboard, when looking for certain fields, or scrolling through the form to increase visibility.

However, many people will use the “return” button on the bottom right of the keyboard to disengage it after keying information into the field, or even to confirm their input for the single field. Although this approach helps many users to get rid of the keyboard (and to see the form on their whole screen), pressing the button also means, in many cases, that the form will be sent to the server straight away. Therefore, many users will be confused by a loading screen and the need to wait for a server response after pressing the “return” button.

The return button on Android (left) and iOS (right) is very salient within Web forms, and pressed by many users without the intent to send off the form.

Using the keyboard to send off a form is very handy, when using a single field form such as a search box. However, for multiple question forms on portable devices, it is important to check the form on the client side before sending it off, when users press the “return” button (by accident) to avoid confusing loading times. To ensure that your form is not submitted by accident, there are plenty of client-side validation tools; jQuery plugins, for example, provide everything we need.

Provide Contextual And Personalized Guidance

In short, be a tour guide. After all, designing a good form is like planning a hike with friends or family. Not only do we need to find out who will be on the trek, we need to plan for breaks, points of interest, and unguided side-treks in order to make sure everybody gets the most of their hike. However, as most of you will know, most hikes are not free of problems, and difficulties are inevitable; people can wander off, some might need help or more time to get through challenging passages, weather conditions are bound to change, and general mistakes happen. It is seldom that all of these inevitable difficulties will evolve into a real problem as long as we are prepared. Similarly to a hike, difficult situations are all about awarness, clear communication, and guidance. All it takes is a good approach to inform users what their problem is and what they can do to fix it.

There are plenty of techniques to help strayed users find their way back to the right path. Putting messages under input fields, for example, has proven to be quite a solid approach for telling users what has gone wrong. In combination with noticeable color coding (i.e. red for errors, or green for confirmation) you can be sure to get the necessary attention.

Two designs showing prominent error messages for misspelling hints (left) and general processing errors (right).

Another important aspect that is often neglected when it comes to messages within forms is the choice of words. On the one hand this refers to what we say, and on the other, it is about how we say it. Your error messages or instructions will most likely be read by a nontechnical human being. Let’s create messages as we would be talking directly to your user: avoid jargon, be tactful and brief. There are many useful recommendations on how to design effective error messages. Most importantly, we want our users to understand what happened and why it happened in a clear fashion.

On top of that, most users will not only appreciate clear notification, but also advice on how to fix the problem right away. Dyson, for example, managed to reduce support calls and increase the confidence in their products with a simple change in the way they display error messages. Rather then showing the problem (e.g. “Low Voltage Error”), they switched to displaying possible solutions (e.g. “Check Power Cable”). In this way, they are not only making their users aware of problems, they are also giving them guidance on how to fix them. On your form, many different users will possibly make similar mistakes. If possible, it is a good idea to analyze inputs to include a solution for the problem that helps users to recover them quickly. Ideally it even relates to the data they wrongly provided.

Wherever error messages pop up troughout the day, try to record them. At the end of the day, those records can tell us where stumbling blocks are still hiding, and what we need to improve to smooth out the path.

Conclusion

Mistakes happen—c’est la vie. Ideally though, we should aim to avoid most of the tripping hazards that delay so many users from filling out forms on a portable device. Similar to an uneventful stroll on the pavement, the smoother the path is to the destination, the more likely users will complete the journey. Easy orientation, no detours, clarity, and a little bit of guidance are a traveler’s best friends. And experience shows that the further users get before stumbling upon an error, the more likely they will put extra effort into completing the task.

Ultimately, other stumbling blocks may exist apart from the ones I discussed. So try to connect your analytics to the activity on the pages to find out where people drop out of the process. This will show where stumbling blocks may exist and help to remove one block after the other to ensure the user the smoothest journey.

(jvb)

© Robert Brauer for Smashing Magazine, 2012.