Unleash Your Visual Superpower!

Written by: Steve Turbek

From start-ups to banks, design has never been more central to business. Yet at conference after conference, I meet designers at firms talking about their struggle for influence. Why is that fabled “seat at the table” so hard to find, and how can designers get a chair?

A superhero, partially wireframed and partially illustrated.
Designers have the magical ability to visualize the future.

Designers yearn for a world where companies depend on their ideas but usually work in a world where design is just one voice. In-house designers often have to advocate for design priorities versus new features or technical change. Agency designers can create great visions that fail to be executed. Is design just a service, or can designers* lead?

*Meaning anyone who provides the vision for a product, whether it be in code, wireframes, comps, prototypes, or cocktail napkins.

Continue reading Unleash Your Visual Superpower!

How to Determine When Customer Feedback Is Actionable

Written by: Naira Musallam

One of the riskiest assumptions for any new product or feature is that customers actually want it.

Although product leaders can propose numerous ‘lean’ methodologies to experiment inexpensively with new concepts before fully engineering them, anything short of launching a product or feature and monitoring its performance over time in the market is, by definition, not 100% accurate. That leaves us with a dangerously wide spectrum of user research strategies, and an even wider range of opinions for determining when customer feedback is actionable.

To the dismay of product teams desiring to ‘move fast and break things,’ their counterparts in data science and research advocate a slower, more traditional approach. These proponents of caution often emphasize an evaluation of statistical signals before considering customer insights valid enough to act upon.

This dynamic has meaningful ramifications. For those who care about making data-driven business decisions, the challenge that presents itself is: How do we adhere to rigorous scientific standards in a world that demands adaptability and agility to survive? Having frequently witnessed the back-and-forth between product teams and research groups, it is clear that there is no shortage of misconceptions and miscommunication between the two. Only a thorough analysis of some critical nuances in statistics and product management can help us bridge the gap. Continue reading How to Determine When Customer Feedback Is Actionable

Online Surveys On a Shoestring: Tips and Tricks

Written by: Gabriel Biller

Design research has always been about qualitative techniques. Increasingly, our clients ask us to add a “quant part” to projects, often without much or any additional budget. Luckily for us, there are plenty of tools available to conduct online surveys, from simple ones like Google Forms and SurveyMonkey to more elaborate ones like Qualtrics and Key Survey.

Whichever tool you choose, there are certain pitfalls in conducting quantitative research on a shoestring budget. Based on our own experience, we’ve compiled a set of tips and tricks to help avoid some common ones, as well as make your online survey more effective.

We’ve organized our thoughts around three survey phases: writing questions, finding respondents, and cleaning up data.

Writing questions

Writing a good questionnaire is both art and science, and we strongly encourage you to learn how to do it. Most of our tips here are relevant to all surveys, but particularly important for the low-budget ones. Having respondents who are compensated only a little, if at all, makes the need for good survey writing practices even more important.

Ask (dis)qualifying questions first

A sacred rule of surveys is to not waste people’s time. If there are terminating criteria, gather those up front and disqualify respondents as quickly as you can if they do not meet the profile. It is also more sensitive to terminate them with a message “Thank you for your time, but we already have enough respondents like you” rather than “Sorry, but you do not qualify for this survey.”

Keep it short

Little compensation means that respondents will drop out at higher rates. Only focus on what is truly important to your research questions. Ask yourself how exactly the information you collect will contribute to your research. If the answer is “not sure,” don’t ask.

For example, it’s common to ask about a level of education or income, but if comparing data across different levels of education or income is not essential to your analysis, don’t waste everyone’s time asking the questions. If your client insists on having “nice to know” answers, insist on allocating more budget to pay the respondents for extra work.

Keep it simple

Keep your target audience in mind and be a normal human being in framing your questions. Your client may insist on slipping in industry jargon and argue that “everyone knows what it is.” It is your job to make the survey speak the language of the respondents, not the client.

For example, in a survey about cameras, we changed the industry term “lifelogging” to a longer, but simpler phrase “capturing daily routines, such as commute, meals, household activities, and social interactions.”

Keep it engaging

People in real life don’t casually say, “I am somewhat satisfied” or “the idea is appealing to me.” To make your survey not only simple but also engaging, consider using more natural language for response choices.

For example, instead of using standard Likert-scale “strongly disagree” to “strongly agree” responses to the statement “This idea appeals to me” in a concept testing survey, we offered a scale “No, thanks” – “Meh” – “It’s okay” – “It’s pretty cool” – “It’s amazing.” We don’t know for sure if our respondents found this approach more engaging (we certainly hope so), but our client showed a deeper emotional response to the results.

Finding respondents

Online survey tools differ in how much help they provide with recruiting respondents, but most common tools will assist in finding the sample you need, if the profile is relatively generic or simple. For true “next to nothing” surveys, we’ve used Amazon Mechanical Turk (mTurk), SurveyMonkey Audience, and our own social networks for recruiting.

Be aware of quality

Cheap recruiting may easily result in low quality data. While low-budget surveys will always be vulnerable to quality concerns, there are mechanisms to ensure that you keep your quality bar high.

First of all, know what motivates your respondents. Amazon mTurk commonly pays $1 for the so-called “Human Intelligence Task” that may include taking an entire survey. In other words, someone is earning as little as $4 an hour if they complete four 15-minute surveys. As such, some mTurk Workers may try to cheat the system and complete multiple surveys for which they may not be qualified.

SurveyMonkey, on the other hand, claims that their Audience service delivers better quality, since the respondents are not motivated by money. Instead of compensating respondents, SurveyMonkey makes a small donation to the charity of their choice, thus lowering the risk of people being motivated to cheat for money.

Use social media

If you don’t need thousands of respondents and your sample is pretty generic, the best resource can be your social network. For surveys with fewer than 300 respondents, we’ve had great success with tapping into our collective social network of Artefact’s members, friends, and family. Write a request and ask your colleagues to post it on their networks. Of course, volunteers still need to match the profile. When we send an announcement, we include a very brief description of who we look for and send volunteers to a qualifying survey. This approach costs little but yields high-quality results.

We don’t pay our social connections for surveys, but many will be motivated to help a friend and will be very excited to hear about the outcomes. Share with them what you can as a “thank you” token.

For example, we used social network recruiting in early stages of Purple development. When we revealed the product months later, we posted a “thank you” link to the article to our social networks. Surprisingly even for us, many remembered the survey they took and were grateful to see the outcomes of their contribution.

Over-recruit

If you are trying to hit a certain sample size for “good” data, you need to over-recruit to remove the “bad” data. No survey is perfect and all can benefit from over-recruiting, but it’s almost a must for low-budget surveys. There are no rules, but we suggest over-recruiting by at least 20% to hit the sample size you need at the end. Since the whole survey costs you little, over-recruiting will equally cost little.

Cleaning up data

Cleaning up your data is another essential step of any survey that is particularly important for the one on a tight budget. A few simple tricks can increase the quality of responses, particularly if you use public recruiting resources. When choosing a survey tool, check what mechanisms are available for you to clean up your data.

Throw out duplicates

As mentioned earlier, some people may be motivated to complete the same survey multiple times and even under multiple profiles. We’ve spotted this when working with mTurk respondents by checking their Worker IDs. We had multiple cases when the same IDs were used to complete a survey multiple times. We ended up throwing away all responses associated with the “faulty IDs” and gained more confidence in our data at the end.

Check response time

With SurveyMonkey, you can calculate the time spent on the survey using the StartTime and EndTime data. We benchmarked the average time of the survey by piloting the survey in the office. This can be used as a pretty robust fool-proof mechanism.

If the benchmark time is eight minutes and you have surveys completed in three, you may question how carefully respondents were reading the questions. We flag such outliers as suspect and don’t include them in our analysis.

Add a dummy question

Dummy questions help filter out the respondent quickly answering survey questions at random. Dummy questions require the respondent to read carefully and then respond. People who click and type at random might answer it correctly, but it is unlikely. If the answer is incorrect, this is another flag we use to mark a respondent’s data as suspect.

Low-budget surveys are challenging, but not necessarily bad, and with a few tricks you can make them much more robust. If they are used as an indicative, rather than definitive, mechanism to supplement other design research activities, they can bring “good enough” insights to a project.

Educate your clients about the pros and cons of low-budget surveys and help them make a decision whether or not they want to invest more to get greater confidence in the quantitative results. Setting these expectations up front is critical for the client, but you never know, it could also be a good tool for negotiating a higher survey budget to begin with!

Enhancing the Mind-Meld

Written by: Mark Richman

Which version of the ‘suspended account’ dashboard page do you prefer?

Version A

Version A highlights the address with black text on a soft yellow background.

 

 

 

Version B

Version B does not highlight the service address.

 

 

Perhaps you don’t really care. Each one gets the job done in a clear and obvious way.

However, as the UX architect of the ‘overview’ page for a huge telecom leader, it was my job to tell the team which treatment we’d be using.

I was a freelancer with only four months tenure on this job, and in a company as large, diverse, and complex as this one, four months isn’t a very long time. There are a ton of things to learn—how their teams work, the latest visual standards, expected fidelity of wireframes, and most of all, selecting the ‘current’ interaction standards from a site with thousands of pages, many of which were culled from different companies following acquisitions or created at different points in time. Since I worked off-site, I had limited access to subject matter experts.

Time with the Telecom Giant’s UX leads is scarce, but Nick, my lead on this project , was a great guy with five years at the company, much of it on the Overview page and similar efforts. He and I had spent a lot of phone time going over this effort’s various challenges.

Version A, the yellow note treatment, had been created to highlight the suspended location if the “Home Phone” account covered more than one address. After much team discussion, we realized that this scenario could not occur, but since the new design placed what seemed like the proper emphasis on the ‘Account Suspended’ situation, I was confident that we’d be moving forward with version A.

So, why was I surprised when Nick said we’d “obviously” go with version B?

Whenever I start with a new company, I try to do a mind meld with co-workers to understand their approach, why they made certain decisions, and learn their priorities. Unless I’m certain there is a better way, I don’t want to go in with my UX guns blazing—I want to know whether they’d already considered other solutions, and if so, why they were rejected. This is especially true in a company like Telecom Giant, which takes user experience seriously.

I’d worked so closely with Nick on this project that I thought I knew his reasoning inside out. And when he came to a different conclusion, I wondered whether I’d ever be able to understand the company’s driving forces. If I wasn’t on the same page with someone who had the same job and a similar perspective, with whom I’d spent hours discussing the project, what chance did I have of seeing eye-to-eye with a business owner on the other side of the country or a developer halfway across the world?

Historical perspective

Version A (the yellow note treatment) was created by Ken, a visual designer who had an intimate knowledge of the telco’s design standards. This adhered to other instances where the yellow note was used to highlight an important situation.

Version B was the existing model, which had worked well in a section of the site that had been redesigned a year ago following significant user testing. Because of its success, this section–“Home Usage”–was earmarked as the model for future redesigns.

Once I had a bit of distance from the situation, I realized what the problem was. Although I had worked very closely with Nick, I didn’t have the same understanding of the company’s priorities.

My priorities were:

  • Consistency across the site
  • Accessibility
  • Using the most up to date and compelling interaction and design patterns
  • Modeling redesign efforts on “Home Usage” where possible

Because Nick had a background in visual design, I thought that he would want to use Ken’s design pattern, which seemed both more visually distinct and a better match for the situation. But Nick preferred the Home Usage pattern and may have had good reasons to think so.

First, Home Usage had been thoroughly tested, and since this was an ecommerce site with many hard-to-disentangle components, testing could have provided insight into its success factors, especially if individual components had been tested separately.

Second, by following the existing pattern, we wouldn’t wind up with two different treatments for the same situation. Even though the yellow note treatment might be more prominent, was it significant enough to shoulder the cost of changing the pattern in the existing Home Usage flow?

Now that I knew at least one piece of the puzzle, I wondered how I might have achieved a more complete ‘mind meld’ with Nick, so that we were more closely in sync.

Know your priorities—and check them out

Just being aware of the priorities I was following would have offered me the chance to discuss them directly with Nick. With so much information to take in, I hadn’t thought to clarify my priorities and compare them with my co-workers, but this would have made it easier to sync up.

Other barriers to knowledge transfer

Gabriel Szulanski1 identified three major barriers to internal knowledge transfer within a business. Although these are aimed at firm-wide knowledge, they seem relevant here for individuals as well:

Recipient’s lack of absorptive capacity

Absorptive capacity is defined as a firm’s “ability to recognize the value of new information, assimilate it, and apply it to commercial ends.”2 To encourage this, companies are urged to embrace the value of R&D and continually evaluate new information.

Szulanski notes that such capacity is “largely a function of (the recipient’s) preexisting stock of knowledge.”3 If existing knowledge might help or hinder gathering new information, how might we apply this to an individual?

  • As information load increases, it lessens your ability to understand it and properly place it within a mental framework.
  • While the new company may have hired you for your experience and knowledge, you might need to reevaluate some of that knowledge. For instance, it may be difficult to shed and reframe your priorities to be in sync with the new firm.

Causal ambiguity

Causal ambiguity refers to an inability to precisely articulate the reasons behind a process or capability. According to Szulanski, this exists “when the precise reasons for success or failure in replicating a capability in a new setting cannot be determined.”

How did causal ambiguity affect this transfer? While the site’s Home Usage section was promoted because of its successful testing and rollout, the reasons behind its success were never clear. Success of an ecommerce site depends on many factors, among them navigation, length and content of copy and labels, information density, and the site’s interaction design. Since Home Usage’s advantages had never been broken down into its components, and I hadn’t been there when usability tests were conducted, I could only see it as a black box.

To truly assimilate new knowledge, you need context. If none is provided, you need to know how to go out and get it. Ask about the reasons behind a model site. If possible, read any test reports. Keep asking until you understand and validate your conclusions.

An arduous relationship between the source and the recipient

Finally, knowledge transfer depends on the ease of communication and ‘intimacy’ between the source and recipient. Although my relationship with Nick was close, I worked off-site, which eliminated many informal opportunities for knowledge sharing. I couldn’t ask questions during a chance meeting or ‘ambush’ a manager by waiting for her to emerge from a meeting. Since I didn’t have access to Telecom Giant’s internal messaging system, I was limited to more formal methods such as email or phone calls.

A model for knowledge transfer

Thomas Jones offered this approach to knowledge transfer in a Quora post: “As they say in the Army: ‘an explanation, a demonstration, and a practical application.’ Storytelling, modeling, and task assignment … share your stories, model the behaviors you want to see and assign the tasks required to build competency.”4

Keeping “Home Usage” in mind, the story could be “how we came to follow this model,” the demonstration could be the research paper, and a practical application could be your work, evaluated by your lead.

In conclusion

Your ability to retain new information is essential to your success at a new company. However, your ability to understand the reasons behind the information and place these within a framework are even more important. Some techniques to help you do so are:

  • Be aware of your own design priorities and how they match with the firm’s. Treat the company’s priorities like any user research problem and check them out with your leads and co-workers.
  • To increase your absorptive capacity, evaluate your preconceptions and be prepared to change them.
  • Ask for the reasons behind a ‘model’ design. Read research reports if available.
  • Maximize your contact points. Follow-up emails can target ambiguous responses. If time with the UX leads is scarce, ask your co-workers about their view of priorities, patterns and the reasons behind them.

Further reading

1 Szulanski, G 1996, ‘Exploring Internal Stickiness: Impediments to the Transfer of Best Practice within the Firm’, Strategic Management Journal, vol. 17, pp. 27-43.

2 Absorptive capacity. Wikipedia entry.

3 Dierickx, Ingemar and Karel Cool. 1989. “Asset stock accumulation and sustainability of competitive advantage.” Management Science. 35 (December): 1504-1511.

4 “What patterns of behavior have proven to be most helpful in knowledge transfer?” Quora post.

Forms: The Complete Guide—Part 4

Written by: Martin Polley

In which we take a look at selection-dependent inputs, and see that they’re a lot more simple to put together than they look.

Forms. They’re often the bane of users’ online lives. But it doesn’t look like they’re going away any time soon. So its up to us, UX designers, to make them as smooth and easy to use as possible for our users while still reaching the best business outcomes.

If we prototype our forms, we can get them in front of users earlier and get feedback sooner, which we can use to iterate our designs. Previous posts in this series covered form layout and alignment, input types, and grouping and inline help.

In this, the fourth post in this series, we take a look at selection-dependent inputs. (I’ve also seen it referred to as “responsive enabling” and/or “responsive disclosure”). All this means is changing the fields that the user sees based on some selection that they have made or some information that they have provided. For example, if we’re asking the user for their postal address, we might have a field where they can enter (or select) the country that they live in. Then, depending on the country, we can change the other fields to match the standard address format for that country.

Note: “Responsive enabling” refers to having one or more fields that are disabled until the user makes a particular selection, in which case they become enabled, allowing the user to interact with them. “Responsive disclosure,” on the other hand, hides the fields, and makes them appear if the user makes a particular selection. I don’t recall seeing many forms that use responsive enabling of late, but I’m sure it’s useful in some circumstances, so I’ll include an example.

Responsive enabling

I think one of the reasons that this pattern has fallen out of favor in recent years is that it can be distracting. You have all these disabled fields, and they just take up space and draw the user’s attention away from the stuff that matters unless they click on a particular checkbox (which may only be relevant for a small percentage of users).

One benefit is that things stay put. When you use responsive disclosure to make fields appear and disappear, the content below them suddenly jumps downward, which can be jarring and disorienting. But nowadays, it’s easy to animate transitions like this, which can reduce the problem.

Anyway, in some cases, responsive enabling is going to be the right approach (where there aren’t too many disabled fields, and where it would be confusing not to show them), so let’s press on with an example.

In this example, we’re going to let the user opt in to receiving text messages from us to let them know about special offers. You would typically find things like this at the bottom of an order form. We’ll have a field where they can enter their mobile number, which will be disabled until they click the opt-in checkbox.

After you’ve set up a new Foundation project (this post explains how), add this HTML just after the opening <body> tag. (We’re not going to waste time prototyping the whole form–we’ll just prototype the bit we’re interested in.)

Somewhere within the page’s <head> tags, add this <style> block:

The result looks like this:

Our form, with the phone number input disabled

What I’ve done here is not very complicated. Like in the previous posts, I’ve used Foundation’s grid to lay out the form. In the second line of the HTML, I’m just squishing the form down into eight of Foundation’s available twelve columns, and adding a two-column offset to center it on the page.

The first bit of actual content is a paragraph to show where the actual form fields and labels would go if this was a real form.

Then we’ve got a row containing a column that takes up all twelve columns. (small-12 columns means it is twelve columns wide on small screen sizes and anything bigger, i.e., all screen sizes.) This contains the checkbox <input> (with id and name) and its label (which uses for to link it to the checkbox, so that you can click on it to toggle the checkbox too).

After that, there’s another row that contains two columns, for the phone number <input> and its <label>. Notice how this divvies up the available space differently for small and medium (and bigger) screens.

For small screens, we’ve got a three/nine column split, so together they fill up all the available width. But on medium-and-up screens, they are three and six columns wide. This is to prevent the <input> from being ridiculously wide on larger screens—Foundation makes each input 100% of the width of the column that it’s in. (By default, if the number of columns doesn’t add up to twelve, Foundation scoots the last column over so it is right-aligned. I’ve added the end class to stop this happening.)

The label gets the right class to right-align it, and the align class to align it vertically with the <input>. It also gets an ID so we can style it and do stuff to it. And the <input> gets the appropriate type (tel) and the disabled property to make it disabled initially.

The CSS in the <style> block in <head> just applies some styling to the placeholder text that shows where the real form fields would go and makes the “Mobile number” label grey so it looks disabled. (You can add the disabled property to <input>s, but not to <label>s—you have to style these yourself so they’ll look disabled.)

It looks OK so far. The phone number input is disabled, and its label looks disabled too. But it doesn’t get enabled when you check the checkbox. For that, we need a bit of JavaScript. Not much; just a smidge.

At the bottom of the page, right before the closing </body> tag, add this <script> block:

This is pretty similar to what we saw in the last post. All the code is inside the jQuery $(document).ready() function, so it will only get run after the page has finished loading.

Within $(document).ready(), this part of the first line selects the checkbox:

$('#cb')  

that is, the element with the ID of cb, then this part:

.on('change', function(){  

calls the on() function to detect when its state changes. The three lines within the curly braces ({}) specify what happens when this change event is detected:

  • In the first line, this bit:
    $('#mobilelabel')
    

    selects the label for the phone number field, which has an ID of mobilelabel, then this bit:

    .toggleClass('disabled')
    

    calls toggleClass() on it. This adds the disabled class to the element if it doesn’t already have it, and removes it if it does. This is the class that gives it the grey color, so removing it switches it back to its default color, black.

  • The second line declares a variable called checked. Then this part:
    $('#cb')
    

    selects the checkbox again and then checks whether it is checked or not like this:

    .is(':checked')
    

    This gives us an answer of true or false. The ! reverses this value. If it is true, this makes it false, and vice-versa. Then this value gets stored in our checked variable. I’ll explain why we need to reverse the value in a minute.

  • The third line selects the phone number input, which has an ID of mobile, like this:
    $('#mobile')
    

    and calls prop() on it to set the value of its disabled property. And the value we give it is whatever we just stored in our checked variable. This way, if the checkbox is checked, checked gets a value of false, which we use to set disabled to false. (Actually, I used trial and error to know whether I needed to reverse the value or not! I like to think of this kind of thing as being pragmatic.)

    In fact, disabled doesn’t take a value–an element either has the property or it doesn’t. But behind the scenes, jQuery correctly interprets us giving disabled a value of false and simply removes the property.

Now checking the checkbox enables the input, so it looks like this (and unchecking it disables it again):

Our form, with the phone number input now enabled

You can see it in action here.

Responsive disclosure

For responsive disclosure, we’re just going to take the previous example and change a couple of things. Here’s the HTML:

The only changes that I’ve made here are to remove the disabled attribute from the phone number <input> and to remove the disabled class from its <label>. And I’ve added a new ID, mobile_container, to the row <div> that contains them so that I’ll have something to attach behavior to.

The CSS is a bit different too:

Gone is the rule for styling the “disabled” label, and in its place is a rule that hides the row <div> that contains the phone number input and its label by giving it a display of none.

As you can see, when the checkbox is unchecked, the phone number input and its label are nowhere to be seen:

Our form, with the phone number input hidden

To make them appear when you check the checkbox, we need to modify our JavaScript:

This is much simpler than it was before. All we’ve got now inside the function is one line, which toggles the visibility of the <div> that contains the phone number field. Using the toggle() function means that whenever the state of the checkbox changes, we either show or hide the phone number field. We don’t have to check the value of anything, store things in variables, or any of that stuff.

Now when we check the checkbox, the phone number field appears:

Our form, with the phone number input now shown

(You can see a live example here.)

If we had additional content below these elements, it would jump down when the phone number field appears. It doesn’t take up much space, so it doesn’t jump very much. But imagine if what we were making appear was a whole sub-section of the form that takes up half the height of the page. Pushing the following content down by so much can be very disorienting.

It’s worth taking a minute to look at how we can use animation to make changes like this more palatable. We’ll add some more content after the phone number field, then add animation and see how it looks. Add another <div> containing some text below the hidden one, so it looks like this:

Now let’s change our JavaScript to include animation. Luckily, in this case, it is very easy indeed. All we need to do is replace the call to toggle() with a call to slideToggle(), so it looks like this:

Instead of just showing or hiding the element, slideToggle() makes it appear by sliding it down from the top, or hides it by sliding it up. Try it out here.

We can control various aspects of how this animation happens. For example, we can make it faster or slower by putting a value (in milliseconds) in the parentheses, like this:

slideToggle(1000)  

This example shows this slower version in action.

Another thing we can do is control the flow of the animation (what is referred to as its easing). By default, jQuery animations start out slow, speed up in the middle, then slow down again at the end. We can change this by doing something like this:

slideToggle({easing: easeInCubic})

Note that to use additional easings like this one, you need to include the jQuery UI library by adding these two lines near the bottom of the page (before the <script> block that contains our code):

This starts off slow, like before, but speeds up and then doesn’t slow down–it just stops abruptly, as if it had hit a wall. Try it here.

We’re off on a bit of a tangent here, but I’ll just show you one more before we move on to the next thing. There are 32 different easings available in jQuery, and each one gives the animation a slightly different feel.

For example, look what happens when we change the easing to easeOutBounce:

slideToggle({easing: easeOutBounce})

Take a look here. Fun, isn’t it?

More complex scenarios

Sometimes we are faced with more complex scenarios than just disabling or enabling part of a form, or showing and hiding it. Often these more complex scenarios involve replacing one set of inputs with another depending on what the user selects. The example that Luke Wroblewski uses in his book is a “contact me” form, where the user can choose to be contacted via email, phone, SMS, or IM. When the user makes a selection, the form changes to show just the relevant fields (email address for email, phone number for phone, and so on).

There are lots of different ways that a form like this could work. You could have the initial selection as tabs, with the appropriate form fields inside each tab. You could have a drop-down list for email, SMS, etc, with the form fields right below it. You could have radio buttons for the initial selection, with the relevant fields appearing either below the radio button group or below the selected option. You could even go with a progressive-enabling-style design, with a disabled set of fields after each radio button, with the appropriate set of controls being enabled when the user selects one of the options.

(And, of course, there are lots of other scenarios where one user selection changes something else. One that you see pretty often is two drop-down lists, where the first is for selecting a category and the second is for selecting a sub-category, or an item within the selected category. So on a site that lists second-hand cars, you might have one drop-down list for selecting the brand, and a second for selecting the model.)

I could show you how to prototype one of these, but that wouldn’t help at all with any of the others. And if I were to show you how to prototype them all, you would soon lapse into a boredom-induced coma. So what to do?

Is there some common thread can we draw out of all these different scenarios? Maybe there’s some technique can I show you that will be useful in prototyping all of these? Well, there isn’t really. All I can do is give you some pointers, which will hopefully help you to avoid some wasted effort:

Be lazy

There is the way that a proper programmer would do something, and then there are shortcuts. We’re not writing production code here, so it doesn’t matter if we cut corners. What matters is that it walks and quacks like the real thing. Or even just enough like the real thing to be moderately convincing. So going back to the example I just gave of a pair of drop-down lists, the proper way to build something like this would be to populate the first list dynamically using a list of car brands that you request from the server. Then, when the user selects a brand, you would make another server request for the list of models for the brand, and use that to dynamically build up the list.

But for a prototype, you might not even need all the possible car brands and their models. It might be enough to have half a dozen brands, and a few models for each. And instead of dynamically populating each <select> element with the appropriate <option>s, you can put six separate <select>s in yout HTML, one for each brand, hide them all to start with, and just use JavaScript to show the right one depending on the brand that the user selects.

Learn a few key things in JavaScript/jQuery.

You don’t need to know everything there is to know about JavaScript and jQuery to be able to do useful stuff with it. The ones I find myself using most often are:

  • Event handlers. Mostly, this means using jQuery’s on() function to detect when the user does something to some element, and performing some action when they do.
  • Chaining. Every function gives you something when it’s done. (In programming parlance, it “returns” it.) You can then do something with the thing it returns. So if you call the find() function on an element like this:
    $('#myelement').find('li');
    

    find() returns the <li> element that it found (if there was one within #myelement for it to find). So then you can do stuff to the <li> by chaining another function on the end, like this:

    $('#myelement').find('li').hide();
    

    hide() returns the element that it just hid, so you could, if you wanted, tack on yet another function to the chain to do something else to it. (But we won’t.)

  • Simple conditional branching. The if and if ... else constructs let you ask “is this thing true”, and if it is, to perform some action. (else lets you do something else if it isn’t true.)
  • Slightly less simple conditional branching. When you’ve got something that can have multiple different outcomes, each with a different action to be performed, if becomes an overly-complicated way of doing things. The JavaScript switch statement is perfect in these situations. It’s ideal when you’ve got something like a drop-down list with several options, and you want to do a different thing for each selected option.
  • Making stuff appear and disappear. We can use show(), hide(), and toggle(), as we’ve seen, to make stuff appear and disappear. And we can either supply additional arguments to these functions to animate them (and to control things like the speed and direction of the animation) or use special functions like slideUp() and slideDown() (and slideToggle(), which we saw above) to do the same thing. There’s also the animate() function, for when we want full control over every aspect of an animation.

Look stuff up.

The jQuery documentation is pretty good. If you know the name of the function you’re trying to use, it tells you everything you need to know about how to use it. And if you don’t know which function you need, it has category pages that list all the functions for, for example, getting from one element to another, or for inserting, removing, and manipulating elements. (Note that jQuery is an addition to JavaScript. Some things, like if and switch, are part of JavaScript, not jQuery, so you won’t get very far searching for them in the jQuery docs.) And if you Google for the thing you’re wrestling with, you’ll usually end up at Stack Overflow, the Q&A site for programmers. 99.9% of the time, your question will have already been asked and answered. For example, I wanted to know the correct way to find out if a checkbox is checked or not. So I Googled jquery checkbox get value, clicked the first result, and got the information I needed from the top answer. Easy-peasy.

Don’t be afraid of doing it “wrong.”

For anything you want to do, there are going to be several (even many) different ways to do it. Does it matter which one you choose? For a (disposable) prototype, it doesn’t. The only thing that matters is: does it work or not? If it works, it’s “right”. I’m sure a “real” programmer would take one look at most of my prototype code and snicker to himself under his beard. But it serves the purpose for which it is intended, so it doesn’t matter.

Having said that, I do have a couple of examples that you can take a look at. The first shows a different form depending on what you select in a drop-down list. The second changes the contents of one drop-down list depending on what you select in another. Use the View Source option in your browser to see how they work—they don’t do anything particularly clever.

Conclusion

Changing parts of a form depending on what the user selects is pretty powerful. We can use it to hide complexity from the user and make our forms more simple to use. It means we need to learn a bit of JavaScript, but we can do a lot with a little. I think it’s well worth the effort.