Forms: The Complete Guide–Part 2

Written by: Martin Polley

Forms are one of the most important parts of any site or app—they are the most common way for our users to give us the information that we need to help them do what they want to do.

But in many instances, we design forms statically, often as wireframes. But so often, what makes or breaks a form is what it’s like to interact with it. When the user clicks on a particular radio button, some additional inputs appear. How does that happen? More importantly, does the user understand what just happened?

Things like this are next to impossible to explore using static deliverables. But with a prototype of a form, it’s easy. And with a prototype form made in HTML, you can make it look and behave exactly like the real thing. Which means that once you’ve validated it with users, you can be sure that it can be implemented so that the appearance and feel are just the same.

This series does not try to explain what your form should contain, how the fields should be grouped and laid out, where to put primary and secondary buttons, and so on. There are lots of great resources out there that do that already. (Like Luke’s and Caroline and Gerry’s books. Or Justin’s article.)

No. What this series does is give you the how. You’ve already figured out what you think your form should contain and how it should behave. These posts will give you everything you need to know to make a prototype of your form in HTML, something that looks, works, and feels like the real thing. Which you can then use for usability testing, for getting stakeholder buy-in, and as a living specification for developers.

In the first post in this series, I showed you how to lay out a form and align the labels the way you want, using HTML and Foundation.

In this post, I’ll show you the different types of inputs available to you and how to use them.

To make the most of this post, I strongly encourage you to get your hands dirty by actually typing in the examples and then opening them in your browser to see how they look and work. From personal experience, this gets it into your brain, into your fingers, much better than just copying and pasting.

Input types

There are several different HTML elements that are used in forms. Buttons get their own element (<button>), as do drop-down lists (<select> and <option>), and multi-line text inputs (<textarea>).

But most form elements are the <input> element, with a type attribute that specifies what kind of input it is.

Let’s look at them one by one.

If you’re following along and actually typing this stuff in, you need to set up a new Foundation project, open up its index.html file, and delete all the sample content (see this post to find out how).

Then add an empty <form> element and the necessary Foundation layout elements.

Once you’ve got that set up, you can just add each example within the <fieldset> tags, after the <legend> element.

Note: In the code samples below, you’ll notice that all the <input> elements have both a name and an id. Why is this? It’s because you need the id to be able to identify individual HTML elements (to style them with CSS, etc.). But for a real form, you need name so that the data that gets sent to the server will be labeled correctly. These aren’t proper forms, they’re just prototypes. But it’s good to do it properly from the start. So the rule of thumb is: for <input>s, use both id and name, and give them both the same value. (An exception is radio buttons—I explain why they’re different below.)

Text and its variants

Text

Type some text

An <input> of type text is just a simple input field. There are no restrictions on what the user can type in it (though there are attributes that you can add to do things like limit the length of the field’s contents—see below).

Password

Password

An <input> of type password behaves exactly the same as a text input, except that whatever you type in it is obscured.

Email

Email address

An <input> of type email is the same as a text input, except that on phones and tablets, the keyboard that is displayed has @ and dot keys as standard—you don’t have to go digging for them:

Keyboard displayed based on attribute
Keyboard displayed based on attribute

It also gives you validation for free. If you enter something other than a valid email address and then submit the form, the browser will do something like this:

Invalid email address notification

(This is true for desktop browsers anyway. Most mobile browsers don’t do this yet.)

URL

URL

The url <input> type is similar to email, except here you get a keyboard layout with slash and dot keys (and maybe others, such as .com).

Keyboard displayed based on attribute
Keyboard displayed based on attribute

Again, desktop browsers validate these automatically:

Invalid URL

Phone number

Phone number

The tel <input> type, as we saw in the previous post, gives you a phone keypad on smartphones:

Keyboard displayed based on attribute
Keyboard displayed based on attribute

Number

Number

The number <input> type doesn’t restrict what you can type, but on smartphones (the iPhone, at least), you get the regular keyboard, switched to numbers-and-symbols mode:

Keyboard displayed based on attribute
Keyboard displayed based on attribute

Different desktop browsers render this input differently. In IE and Firefox, it looks the same as a text input, but in Chrome and Safari, it gets spinner controls for increasing and decreasing the value:

Spinner

You can set minimum and/or maximum values, and a step size. These affect the behavior of those spinner controls.

Autosuggest

Empty:

Empty autosuggest

Typing:

Autosuggest while typing

You can use an <input> with a list attribute paired with a <datalist> element to get something that is kind of a cross between a text input and a drop-down list. As you type in the input, a dropdown list shows you matching options. You can click on an option or use the arrow keys and Enter to select.

Other types

There are a number of other <input> types that were introduced with HTML5, but most of them are not widely supported yet. These include color and various date and time inputs, such as date, time, datetime, datetime-local, week, and month.

For now, you’re better off using things like the jQuery Datepicker.

The rest

Checkboxes

Checkboxes

If you give an <input> a type of checkbox, you get a checkbox. These usually have their label to the right. For checkboxes, the for attribute is particularly important—it makes the label clickable—clicking it is just like clicking the checkbox itself. Adding the checked attribute (which doesn’t take an argument) makes the checkbox checked when the page loads. For a prototype it doesn’t really matter, but a checkbox in a real form must have a value attribute.

Radio buttons

Radio buttons

Like checkboxes, with <input>s of type radio, the label usually comes after the input. And for and checked work the same here too. Here though, be sure to give all the radio buttons in a group the same name attribute—this tells the browser that they belong together, and that only one can be selected at a time. Again, like with checkboxes, every radio button must have a value.

Sliders

Sliders

An <input> of type range gives you a slider. Like with number, you can specify a minimum, maximum, and step values. But this control is not hugely useful on its own—if precision is not an issue, you can probably get away with just adding text before and after the <input> to show the maximum and minimum values. But in most cases, you’ll probably want to provide some sort of feedback so the user knows what value they have selected.

This is not difficult. It requires a tiny bit of Javascript, but you’ll see in a minute that it’s really no big deal. We just need to take the existing bit of HTML and add an <output> element to show the value. And we add an oninput attribute to the <input> to tell it what to do when its value changes.

In this version, the <input> and <output> elements are in separate columns, and I’ve given the <input> a width of 100% so it will stretch to fill its column:

Slider with indicator

The little bit of Javascript that is the value of oninput just sets the value of the output (range_value.value) to the value of the input (range_input.value). (range_value is the <output>‘s ID, and range_input is the <input>‘s ID. Adding the dot and value just means “the value of the value attribute of the element with this ID.”)

Drop-down lists

Closed:

Closed dropdown list

Open:

Open dropdown list

Drop-down lists are not <input> elements—they are made up of a <select> element containing a number of <option> elements.

This is fairly straightforward. One thing I’ve added here though is the first <option>—it prompts the user what to do, but is not actually an option they can select. (The selected attribute means it is what is displayed in the closed dropdown before the user interacts with it.)

Without this option, “Option 1” would be selected by default. Usually we don’t want anything to be selected by default.

Textareas

Textarea

A <textarea> is like a text <input>, except it lets you enter multiple lines of text. Like all the text-like <input>s, its width is 100% of the column that it’s in.

As for height, there are two ways to set this. One way is to set the height in CSS (or directly on the element by adding a style attribute). The other way is to use the rows attribute, like I’m doing here. This makes the <textarea> tall enough to fit six lines of text.

(The style="height: auto;" attribute is to get around a bug in Foundation. If you set the height to a specific value instead of using rows, you won’t need this.)

Buttons

Buttons

Most forms have buttons that you have to click to send the information you’ve entered to the server. Some also have a button for a secondary action, to cancel out or to reset the form (though some argue that such secondary actions are usually a bad idea).

Here, the buttons are <input>s of type submit and button. (submit is a special kind of button for submitting a form.) The right place to put these is after the closing </fieldset> tag.

The Submit button gets a class of button to make it into a nice-looking Foundation button, while the Cancel button also gets a class of secondary to make it visually less prominent.

Foundation also lets you use the <a> element for making buttons—just give it a class of button. It also lets you do stuff like make buttons smaller, give them rounded corners, and so on, just by adding classes.

Other clever Foundation stuff

Foundation lets you do some clever things that the standard HTML elements don’t let you do.

For example, you can combine an input with a label to get something like this:

Input and label

You can see the code for that here.

You can also combine an input with a button to get this:

Input with button

The code for that one is here.

Important attributes

I mentioned a few attributes along the way, like id and name, checked for checkboxes and radio buttons, min, max, and step for number and range type inputs, and so on. But there are some others that you need to know about.

autocomplete

Browsers try to help us by automatically filling in form fields for us when they can. But sometimes this is not appropriate, for example, for sensitive information such as bank account and credit card numbers (and even passwords in certain cases, though beware of being annoying with this one).

Setting autocomplete to off for an input tells the browser not to fill it in automatically.

autofocus

On each page, you can give one (and only one) form control the autofocus attribute. This field will get focus when the page loads, so the user can start interacting with it without having to click in it or tab to it.

disabled

Disabled

A control with the disabled attribute gets greyed out and you can’t interact with it. This may be because it’s not relevant unless some other control has a particular value. (For example, if your form has a “How did you hear about us” section with radio buttons, the last one might be “Other”, with a text input so the user can type something that’s not in your list. It makes sense to make this input disabled unless “Other” is selected. I’ll cover this sort of thing in more depth in a subsequent post.)

maxlength

Text-type inputs (text, email, url, tel, etc.) can have a maxlength attribute. This lets you specify the maximum length in characters. Most browsers won’t let you type any more once you hit the limit. This is handy for things like phone numbers, which can’t be longer than a certain number of digits.

multiple

The <select> element and <input>s of type email (also of type file, for uploading files, which I haven’t covered here) can take the multiple attribute. This lets you select multiple items in a dropdown or specify multiple email addresses, respectively.

Select multiple

Notice how the <select> is displayed differently when multiple selection is enabled.

pattern

pattern tells the browser what an acceptable value looks like. I’ll cover this in a subsequent post when I talk about validation.

placeholder

Placeholder

The placeholder attribute puts hint text inside the <input> (or <textarea>), to give the user an idea of what they need to type. It disappears when you click in the <input>. Some sites use it to indicate which fields are mandatory and which are optional.

IMPORTANT: Do NOT use this instead of a <label>. It is very bad from both accessibility and usability points of view.

required

The required attribute means that a field is mandatory. It doesn’t change its appearance (an asterisk doesn’t magically appear next to its label), but if you submit the form without filling it in, you’ll get a helpful message:

Required field

tabindex

The tabindex attribute (which has a numerical value) determines the order in which controls get focus when the user presses the Tab key.

If you’re doing something weird with your form layout such that the inputs are in a different order on the screen than in the page source, you should use the tabindex attribute to make sure that focus jumps to the right input when the user tabs between them.

Special considerations

On phones and tablets, there are additional challenges that we face. How often have you come to sign in or register at a site on your phone and seen something like this?

Autocorrect fail

On m.hpdirect.com, as I’m typing in the User ID field in the login form, my phone is automatically capitalizing the first letter and wants to correct what I’m typing to words it has in its dictionary. So now I have to tap the little “x” to dismiss autocorrect, and go back and change the capital “M” to a lowercase one. Grrr.

For fields like this, there are two attributes that we can add to turn off this antisocial behavior: autocorrect and autocapitalize.

They both take the same values: on and off. By default, they are on.

Conclusion

Hopefully you now have a pretty good idea of the building blocks that you can use to create your prototype forms.

In the next post, I’ll show you how to group inputs into logical (and less overwhelming-looking) groups and how to provide help to users while they are filling in the form.

Managing Website Accounts in Cross-Platform Contexts

Written by: Will Hacker

So you want to extend your website’s account management features to mobile devices. Well you’re not alone; most major websites today have cross-platform accounts and profiles that make for a more engaging and cohesive user experience. And many sites enable account management features on mobile devices.

After all, you want people to be able to interact with your product or service whenever and wherever. The trick is knowing which features to add to the mobile account management experience. Devices and use contexts are not created equally, so you need to consider how people want to use your product in the mobile context before enabling account management features.

Accounts provide a lot of value for website visitors. They allow people to save address and payment information on ecommerce sites, airport and airline preferences on travel sites, and topical preferences on news sites. They help reduce friction when completing tasks.

In this article, and in general, an “account” refers to a set of features that allow transactions of all types and requires a person to sign in to manage it. “Profiles,” on the other hand, refer to publically exposed information about a person that can be seen by other people.

The challenge for experience designers is figuring out which of the many settings that can be part of an account should be made available on all platforms. There is no easy one-size-fits-all answer because user needs and use contexts vary from site to site.

For the purpose of this article I’m using the term “mobile” to refer to websites and native apps used on smartphones, which, in addition to the unpredictable cellular networks and often clumsy touchscreens that impact designing for tablets, have the added challenge of reduced screen size.

It’s easy for website accounts to get bloated. And while it’s common to add features for the traditional desktop user, an account can quickly become a confusing experience for someone trying to complete a simple task on a handheld device.

Context is king

When making account management mobile ready, you have to understand the main tasks someone is going to want to complete on their smartphone. This is usually accomplished by research, which can take the form of interviews, contextual inquiry, participatory design, or exploring web analytics. As you flesh out your mobile identity management strategy, start with these tasks first and only consider additional ones later.

Accounts should not be required

One of the cardinal rules of mobile design is that people should not be required to have an account to use your site or app. Greg Nudelman covers this design tenet very well in his article on the sign-in/sign-up antipattern.

Obviously, signing in is required for financial services and other applications that grant access to personal information. But an airline site or app should not require an account to check flight status or get basic gate information, and hotels should allow people to access property information and room availability without signing in.

American Airlines provides a lot of functionality in its iPhone app for people who are not signed in.
Figure 1. American Airlines provides a lot of functionality in its iPhone app for people who are not signed in.

There are exceptions to this rule, of course. Facebook, for example, loses a lot of its value if you haven’t signed in, although it still makes some of its vast amount of profile data available to searchers to the extent that users have allowed that information to be made “public.” Even for sites that require people to sign in for certain information and functionality–which Mint.com does–access to general information like blog posts and commentary should be provided in a mobile friendly format to users of their native apps–which Mint.com does not do. Since all the major mobile platforms have web viewing features built into their native app libraries, Mint should make its existing mobile friendly web content available to both website users and people using their native apps.

American Airlines, on the other hand, provides a lot of content and functionality for anonymous users of its iPhone app, as shown in Figure 1.

Streamline account creation

If you are going to allow your mobile users to create accounts, try to ask for as little information as possible. Your goal should be to reduce interaction cost and get the person’s account created with as little effort as possible.

You can see this approach by comparing the mobile and desktop versions of TripAdvisor’s website, as shown in Figure 2.

TripAdvisor’s mobile profile-creation screen (left) asks for four pieces of information, compared to six on its desktop version (right).
Figure 2. TripAdvisor’s mobile profile-creation screen (left) asks for four pieces of information, compared to six on its desktop version (right).

On the desktop version of its profile-creation form, TripAdvisor asks for additional information–first and last name–not requested in the mobile version.

TripAdvisor could have streamlined its mobile profile-creation screen even further by not asking the user to create a screen name until after they create the profile, or even deferring it until the user wants to create or share content for the first time. They also should have considered if a user really needs a screen name if all they want to do is save hotels and other destinations.

Using device features to enrich the experience

TripAdvisor also could have used geolocation to try and set a default value for the current city or, better still, left that until after profile creation. Native mobile apps, unlike websites, can take advantage of a lot of device features that can benefit people by streamlining activities. When you sign into Foursquare, you are asked if you want to connect to friends via your mobile address book or social media networks (if you connected the accounts). For someone working on the small screen, this is a big time saver and helps apps like Foursquare and Twitter build their networks.

Simplify account and profile management

TripAdvisor provides a limited set of functionality for managing a user profile on a mobile device (left) compared to many more options people can manage on the desktop version of the site (right).
Figure 3. TripAdvisor provides a limited set of functionality for managing a user profile on a mobile device (left) compared to many more options people can manage on the desktop version of the site (right).

TripAdvisor also provides a good example of exposing enough account settings on a mobile device to make its site useful without filling it up with settings unconnected to task completion in a mobile context.

As shown in Figure 3, TripAdvisor allows mobile users to modify basic settings like choosing their country and preferred currency. These profile settings would be useful in a mobile context if the user is an American reading hotel reviews in London and wants to see the nearby properties and their nightly rates in British pounds.

TripAdvisor offers many more profile settings for desktop users to manage, including the ability to list the types of activities they like and other information about an individual’s personal travel style.

Allow password reset

Instagram users can reset their password using only the app and email or by using a Facebook login (left). The Instagram password reset email takes users to a simple screen where they can create a new password (right).
Figure 4. Instagram users can reset their password using only the app and email or by using a Facebook login (left). The Instagram password reset email takes users to a simple screen where they can create a new password (right).

Resetting a password is a must for mobile products. Someone who has forgotten their password may not be able to wait until they are at a desktop computer to get into a given website. This functionality should be supported in all mobile user accounts and profiles, whether the product is a mobile-only app like Foursquare or the mobile version of a cross-platform website like Amazon.

Instagram provides a good example of this, as shown in Figure 4.

Social media and user accounts

Foursquare allows users to connect to Facebook and Twitter through its account.
Figure 5. Foursquare allows users to connect to Facebook and Twitter through its account.

Allowing someone to connect to a social media account is a great example of functionality you should include in your mobile account.

Foursquare, for example, allows users to connect their app to Twitter and Facebook accounts so check-ins can be shared to those platforms, as shown in Figure 5. It makes sense to include this in the mobile context, not only because Foursquare is a mobile-only experience but also because it allows the in-the-moment sharing of information to social media that is one of the great appeals of smartphones.

Fatal operations on a mobile device

Facebook allows users to deactivate accounts from its iPhone app, but requires the user to re-enter their password to prevent accidental deactivation.
Figure 6. Facebook allows users to deactivate accounts from its iPhone app, but requires the user to re-enter their password to prevent accidental deactivation.

Experience designers also need to be conscious of adding what I call “fatal operations” to a mobile account. Fatal operations are things that cannot be undone and can have serious consequences, such as deleting a shopping cart or an entire account.

Facebook provides a good example of how to handle this type of situation. On its desktop site, a user can deactivate or permanently delete their account. But in its mobile apps, users can only deactivate their account.

Google’s Gmail app for iPhone allows users to recover an email that was just deleted from their inbox.
Figure 7. Google’s Gmail app for iPhone allows users to recover an email that was just deleted from their inbox.

And Facebook requires the user to re-enter their password before performing the deactivation, as shown in Figure 6, making it less likely a user will deactivate an account by mistake.

Another approach could be to have an “undo” button available for a brief period after a user performs a fatal operation, like Google does when users delete email messages in its Gmail app, as shown in Figure 7.

Amazon takes a similar approach when a user deletes an item from the cart in its mobile apps, as shown in Figure 8.

Conclusion

Accounts are an essential part of digital products that tie individual uses and activities together into a more cohesive overall experiences. They are even more valuable when those experiences are shared across platforms and devices.

Amazon provides an “Undo” link after a user deletes an item from their shopping cart.
Figure 8. Amazon provides an “Undo” link after a user deletes an item from their shopping cart.

The challenge for us as experience designers is to know what parts of account and profile management should be enabled on mobile devices and what ones are best left for the desktop experience.

There’s no easy answer to this, and like many aspects of experience design, this is where research and knowledge of our users is essential. If you are adding a feature to a mobile experience, consider whether the feature will make the experience more enriching or more confusing–and think about how to mitigate the negative consequences of someone making a mistake.

Guerrilla Usability at Conferences

Written by: Nick Cawthon

Does your company have display booths at trade shows and conferences? Typically, these are marketing-dominated efforts, but if you make the case to travel, working the booth can be used for user research. Here’s how I’ve done it.

Positioning and justification

At times it can be a hard internal sell to justify the costs and diversions to take your one- or two-person show on the road, all the while piggybacking off of another department’s efforts. Yet, standing on your feet for 12 hours a day doubles as a high-intensity, ‘product booth-camp.’ Say what you will about sales folk, but they are well trained on knowing how to (or finding someone who can) answer any question that comes their way. As an in-house UX professional, the more I can technically understand about our SaaS product, the more context I can have about our user’s needs.

I’ve found that having prospective customers participate in a usability session is a great way to show that we were taking the time to invest in them and their opinions of the product. As a result, there have been specific features that have been rolled into our application during the next sprint, which were proposed as small sound bites of feedback during these sessions. It shows we were listening, and makes a great justification for a follow-up phone call.

Recruiting and screening

To recruit, I scan Twitter to find those who tweet that they are excited about attending the upcoming conference. I cross-reference the Twitter handles to the names in LinkedIn to see if, based on job title and industry, they would be good participants.

I reach out to them to see if they’d be willing to sign up for a slot, proposing times between presentation sessions or before/after lunch to not conflict with their conference attendance.

Because the expo halls are generally open the entire day, even if there is no one booked on the calendar in specific spots, I also grab people just milling about to keep the sessions going. If you do this, be sure to quickly do a visual scan of their badge, as you can get a good sense of what they do and what knowledge they might have by where they work.

Booking

For the time bookings, I find that Calendly.com is a flexible, free, user-friendly way to book time slots with random people, using just a URL with no account sign-ups needed. In addition to custom time buckets (18 minutes, anyone?), Calendly also provides the option of a buffer increment after every session, so I can take notes and regroup.

Screen shot of a calendar with appointments booked.
Pick a time, (most) anytime.

Calendly does a good job of reminding participants when to show up and how find me–all the important things, including integrating well with all the major calendaring applications.

Come conference time, I have a slate of appointments along with contact information and reminders when they were coming. Couldn’t be easier. If expo hall hours change, I can easily message participants to let them know of the reschedule.

Duration

In a normal, controlled setting, I would typically want to go a full hour with a participant to properly delve into the subject matter and go through a number of different tasks and scenarios. “Pick a few and grade on a curve,” as Neilsen once said.

However, with the participant’s attention scattered given the sensory overload of the conference floor, anything more than 20 minutes gets to feel too long. At conferences, you’re going for quantity over quality. An advantage to this staccato method is when you find a vein of usability that you want to continue to explore in further depth and detail, there’s likely another participant right around the corner (either scheduled or random) to confirm or refute that notion.

Script and tone

The main challenge of this technique is that you’re not supposed to ‘sell’ in the role of testing moderator but rather to guide and respond. I wear many hats when working a booth; when not conducting these sessions, I sell the product alongside marketing.

As a result, 90% of the conversations in the booth are indeed sales, and switching roles so quickly is sometimes hard. I try to check myself when the testing script bleeds into ‘did you know that there are these features…’, because after 3+ days and what feels like a thousand conversations, I tend to put my conversations on a programmed sales loop, letting my brain rest a bit by going off of a script.

A pre-written task list helps keep me on point as a moderator. However, with the variety in participant group, I use the script much more as a guide than a mandate.

As with any usability session, I let the participants veer into whatever area of the app interest them the most and try to bring them back to the main road ever so subtly. With so many participants in such a short period of time, sometimes these unintended diversions became part of the next participant’s testing script, as it is easy to quickly validate or refute any prior assumptions.

Tools

Following the ‘guerrilla gorilla’ theme of this article, I use Silverback for my recording sessions. Silverback is a lightweight UX research tool that is low cost and works very well.

At one event, without my Bluetooth remote to use Silverback’s built-in marker/highlights, I paired an iPhone with an app called HippoRemote. Meant initially to provide ‘layback’ DVR/TV functionality, Hippo can also be written with custom macros to allow you to develop third-party libraries.

In the case of integrating with Silverback, this meant Hippo marked the start of new tasks, highlights of sound bytes, and starting/stopping recording–all the things that the Apple Remote should have done natively.

Despite some of the challenges in peripherals, Silverback is absolutely the right tool for the job. It’s lightweight, organized, and marks tasks and highlights efficiently.

Screen grab of the Silverback UI
Silverback UI

I recommend a clip-on microphone or directional mic given the background noise from the conference floor. Any kind of isolation that you can do for the participant’s voice will save you time in the long run, because you won’t have to try to scrub the audio in post-processing. Moving the sessions to somewhere quiet is a hard proposition, as the center of activity is where the impromptu recruitment tends to occur.

Wi-Fi

As a data-intensive SaaS product, the biggest challenge comes when trying to use the conference wi-fi. With the attendees swamping access points, there is no guarantee that I can pair the testing laptop and the iPhone used for marking, because they both need to be on the same network router for integration with with Silverback.

An ad-hoc network for the Mac won’t work, because I still need web access to use the application. Using my mobile phone as an access point has bandwidth constraints, and choppy downloads are not a good reflection on the speed of our application.

Unfortunately, then, every session begins with an apology on how slow the application is performing due to the shared conference wi-fi. A high-speed, private access point or a hardline into your booth cures all of these issues and would be worth the temporary investment for sales demonstrations and usability sessions alike.

Summary

There are a few adaptations we, as usability professionals, have to make from a traditional sit-down, two-sided-glass setting. Conference booth testing is a much more informal process, with an emphasis on improvisation and repetition. Some of the tools and methods used in guerilla testing certainly are not as proven or stable, but the potential recruitment numbers outweighs the inconveniences of a non-controlled setting.

From an educational standpoint, being inside the booth for days at a time will raise your knowledge-level considerably. You’ll hear again and again the type of questions and responsive dialog that prospective customers have around the product, and you’ll start to recognize the pain points coming from the industry.

After a half-dozen conferences, you’ll start to understand the differences in the average participant. In the case of the technology-centric attendees, some conferences provide a recruitment base of high-level generalists, with others being much executionally closer to the ground and detail-oriented. I tend to tailor my scripts accordingly, focusing on principles and concepts with the generalists, and accomplishment of specific tasks with the more programmatic participant.

One good thing about working for Loggly o’er here in the startup world is the ability to create paths and practices where there were none before. Pairing with the marketing team, using a portion of the presentation table to recruit participants off the expo hall floor, and sitting them down for a quick walkthrough of the product is a great way to become inspired about what you do and who you’re working for. As someone who still gets excited to travel, meet new people, and play off crowds, these sessions are always a highlight for me to conduct guerilla usability in front of my customers, peers, and my co-workers.

The Creative Impact of Improvisation

Written by: Amy Marquez

Improvisation is a very old and time-tested form of theater. The earliest use of improvisation is found in records of a Roman farce performed in 391 BC. Given its long history, it’s surprising to me that in our modern world, comedy–and comedic improvisation–is considered a low-brow form of entertainment. It is generally eschewed by the erudite. But it shouldn’t be.

My own experience with improvisation spans 20+ years. And in the middle of that I took a hiatus from performing when my husband and I started a family. For four years, I did no improv. And my brain seemed to stutter to a screeching halt. I felt dull and less energetic. Creativity started taking more effort than it had previously. I felt like I was on autopilot. But I chalked that up to being a new, perpetually sleep-deprived parent. I’m sure that sleep deprivation didn’t help, but at the time I didn’t even realize what the real problem was.

Ramping up my brain

When I first came back to improv from that break, I felt like my brain was having to wade through mud to get ideas out. I looked at my fellow troupe members and marveled at how quickly they could craft a scene or throw out ideas. But after a couple of months with the troupe, my thoughts moved much more quickly. I could keep up with the rest of my team, and I suddenly felt so much more alive than I had in years.

I noticed something else. My creative process at work started to go into overdrive. I was able to generate, dismiss, or accept design ideas very quickly. It was much easier to do collaborative creative brainstorming and get dozens of ideas out because my thought processes had become accustomed to it. I felt like my mental Rolodex (here’s a link for the young whippersnappers who have no idea what a Rolodex is) was stuffed with ideas and was spinning impossibly fast; ideas were flying.

It was a wonderful feeling–like moving out of the fog into the sunlight.

The science behind creativity

I decided to do some research on this, and as it turns out, this isn’t just a fluke, it’s a proven scientific method of improving brain function.

Dr. Charles Limb, a Johns Hopkins University neuroscientist, has dedicated his research to the art of improvisation and how it increases creativity. He has a fascinating TED Talk on the topic. His studies focus on jazz piano improvisation, and he demonstrates that the same increase in creativity is seen when the subject is improvising while rapping.

A post by self-proclaimed “biohacker” Dave Asprey about Limb’s studies summed up what was found to occur in the brain while improvising:

“During improvisation, the self-monitoring part of the brain (lateral prefrontal for you brain hardware hackers out there) deactivated, while the self-expression part of the brain got activated (medial prefrontal). Literally, that means that to be creative, you have to stop picking on yourself while boosting your self-expression abilities.”

Turn off your filters

If there is one thing you get practice doing in improv, it’s in turning off your brain’s filters. In improv, there are no bad ideas, you don’t hesitate on an impulse–you must charge forward with the scene and be fearless about making mistakes.

Applying the same principles in creative work comes more naturally once your brain is trained to do it in an improvisational setting.

So how can you bring this into your own work when you don’t perform improv on a regular basis? Bring the improvisation to your team. There are simple exercises you can do in a team setting that will help break down the voice of doubt and hesitation.

You can begin very simply so that your team becomes accustomed to the idea of improvising. If the idea of finding extra time to do this is daunting, take advantage of weekly meetings (like staff meetings). Set aside one of those meetings a month to do improvisational exercises.

The pep talk

Make it clear to your team that this is an activity where mistakes are expected and even welcome. This is a safe environment for them to be silly…because when everyone looks silly, no one looks silly.

Tell them not to overthink reactions and to act spontaneously. That means listen to what the other players are saying without trying to formulate a response before they’re finished. This forces the players to practice some of the key elements of active listening.

You’ll also want to review some of the basic rules of improv with the team.

Warm up exercises

Keep in mind that in all of these games, there needs to be a coach. Someone directing the team members in what to do. The coach can participate in the warm up exercises, but there are some structures that require a “director” and the coach should fulfill that role.

  1. To get your team engaged, start with an alphabet challenge. There are many names this particular structure goes by, so I’ll leave it up to you to call it what you’d like.

    Instructions
    Have the team stand in a circle.
    Decide who goes first.
    The first person starts by saying a word that starts with the letter “A”, and points at another player.
    The second player must quickly say a word that starts with the letter “B”, and point at another player.
    Repeat this until the team has gone through the entire alphabet.

    This is a simple game, but it primes the brain and gets everyone on the same footing.

  2. A more complex warm up exercise is called “What are you doing?”

    Instructions
    Have the team stand in a line.
    The first player steps forward and begins miming a simple action. (Example: buttering bread.)
    The second player steps forward and observes the first, then asks “What are you doing?”
    The first player responds with something completely different than the action they are miming. (Example: “I’m climbing a mountain.”)
    The second player begins to mime the action the first player said–climbing a mountain in this case.
    The first player steps back to where they were in the line.
    The third player steps forward, looks at what the second player is miming and asks “What are you doing?”
    Repeat the steps above until all of the team members have had a chance to participate.

Intermediate structures/scenes

Once everyone is comfortable with the warm-up exercises, you can move on to some more complex interactions. These involve a handful of participants and the rest of the team act as the audience.

  1. This first scene is called Oracle. It requires three players to act as one entity. It also requires a “handler.” The handler should introduce the all-knowing and powerful Oracle, who can answer any question.

    Instructions
    Have the three players sit one in front of the other at different levels–one on the floor, one on a chair, and one either standing or on a bar-height stool.
    The handler introduces the Oracle and asks if anyone has a question for the all-knowing Oracle. If there is hesitation to ask a question, the handler can suggest a topic.
    (Example: “Today the Oracle will answer all of your questions about bacon. What would you like to know about bacon?”)
    The players answer in order with only one word each. Each player has to build on the word that the player before them said.
    Once that question is answered, the handle asks the audience for another question.

    Example:
    Audience Member: Oracle, why is bacon so good?
    Player 1: Bacon
    Player 2: is
    Player 3: good
    Player 1: because
    Player 2: it
    Player 3: is
    Player 1: bad.

    The players may want to prearrange a signal that their answer is over. Something physical like waving their arms or snapping would work well.

  2. Freeze tag is a structure that requires players to create a scene based on a physical pose. It takes a little more setup than the other scenes and works best when you have no more than six players at a time. Make sure the coach has a whistle for this one.

    Instructions
    The players stand in a line.
    The first two players step forward.
    If there is an “audience,” ask someone to volunteer to position the two players for the initial scene.
    (Positioning rules: The position should be socially acceptable, the position should obey the laws of gravity, and the two players need to be touching. It can be a little touch–like a finger to a finger–or it can be a lot of touch.)
    If there is no audience, the coach should tell the first two players to assume a position they would if they were playing a sport. The coach should pick a specific sport, and the same positioning rules apply.
    When the players are in position, the coach blows the whistle to start the scene.
    The players must build their scene based on the initial position, but should start moving out of that position as soon as possible.
    After about a minute, the coach should blow the whistle when the players are in an interesting position.
    When the whistle is blown, the players freeze.
    The next player in line approaches the frozen players, taps one of them on the back letting them know they can get back in line, and assumes that player’s position.
    The two players then start a completely different and unrelated scene based on the new position.
    Repeat until all of the players have rotated in and out at least twice.

For more improvisational warm-ups, games, and exercises, you can look through the Improv Encyclopedia.

Remember “Yes, and…”

This handful of exercises will get your team started and help break down mental barriers to creativity. The more you do this, the less they will second guess themselves. And remember to emphasize the king of all improv rules, “Yes, and….”

There is no faster way to kill the energy in a scene than when one player says “no” to another. Forward progress is the objective. If a player tells you that you’re making a documentary on unicorns, don’t say “No, we’re not, because unicorns don’t exist.” The response should be an affirmation and a continuation.

The Benefits of Play

I’m grateful that I took a break from improv while I was a new mom. Putting the focus on my family was the right thing for me to do. And the mental impact of quitting improv taught me valuable lesson. Coming back to it has fundamentally changed the importance I place on collaboration, creative play, pretending, and imagination, both at home and at work.
The National Institute for Play cites multiple research efforts which found that pretend play “remains key to innovation and creativity.” They state that play mixed with science begets transformation.
Whether at work, at home, or on the stage, because of my continued experiences with improvisation, I bring that sense of play with me. Not only does it make life more fun, it has also helped foster an early, more mature sense of humor in my children (now elementary school age) where wordplay, puns, and imagination are a part of everyday conversation. It has also put me on a first-name basis with the principal…but in a good way.

How to Breathe Life Into Personas

Written by: Barnabas Nagy

Personas are essential when you are working on a project and don’t know the target audience very well. For instance, not every designer has experience in fashion or banking. Creating a model of your target audience may help you and your stakeholders feel significantly more empathy for those people.

Personas can also help you get out of the mindset of thinking about users abstractly. “User” sounds like it does not refer to real people who have desires, concerns, past experiences. When real people use your app or website, they are there to reach their goals: to buy something, to research, to register for something they need, or to get information. How can we design something helpful for them without feeling empathy?

Thinking about users as “just users” is just plain harmful. Empathy for the real people who use the website or app, on the other hand, is essential. If we have empathy, we will not design something that would make these people feel trapped, cheated, or confused.

Humane personas

Using  personas enables us to feel more empathy by creating a life-like humans we want to make happy. The problem is, most personas are not designed to make the reader care about the person. Most of them look like dossiers: name, occupation, age, sex, some descriptive text, and a Google image search photo.  Why would anyone care about a persona that looks like a PowerPoint slide?

A usual, dossier-like persona.
A usual, dossier-like persona. Via Data Driven Personas

We should also always keep in mind that stakeholders are also “users.” We have to make our deliverables real easy for them to understand.

I wondered: What would make my personas more humane? The bullet-point personas really made me feel ashamed as a designer. I was sure that these deliverables would not reach their desired goal which is to put me and my stakeholders into the mind of the people who use their web site. So why do them that way?

Making life-like personas

I started to look for a solution. As a good UX designer should,  I did some Google searching, sketched, and then fleshed it out. I went through many versions until I found one I was happy with, and response from project teams seems to be positive. I think these deliverables can be developed further, though. I call the result the Humane Speech Bubble Persona.

Where a traditional persona would list attributes in bullet points, I had the persona tell his own story, in speech bubbles.

The author's proposed humanized speech bubble persona.
What would make my personas human? I made some concepts, researched, tested, and refined again.

The key bubble is the worldview. It represents  the central attribute that tells us who our person is, summarizing the person in a single bubble.

Worldview speech bubble
Worldview speech bubble

Then I added bubbles with attributes like “motivation,” “looking for…,” and “desired experience,“ which help us focus on the goals of the person. Adding the opposite of these, such as “demotivation,” “not looking for,” and “last experience,” is also beneficial. Finally, I added the persona’s questions. This helps us focus on the needs and concerns of the user.

The unsolicited insight that comes from an overheard conversation means you get useful information that wasn’t meant for you. The bubbles recreate that experience for the users of the persona.

Presenting text attributes in speech bubbles make the persona humane as well. Speech bubbles show the person speaking, in easy-to-follow sound bites. This makes the persona scannable and adds some fun to the deliverable.

Finally, to make the persona more scannable and relatable, I added pictures from the persona’s imaginary life to help us visualize the persona as a human being. The pictures represent both current as well as desired objects that the persona cares about. As well, when personas are hanging on a far-off wall, they provide an easy way to remember who this persona is, and what he really cares about. No reading necessary!

Conclusion

Making personas humane not only benefits you, the UX designer, but your stakeholders as well. Adding flavor to deliverables does not take a lot of effort, so why not do it? A humane persona will help us feel empathy for the real people who will use our designs and will help stakeholders accept concepts readily.  Try out the Humane Speech Bubble Persona, and let me know what you think!

For some more insight how I made this persona template, read my article on my website.