Forms: The Complete Guide–Part 3

by:   |  Posted on

Forms are important—they’re the most common way to get information from our users. But just making wireframes of a form misses a big piece of the picture—what it’s like to interact with it. An HTML prototype of a form, on the other hand, can look and behave just like the real thing.

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

In the second post, I showed you all the different input types you can use.

In this post, I’ll show you how to group your inputs and how to provide help to the user while they’re filling out the form.

To make the most of these posts, I strongly encourage you to get your hands dirty. Type in the examples and then check them out in your browser. This gets it into your brain, and your fingers, more effectively than just copying and pasting (or worse, just reading).


When you’ve got more than just a few input fields, it makes sense to organize them into logical groups, which you then separate visually. This makes the form less intimidating. It looks more like several small forms than one long one.

Let’s make a shipping details form similar to the one we created in the first post. This time, in addition to the shipping address inputs, we’ll add an extra input for the user’s email address, and we’ll split the phone number and email address out into a separate group.

The most obvious way to do this would be to add a second <fieldset> with its own legend and put the phone and email inputs in there.

Let’s try it. In the index.html file of a new Foundation project (see this post to find out how to set that up), add this:

It’s OK, but the result looks a bit busy (view larger):

Form groups with borders

There’s just a bit too much to process here. We don’t need quite so many visual elements to separate the two groups. We could abandon <fieldset>s and replace the <legend>s with headings, but that would be semantically less correct. It would also affect the form’s accessibility.

A better approach would be to tweak the CSS a bit to reduce the visual clutter. Let’s create a new stylesheet and link it up from index.html.

So open up a new file in your text editor and add this CSS rule to it:

Call the file form.css and save it in the css folder. Then add this line to index.html:

How’s that? (View larger.)

Form groups: no borders

It’s certainly cleaner. We could leave it at that. Or we could do some other things to further emphasize the grouping.

For example, we could put a thin horizontal line (<hr/>) between the groups:

Form groups: horizontal rule

Or we could give each group a background color:

Form groups: background color

Whatever works for you.

Inline help

Sometimes it’s not 100% clear from a field’s label what the user is meant to enter in the field. Maybe it’s something that is simply too long to explain in a short label, so we need some additional text to help the user out.

A well known example is the credit card security code, which is often labeled as something not very helpful, like “CSC” or “CVV.” Even “security code” may not be obvious to some users, so we need to provide the user with an additional explanation somehow.

There are several approaches we can use:

  • We can have a big lump of explanatory text at the top of the form. These often get ignored though.
  • We can supplement the label with additional text (usually in a smaller font size) for fields that need it.
  • We can use the placeholder attribute to give the user an example of the type of information required and its format.
  • We can have some help text that appears automatically when a field (or one of a group of fields) gets focus.
  • We can put an icon next to the label that displays help text when the user clicks on it or hovers over it.

The first one is not usually a good idea, so we won’t bother with it. The second one is technically very easy to do, so we’ll skip that too. And we’ve already seen how to use placeholder.

So let’s tackle the last two.

Automatic inline help

Let’s say you’re designing a form that lets the user order a piece of clothing–a t-shirt, for example. They need to select a size, but you want to direct them to your sizing chart if they’re not sure. So for just this one field, we’re going to have a piece of help text that appears when the size control gets focus.

This is a bit like what eBay does on the password field on its registration form:

Inline help on eBay's registration form

(Actually, in a scenario like ours, it’s more likely that the “form” is just a couple of fields on a product page that allow the user to select size, color, and quantity.)

Our “form”: page structure

Let’s go ahead and build a prototype product page for our t-shirt. We’re going to make it look like this:

T-shirt product page sketch

It’s got a title (the name of the shirt) at the top. Under that, there’s a nice big photo, with additional photos that you can see by clicking the thumbnails on the left (though we’ll fake this part–it’s not important here). And to the right of the photo, we’ve got our form, consisting of inputs for choosing the color, size, and quantity, and an “Add to cart” button.

Only the size selector needs inline help, which we’re going to display to the right of the selector. But when do we we want the help to appear? I think it’s best if we show it both when the selector gets focus, and when the user moves the pointer in the general vicinity of the selector. That way, it will work well on both touch screens and when you’ve got a mouse and keyboard.

The first thing we need to do is get our basic page structure set up. Start out with an empty Foundation index.html file (refer to the instructions in this post for that).

Obviously, in a real design, you’re going to have global navigation, a footer, and all kinds of other stuff on the page. But here, we’re just prototyping the essentials.

For our title, we need a row <div> containing one column that takes up the whole of the available width. (Not the whole width of the page, but the usable area in the middle, which by default in Foundation has a maximum width of 1000 pixels, and which gets shrunk down and rearranged responsively for smaller screens).

To achieve this, we give the <div> containing the heading classes of small-12 and columns. This means that for screen sizes of small and above (i.e., all screen sizes), we want it to take up the whole of the available with (all twelve of the available twelve columns).

So we need to add this to our index.html, right after the opening <body> tag:

Next we need another row <div> that will contain the rest of the content. Within this, we need three column <div>s: one for the thumbnails, one for the big photo, and one for the form:

Here, I’m using to generate placeholder images, instead of using real images. (They have instructions over there that explain how to size the image, how to change the text, and so on.)

Here, the small- classes divide up the twelve available columns into three, with widths of one, five, and six columns respectively (for all screen sizes). The <div> for the form is empty at the moment, so we can’t see anything there yet:

T-shirt product page WIP 1

Things look a bit scrunched up, so let’s add a bit of white space. In the last post, I showed you how to put CSS rules in a separate file and link to it from index.html. But for the sake of speed, this time, we’re going to put the rule in a <style> block in the page’s <head>. Within the <head> tags, add this:

This just adds top and bottom margins to the title, and gives all the images a bottom margin.

The actual form

Now for the actual form part of the page. This is also going to need some structure. Because we want to position the inline help to the right of the size selector, what we need to do is divide the form up into four row <div>s: one for each control and its label, and one for the “Add to cart” button.

Within each row, we’ll divide the space up into two equal columns, one for the control, and one for the help (where needed). So let’s add this within that third, empty <div>:

Notice how each row has only one columns <div>, except the second one. This is where the size selector will go—it’s the only one that needs a column to contain the inline help. And the whole thing is enclosed in <form> tags, because, well, it’s a form.

But until we add the actual controls, we can’t see if it’s right. So let’s do that now. Add the <label>s, <select>s, <option>s, the <input>, and the <button> so it looks like this:

Nothing here that we haven’t seen before. (Except I’ve explicitly set the value of the quantity <input> to 1, a sensible default I think.)

And how does it look? So far, so good:

T-shirt product page WIP 2

This looks OK, but the form elements could use a bit of white space between them. So add this rule, again between the <style> tags in <head>:

This just adds bottom padding to each row. Now the only thing we need to add is the inline help itself. Oh, and there’s the little matter of making it appear and disappear when we want. We’ll get to that in a minute.

First let’s add the HTML. Inside that empty <div> (the one right after the size <select>), add this:

This uses Foundation’s panel and callout classes to style it, plus some inline styling to make it a bit more compact. (Any bigger, and it’ll make the row taller, which means things will jump around when we show and hide it.) It also has an aria-live attribute so that screen readers will be aware of the content when we make it suddenly appear on the screen.

This is how it looks now:

T-shirt product page WIP 3

Now we need to hide it, so we just add display: none; to the existing style attribute of the inner <div> (the one with the panel and callout classes), so it looks like this:

Next, we need to show it and hide it. The only way to do this is with JavaScript. This is more like “proper programming”, but don’t be put off by that—I’ll do my best to make it simple and easy to understand.

JavaScript: show help on focus

First, we need somewhere to put our JavaScript code. Normally, you would keep it in a separate file, so you can reuse it in multiple HTML pages. But for simplicity, we’ll add it in a <script> block at the bottom of the page, a bit like what we did with the CSS rules in the <style> block earlier.

Now, jQuery is included with Foundation, so that’s what we’ll be using here. All the code we’ll be writing will go inside jQuery’s $(document).ready() function. This means that whatever we put inside it will only get run once the page has loaded.

To start with, we’ll add some code that shows our inline help <div> when the size <select> gets focus. (This happens when the user clicks or tabs to it. Or when they tap on it on a touch device.) So add this <script> block at the bottom, right before the closing </body> tag:

Do not be alarmed! This may look a bit intimidating, but if we take it piece by piece, you’ll see there’s not a lot to it.

The <script> tags tell the browser that what’s inside is Javascript. The $(document).ready() function, as I explained, tells the browser to run the code inside it only after the page has loaded. The real meat here is what is between the curly braces (i.e., after $(document).ready(function(){ and before });).

Let’s look at the first bit:

$('.field_row input, .field_row select')

This says “Hey, jQuery, find any <input> or <select> that is a child of something with a class of field_row.”

jQuery uses the exact same selectors (and ways of combining them) as CSS. So that’s one less thing to learn. (I covered the very basics of CSS, among other things, in this post.)

So just like in CSS:

  • A period means it’s a class name. (.field_row means any element with a class of field_row.)
  • A hash (#) means it’s an element ID. (#size_selector means the element with the ID size_selector.)
  • Two selectors separate by a space means the second one must be a child of the first for the selector to apply. (div input means any <input> that is a child of a <div>.)
  • A comma means “or”. (input, select means any <input> or <select>.
  • You can combine selectors in other ways. For example, div.field_row means a <div> with a class of field_row.

OK, on to the next part:

.on('focus', function(){

This says “For whatever we just selected, do something when it gets focus.” on() is what’s called a function. A function is just a chunk of code that has a name that you can use to run it (to “call it”, in programming terms). (The period means “Call this function on the thing we selected.”)

on() looks out for an event, and does something when that event occurs. In this case, the event is focus. You can tell on() to look out for other events too, like click or mouseover.

Everything between the last (opening) curly brace after function() and the closing curly brace here:


is the code that actually gets run when on() detects that one of the selected elements has been given focus. That’s this line:


What this says is:

  1. Take the element that was clicked (this).
  2. Find its parent element. (In this case, the parent of the <input> or the <select> is the column <div> that contains it.)
  3. Find that element’s parent. (In this case, that’s the row <div> containing the <input>/<select>.)
  4. Within this element, find any element with a class of help. (That’s the inline help <div>.)
  5. Finally, show it.

This technique, where you call one function after another like this, is called chaining. It can save you a lot of work. (The alternative would be to store the element you get in step 2, then (step 3) call parent() on what you stored, then store that, and so on and so on.)


Now if you click on the size <select> (or tab to it), the inline help magically appears. But it doesn’t go away when the <select> loses focus.

JavaScript: hiding help when the selector loses focus

Luckily, to make this happen, we can just copy our existing code and make a couple of small changes. Copy the three lines of code (the ones that call on()), add a couple of blank lines below it, then paste them in. Now just change focus to blur and show to hide. The code you pasted in should now look like this:

If you try it now, you’ll see that when the <select> gets focus, the help appears, and when it loses focus, it disappears again. Great! But it’s not enough. Earlier we said we want the help to appear on hover as well. This isn’t a problem— a few more lines of code will do it. But where do we want the hover to work?

JavaScript: show help on hover too

Here, our help text contains a link (to a page that doesn’t exist, unless you feel like creating it). If the help appears when you hover over the <select>, when you go to click the link, it will disappear as soon as your pointer leaves the <select>. Which is not very nice.

We need to make the hover work for the element that contains both the <select> and the help, that is, the row <div>.

Let’s add some more code within our <script> block:

This time, the selector is simpler, because we’re just targeting the rows (that is, the <div>s with a class of field_row). (You may be wondering why I’m using this class, which applies to all four rows, instead of just sticking an ID on the one row that contains the help and use that here. The answer is that this way is more flexible—if I want to add help for another field later, I can just add it to the HTML and it will work, without having to change anything in the JavaScript.)

Instead of on() after the period, this time we’ve got a function called hover(). In contrast to on(), where we specified one piece of code that was run when the event was detected, here we need two: one that tells jQuery what to do when the hover begins, and one that tells it what to do when it ends. That’s why there are two function(){}s.

The code for hover start goes inside the curly braces in the first function(){}, while the hover end code goes in those of the second. To make things easier to read, lets split it up onto separate lines, like this:

Now we can just put the code that actually does stuff in those two blank lines. This code is going to be exactly the same as for the focus and blur events, except here, we don’t need those calls to parent() to navigate up from the field to the row <div>, because we’re already there. Add the necessary lines to make your code look like this:

If you try it now, you’ll see that hovering anywhere in the size row makes the help appear, and when you move away, it disappears. Yes!

Except what happens when the size <select> has focus, and then you hover and move away? No! The help disappears! That shouldn’t happen!

JavaScript: actually, don’t hide it when the hover ends, in this one specific case

What to do? Well, what we need to do is check if the <select> has focus before we hide the help (at the end of the hover)—and if it does have focus, we do nothing. For this, we’ll use JavaScript’s if construct. This lets us check if something is true, then do something. (And if it’s not true, we can either do nothing or do something different.)

Change your code so it looks like this:

What’s going on here? The only new thing here is that we’ve wrapped the line that hides the help in an if block. The line inside the block only gets executed if the bit in the parentheses after if is true. Let’s take a look at that expression:

!$(this).find('input, select').is(':focus')  

Ignore the exclamation point for a moment. this is the row <div>. Within this <div>, we’re using find() to get either the <input> or the <select>, and then we use the is() function (which checks if an element has certain attributes) to check if it has focus.

But this gives us an answer of “true” if the element does have focus. But we want to to hide it only if it doesn’t have focus. That’s where the exclamation point comes in. It means “not”, and simply reverses the result of the expression—true becomes false and false becomes true.

And now it works. (You can see it in action here.)

User-triggered inline help

You’ll be relieved to hear that user-triggered inline help is much easier to set up. All we need to do is take the prototype we just created and make a few changes (mostly removing stuff).

Adding an icon

First off, we need to add some kind of icon that the user can click or hover over to bring up the help. There is a set of Foundation icons that you can use just by adding one line to your page’s <head>:

Let’s add an “i-in-a-circle” icon to the “Size” label. Find it in your HTML and change it so it looks like this:

The fi-info class on the <i> element is how we specify which icon we want. (Other icons get fi-something-else, like fi-heart for a heart or fi-flag for a flag.)

The Foundation icons are an icon font. This means that you can style them just like text. You can make them bigger, change their color, add shadows, whatever. For now, we’re just making the icon a bit bigger, making sure it lines up with the label, and changing the pointer to a hand so that it looks clickable.

Note that the <i> can’t be inside <label> because clicking the label gives focus to the <select> (because of the for attribute that links the two). If we put the icon inside <label>, clicking it the same as clicking the label.

Also, we need to set the <label>’s display to inline-block (instead of the default of block) to force the label and the icon to stay on the same line.

New JavaScript for new behavior

Now, how do we want it to behave? If we make it so that the help only appears when you hover over the icon, then we’re in the same situation we would have been in if we’d made it appear when you hover on the <select>—when you go to click on the link in the help, it disappears before you can.

There are a couple of things we can do. We could introduce a delay, so that when the pointer moves away from the icon, the help does not disappear immediately. The other alternative is to make the help appear when you click on the icon, and have some way to dismiss it. Since we’ve already seen how to make things happen on hover, let’s go for the click-triggered help this time.

Within our $(document).ready(), we can get rid of all the code and replace it with this:

Here, we’re targeting the <i> element with a class of fi-info (our icon), and we’re telling the on() function to look out for click events on it. When it detects a click, we want it to start at this (the icon), go up two levels in the page hierarchy (by calling parent() twice), which takes us to the row <div>, and then call toggle() on it.

toggle() is rather clever. It hides the element if it’s visible, and shows it if it’s hidden. This means you don’t need to keep track of its visibility. So that’s less work for us. And it gives us a way to dismiss the help—you just click the icon again (which is nice and symmetrical).

User-triggered inline help

And that’s it. (See it for real here.)

Bonus learnings! Or I came for the forms, but stayed for the RWD

If you look at either of the above examples on your phone, you’ll see that it’s just the same thing, but squished down and misaligned. This is a bit of a shame. Foundation is a responsive front-end framework—we can use it to change the layout on smaller screens to something that makes better use of the available screen space.

Above, we used small- column classes for everything. This means that the defined layout is used for small, medium, and large screens. All we need to do is change the classes a bit to tell Foundation how the page should be laid out on smaller screens.

Here, we’re just going to have two layouts: one for small (phone-sized) screens, and one for medium (tablets) and large (desktop) screens.

In our small layout, what we really want is to just have everything stacked vertically: first the title, then the thumbnails, then the big picture, then the form. We can get this by just changing every small- class name to medium-. (What this means is that Foundation does something with the column widths we give it for medium and large screens, and treats it as if we didn’t specify any column widths at all on small screens—when you don’t specify column widths for elements, Foundation makes them full width and stacks them vertically.)

On smaller screens, that looks like this (code):

Responsive product page layout on a small screen 1

That’s pretty good, but I think it would look better if the thumbnails were below the big photo instead of above it. Foundation has classes you can add to make this happen.

The way you do it is like this. First, you change the order of the elements so that they appear correctly at small screen sizes. Then you add classes to move them left or right on larger screen sizes.

Let’s swap those two <div>s so they look like this:

Now we need to add push and pull classes to move these two columns to the left and right so that they are in the right positions for medium and large screens. Adding a push class pushes the column to the right, while a pull class pulls the column to the left.

We need to add the medium-push-1 class to the <div> that contains the big photo to push it one place to the right. This will leave the first column free for the thumbnails. Then we add the medium-pull-5 class to the <div> containing the thumbnails to pull it five places to the left, into the first column. This part of the code should now look like this:

Now if we look at it on a small screen (or shrink down our desktop browser window), we can see that the thumbnails are now below the big photo, just like we wanted (real example here):

Responsive product page layout on a small screen 2

And at larger screen sizes, the layout is just the same as before.


We’ve covered quite a lot of ground in this post. Stay tuned for the next post, where we’ll look at responsive enabling and responsive disclosure.

Forms: The Complete Guide–Part 2

by:   |  Posted on

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


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).



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


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.)



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



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:


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



Empty autosuggest


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



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.



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 dropdown list


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.



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.)



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.


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.


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.



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.)


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.


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 tells the browser what an acceptable value looks like. I’ll cover this in a subsequent post when I talk about validation.



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.


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


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, 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.


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

by:   |  Posted on

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 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 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.


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.

We Don’t Research. We Build.

by:   |  Posted on

The following is a composite of experiences I’ve had in the last year when talking with startups. Some dialog is paraphrased, some is verbatim, but I’ve tried to keep it as true as possible and not skew it towards anyone’s advantage or disadvantage.

As professionals in the user-centered design world, we are trained and inclined to think of product design as relying on a solid knowledge, frequently tested, of our potential users, their real-life needs and habits.

We’ve seen the return on investment in taking the time to observe users in their daily lives, in taking our ideas as hypotheses to be tested. But the founders and business people we often interview with have been trained in a different worldview, one in which their ideas are sprung fully formed like Athena from the brow of Zeus. This produces a tension when we come to demonstrate our value to their companies, their products, and their vision. We want to test; they want to build. Is there a way we can better talk and work together?

Most of my interactions with these startups were job interviews or consulting with an eye toward a more permanent position; the companies I spoke with ranged from “I’m a serial entrepreneur who wants to do something” to recent B-school grads in accelerator programs such as SkyDeck, to people I’ve met through networking events such as Hackers & Founders.

In these conversations, I tried to bring the good news of the value of user experience and user research but ran into a build-first mentality that not only depreciates the field but also sets the startup on a road to failure. Our questions of “What are the user needs?” are answered with “I know what I want.” We’re told to forget our processes and expertise and just build.

Can we? Should we? Or how can we make room for good UXD practices in this culture?

“I did the hard work of the idea; you just need to build it”

Over the past two years, I’ve been lucky to find enough academic research and contract work that I can afford to be picky about full-time employment (hinging on the mission and public-good component of potential employers). But self-education, the freelance “UX Team of One,” and Twitter conversations can’t really match the learning and practice potential of working with others, so I keep looking for full-time UX opportunities.

This has lately, by happenstance, meant startups in the San Francisco Bay area. So I’ve been talking to a lot of founders/want-to-be-founders/entrepreneurs (as they describe themselves).

But I keep running into the build-first mentality. And this is often a brick wall. I’m not saying I totally know best, but the disconnect in worldviews is a huge impediment to doing what I can, all of which I know can help a startup be better at its goals, so that it can have a fighting chance to be in that 10-20% that doesn’t end up on the dust heap of history.

“Build first” plays out with brutal regularity. The founders have an idea, which they see as the hard part; I’ve actually had people say, “You just need to implement my idea.” They have heard about something called “UX” but see user experience design as but a simple implementation of their idea.

As a result, the meaning of both the U and the X get glossed over.

The started-up startup

We’ll start with the amalgam of a startup that had already made it into an accelerator program. A round of funding, a web site, an iOS app, an origin story on (as you’d expect) TechCrunch.

It began with a proof of concept: A giant wall, Photoshopped onto a baseball stadium, of comments posted by the app’s users. The idea was basically to turn commercial spaces into the comments thread below any HuffPo story (granted, a way to place more advertising in front of people). The company was composed of the founder, fresh from B-school; a technical lead also just out of school; a few engineers; and sales/marketing, which was already pitching to companies.

The company was juggling both the mobile and web apps and shooting for feature-complete from the word Go. Though there were obvious issues, such as neither actually working and the lack of any existing comment walls or even any users; they were trying to build a house of cards with cards yet to be drawn.

In talking with the tech lead, I saw that they were aware of some issues (crashes, “it’s not elegant enough”) but didn’t see others (the web and mobile app having no consistent visual metaphors and interaction flows, typos, dead ends, and the like). To their credit, they wanted something better than what they had. Hence, hiring someone to do this “UX thing.” But what did they think UX was?

I had questions about the users. How did they differ from the customers–the locations that would host walls, which would generate revenue by serving ads to the users who posted comments?

I had questions about the company. What was their business process? What had they done so far?

This was, I thought, part of what being interviewed for a UX position would entail–showing how I’d go about thinking about the process.

I was more than ready to listen and learn; if I were to be a good fit, I’d be invested in making the product successful as well as developing a good experience for users. I was also prepared with some basic content strategy advice; suggestions about building a content strategy process seemed nicer than pointing out all the poor grammar and typos.

Soon, I was meeting with the founder. He talked about how a B-school professor had liked his idea and helped him get funding. I asked about the users. He responded by talking about selling to customers.

When he asked if I had questions, I asked, “What problem does this solve, for whom, and how do you know this?” It’s my standard question of any new project, and, I was learning, also a good gauge of where companies were in their process. He said he didn’t understand. He said that he had financial backing, so that was proof that there was a market for the app. What they wanted in a UX hire, he said, was someone to make what they had prettier, squash bugs, and help sell.

I got a bad feeling at that point; the founder dismissed the very idea of user research as distracting and taking time away from building his vision. Then I started talking about getting what they had in front of users, testing the hypotheses of the product, iterating the design based on this: all basic UX and Lean (and Lean UX!) to boot, at least to someone versed in the language and processes of both.

This, too, the founder saw as worse than worthless. He said it took resources away from selling and coding, and he thought that testing with users could leak the idea to competitors. So, no user research, no usability testing, no iteration of the design and product.

(Note on one of startups that’s part of this amalgam: As of this writing, there has been neither news nor updates to the company site since mid-2012, and though the app is still on the iTunes Store, it has too few reviews to have a public rating. This after receiving $1.2 million in seed funding in early 2012.)

The pre-start startup

I’ve also spoken with founders at earlier stages of starting up. One had been in marketing at large tech companies and wanted to combine publishing with social media. Another wrote me that they wanted to build an API for buying things online. I chatted with a B-school student who thought he’d invented the concept of jitneys (long story) and an economist who wanted to do something, though he wasn’t sure what, in the edu tech space. What they all had in common was a build-first mission. When I unpacked this, it became obvious that what they all meant was, “we don’t do research here.”

Like the company amalgam mentioned above, they all pushed back against suggestions to get out of the building (tm Steve Blank) to test their ideas against real users. Anything other than coding or even starting on the visual design of their products was seen as taking time away from delivering their ideas, which they were sure of (I heard a lot of “I took the class” and “we know the market” here).

And their ideas might end up being good ones–I can’t say. They seem largely well-intentioned, nice people. But when talking with them about how to make their product or service vital for users and therefore more likely to be a success, it soon becomes clear that what UX professionals see as vital tools and processes in helping create great experiences are seen quite differently by potential employers, to the point that even mentioning user research gets you shown the door. Politely, but still.

I’d like to bring up here the idea that perhaps we, as UX people, perhaps have contributed to the problem. The field is young and Protean, so the message of “what is UX?” can be garbled even if there were a good, concise answer. Also, in the past, user research has indeed been long and expensive and resulted in huge documents of requirements and so on, which the Lean UX movement is reacting to. So nobody’s totally innocent, to be sure. But that’s another article in the making (send positive votes to the editors).

One (anonymized) quote:

“Yep, blind building is a real disaster and time waste… I’ve seen huge brands go down that path… I have identified a great proof-of-concept market and have buy-in from some key players. My most immediate need, however, is a set of great product comps to help investors understand how the experience would work and what it might look like. I’ve actually done a really rough set of comps on my own, but while I’m a serious design snob, I am also terrible designer…”

So: Blind building is a real disaster, but she’s sketched out comps and just wants someone to make it look designed better. Perhaps she saw “buy in from some key players” as user research?

We had an extended exchange where I proposed lightweight, minimum-viable-product  prototypes to test her hypotheses with potential users. She objected, afraid her idea would get out, that testing small parts of the idea was meaningless, that she didn’t have time, that it only mattered what the “players” thought, that she never saw this at the companies she worked at (in marketing).

Besides, her funding process was to show comps of how her idea would work to these key players, and testing would only appear to reduce confidence in her idea. (Later that week, I heard someone say how “demonstrating confidence” was the key ingredient in a successful Y Combinator application.)

With her permission, I sent her a reading list including Steve Blank, Erika Hall, Bill Buxton, Eric Reis, and Jeff Gothelf. I still haven’t heard back.

Another (anonymized) quote:

“We’re looking for somebody who’s passionate about UI/UX to work with us on delivering this interface.

“Our industry specifics make us a game of throwing ideas around with stakeholders, seeing what sticks and building it as fast as possible. Speed unfortunately trumps excellence but all products consolidate while moving in the right direction.

“We certainly have the right direction business-wise and currently need to upgrade our interface. We require UX consulting on eliminating user difficulty in the process of buying, as well as an actual design for this.”

So: To him, it’s all about implementing an interface. Which, to him, is just smoothing user flows and, you know, coming up with a design. Frankly, I’m not sure how one could do this well, or with a user-centered ethic, without researching and interacting with potential users. I’m also not sure how to read his “upgrade our interface”; is that just picking better colors and shapes, in the absence of actual research and testing on whether it works well for users? That doesn’t strike me as useful, user-centric design. (During the interview process at Mozilla, I was asked the excellent question of how I’d distinguish art and design; I’m not sure I nailed the answer, but I suspect there’s more to design than picking colors and shapes.)

And I wasn’t sure even if he was receptive to the idea of users qua users in the first place. Before this exchange, when he described his business model, I pointed out that his users and his customers were two different sets of people and this can mean certain things from a design perspective. Given that his response was that they have been “throwing ideas around with stakeholders,” I gathered that his concept of testing with users was seeing what his funders liked. That did not bode well for actual user-centered design processes.

When I asked how they’d arrived at the current user flows and how they knew they were or weren’t good, he said that they internally step through them and show them to the investors (neither population is, again, the actual user). He was adamant both that talking to users would slow them down from building, and that because they were smart business people, they know they’re going in the right direction. It was at this point I thought that he and I were not speaking the same language.

I referred him to a visual designer I know who could do an excellent job.

I do not have the answers on how to bridge this fundamental gap between worldviews and processes. A good UX professional knows the value of user research and wants to bring that value to any company he or she joins. But though we can quote Blank, though we can show case studies, though we can show how a Gothelfian Lean UX process could be integrated into a hectic build schedule–when all this experience runs into a “build first” mentality, the experience and knowledge loses. At least in my experience. What is to be done?

Guerrilla Usability at Conferences

by:   |  Posted on

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.


For the time bookings, I find that 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.


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.


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.


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.


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.