Mystical Guidelines for Creating Great User Experiences

by:   |  Posted on

The Jewish Torah teaches that the Creator created our world through ten utterances–for example, “let there be light.”

The Jewish mystical tradition explains that these utterances correspond with ten stages in the process of creation. Every creative process in the world ultimately follows this progression, because it is really a part of the continual unfolding of the world itself, in which we are co-creators.

This article aims to present an overview of the mystical process of creation and principal of co-creation and to illustrate how it can guide bringing digital product ideas into reality–although it’s easy enough to see how this could translate to other products and services–in a way that ensures a great user experience, and makes our creative process more natural and outcomes more fruitful.

Continue reading Mystical Guidelines for Creating Great User Experiences

A Beginner’s Guide to Web Site Optimization—Part 2

by:   |  Posted on

In the previous article we talked about why site optimization is important and presented a few important goals and philosophies to impart on your team. I’d like to switch gears now and talk about more tactical stuff, namely, process.

Optimization process

Establishing a well-formed, formal optimization process is beneficial for the following reasons.

  1. It organizes the workflow and sets clear expectations for completion.
  2. Establishes quality control standards to reduce bugs/errors.
  3. Adds legitimacy to the whole operation so that if questioned by stakeholders, you can explain the logic behind the process.

Continue reading A Beginner’s Guide to Web Site Optimization—Part 2

Enhancing the Mind-Meld

by:   |  Posted on

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.

Continue reading Enhancing the Mind-Meld

A Beginner’s Guide to Web Site Optimization—Part 1

by:   |  Posted on

Web site optimization, commonly known as A/B testing, has become an expected competency among many web teams, yet there are few comprehensive and unbiased books, articles, or training opportunities aimed at individuals trying to create this capability within their organization.

In this series, I’ll present a detailed, practical guide on how to build, fine-tune, and evolve an optimization program. Part 1 will cover some basics: definitions, goals and philosophies. In Part 2, I’ll dive into a detailed process discussion covering topics such as deciding what to test, writing optimization plans, and best practices when running tests. Part 3 will finish up with communication planning, team composition, and tool selection. Let’s get started!

The basics: What is web site optimization?

Web site optimization is an experimental method for testing which designs work best for your site. The basic process is simple:

  1. Create a few different design options, or variations, of a page/section of your website.
  2. Split up your web site traffic so that each visitor to the page sees either your current version (the control group) or one of these new variations.
  3. Keep track of which version performs better based on specific performance metrics.

The performance metrics are chosen to directly reflect your site’s business goals and might include things like how many product purchases were made on your site (a sales goal), how many people signed up for the company newsletter (an engagement goal), or how many people watched a self-help video in your FAQ section (a customer service goal). Performance metrics are often referred to as conversion rates, which equals the percentage of visitors who performed the action being tested compared to the total number of visitors to that page.

Optimization can be thought of as one component in the web site development ecosystem. Within optimization, the basic process is to analyze data, create and run tests, then implement the winners of those tests.

Visual of where optimzation fits in site development
Optimization can be thought of as one component in the website development ecosystem.

 

A/B vs. multivariate

There are two basic types of optimization tests: A/B tests (also known as an A/B/N tests) and multivariate tests.

A/B tests

In an A/B test, you run two or more fixed design variations against each other. The variations might differ in only one individual element (such as the color of a button or swapping out an image for a video) or in many elements all at once (such as changing the entire page layout and design, changing a long form into a step-by-step wizard, etc…).

Three buttons for testing, each with different copy.
Example 1: A simple A/B/N test trying to determine which of three different button texts drives more clicks.

 

 

 

Visuals showing page content in different layouts.
Example 2: An A/B test showing large variations in both page layout and content.

 

In general, A/B tests are simpler to design and analyze and also return faster results since they usually contain fewer variations than multivariate tests. They seem to constitute the vast majority of manual testing that occurs these days.

Multivariate tests

Multivariate tests vary two or more attributes on a page and test which combination works best. The key difference between A/B and multivariate tests is that the latter are designed to tease apart how two or more dimensions of a design interact with each other and lead to that design’s success. In the example below, the team is trying to figure out what combination of button text and color will get the most clicks.

Buttons with both different copy and different colors
Example 1: A simple multivariate test with 2 dimensions (button color and button text) and 3 variations on each dimension.

The simplest form of multivariate testing is called the full-factorial method, which involves testing every combination of factors against each other, as in the example above. The biggest drawback of these tests is that they generally take longer to get statistically significant results since you are splitting the same amount of site traffic between more variations than A/B tests.

Other fractional factorial methods use statistics to try and interpolate the results of certain combinations, thereby reducing the traffic needed to test every single variation. Many of today’s optimization tools allow you to play around with these different multivariate methods; just keep in mind that fractional factorial methods are often complex, named after deceased Japanese mathematicians, and require a degree in statistics to fully comprehend. Use at your own risk.

Why do we test? Goals, benefits, and rationale

There are many benefits of moving your organization to a more data-driven culture. Optimization establishes a metrics-based system for determining design success vs. failure, thereby allowing your team to learn with each test. No longer will people argue ad nauseum over design details. Cast away the chains of the HiPPO effect—in which the Highest Paid Person in the Office determines what goes on your site. Once you have established a clear set of goals and the appropriate metrics for measuring those goals, the data should speak as the deciding voice.

Optimization can also drastically improve your organization’s product innovation process by allowing you to test new product ideas at scale and quickly figure out which are good and which should be scrapped. In his article “How We Determine Product Success” John Ciancutti of Netflix describes it this way:

“Innovation involves a lot of failure. If we’re never failing, we aren’t trying for something out on the edge from where we are today. In this regard, failure is perfectly acceptable at Netflix. This wouldn’t be the case if we were operating a nuclear power plant or manufacturing cars. The only real failure that’s unacceptable at Netflix is the failure to innovate.

So if you’re going to fail, fail cheaply. And know when you’ve failed vs. when you’ve gotten it right.”

Top three testing philosophies

1. Rigorously focus on metrics

I personally don’t subscribe to the philosophy that you should test every single change on your site. However, I do believe that every organization’s web strategies should be grounded in measurable goals that are mapped directly to your business goals.

For example, if management tells you that the web site should “offer the best customer service,” your job is to then determine which metrics adequately represent that conceptual goal. Maybe it can be represented by the total number of help tickets or emails answered from your site combined with a web customer satisfaction rating or the average user rating of individual question/answer pairs in your FAQ section. As Galileo supposedly said, “Measure what is measurable, and make measurable what is not so.”

Additionally, your site’s foundational architecture should allow, to the fullest extent possible, the measurement of true conversions and not simply indicators (often referred to as macro vs micro conversions). For example, if your ecommerce site is only capable of measuring order submissions (or worse yet, leads), make it your first order of business to be able to track that order submission through to a true paid sale. Then ensure that your team always has an eye on these true conversions in addition to any intermediate steps and secondary website goals.  There are many benefits of measuring micro conversion rates, but the work must be done to map them to a tangible macro conversion or you run the risk of optimizing for a false conversion goal.

2. Nobody really knows what will win

I firmly believe that even the experts can’t consistently predict the outcome of optimization tests with even close to 100% accuracy. This is, after all, the whole point of testing. Someone with good intuition and experience will probably have a higher win rate than others, but for any individual test, anyone can be right. With this in mind, don’t let certain members of the team bully others into design submission. When it doubt, test it out.

3. Favor a “small-but-frequent” release strategy

In other words, err on the side of only changing one thing at a time, but perform the changes frequently. This strategy will allow you to pinpoint exactly which changes are affecting your site’s conversion rates. Let’s look at the earlier A/B test example to illustrate this point.

Visuals showing page content in different layouts.
An A/B test showing large variations in both page layout and content.

Let’s imagine that your new marketing director decides that your company should completely overhaul the homepage. After a few months of work, the team launches the new “3-column” design (above-right). Listening to the optimization voice inside your head, you decide to run an A/B test, continuing to show the old design to just 10% of the site visitors and the new design to the remaining 90%.

To your team’s dismay, the old design actually outperforms the new one. What should you do? It would be difficult to simply scrap the new design in its entirety, since it was a project that came directly from your boss and the entire team worked so hard on it. There are most likely a number of elements of the new design that actually perform better than the original, but because you launched so many changes all at once, it is difficult to separate the good from the bad.

A better strategy would have been to have constantly optimized different aspects of the page in small but frequent tests to gradually evolve towards a new version. This process, in combination with other research methods, would provide your team with a better foundation for performing site changes. As Jared Spool argued in his article The Quiet Death of the Major Relaunch, “the best sites have replaced this process of revolution with a new process of subtle evolution. Entire redesigns have quietly faded away with continuous improvements taking their place.”

Conclusion

By now you should have a strong understanding of optimization basics and may have started your own healthy internal dialogue related to philosophies and rationale. In the next article, we’ll talk about more tactical concerns, specifically, the optimization process.

User Experience Research at Scale

by:   |  Posted on

An important part of any user experience department should be a consistent outreach effort to users both familiar and unfamiliar. Yet, it is hard to both establish and sustain a continued voice amongst the business of our schedules.

Recruiting, screening, and scheduling daily or weekly one-on-one walkthroughs can be daunting for someone in a small department having more than just user research responsibilities, and the investment of time eventually outweighs the returns as both the number of participants and size of the company grow.

This article is targeted at user experience practitioners at small- to mid-size companies who want to incorporate a component of user research into their workflow.

It first outlines a point of advocacy around why it is important to build user research into a company’s ethos from the very start and states why relying upon standard analytics packages are not enough. The article then addresses some of the challenges around being able to automate, scale, document, and share these efforts as your user base (hopefully) increases.

Finally, the article goes on to propose a methodology that allows for an adjustable balance between a department’s user research and product design and highlights the evolution of trends, best practices, and common avoidances found within the user research industry, especially as they relate to SaaS-based products.

Why conduct usability sessions?

User research is imperative to the success and prioritization of any software application–or any product, for that matter. Research should be established as an ongoing cycle, one that is woven into the fabric of the company, and should never drop-off nor be simply ‘tacked on’ as acceptance testing after launch. By establishing a constant stream of non-biased opinions and open lines of communication which are immune to politics and ever-shifting strategies, research keeps design and development efforts grounded in what should already be the application’s first priority–the user.

A primary benefit in working with SasS products is that you’re able to gain feedback in real-time when any feature is changed. You don’t have to worry about obsolete versions, or download packages–web-based software enables you to change directions quickly. Combining an ongoing research effort with popular software development methods such as agile or waterfall allows for immediate response when issues with an application’s usability are found.

Different from analytics

SaaS are unique in that there is not the same type of tracking needed in-product. Metrics such as page views or bounce-rates are largely irrelevant, because the user could be spending their entire session on configuring functions of a single feature on a single page.

For example, for our application here at Loggly, the user views an average of ~2 pages (predominantly login and then search) and spends on average 8x as long on search then any other page. Progression is made within the page-level functions, not among multiple pages within the application’s structure.

Javascript-heavy applications don’t have the same URL and tree structure content-heavy sites are built around but instead make calls to different states of the application from within the same page.

Say your analytics package gives an indication that something is wrong with the setup flow or configuration screen, but you don’t yet have a good concept of at what point in the process the users are getting stuck.

Perhaps a button might be getting click after click because it is confusing and unresponsive, not because its useful. Trying to solve this exclusively with an analytics package will pale in comparison to the feedback you’ll get from a single, candid user who hits the wall. As discussed later in this article, with screensharing, you’re able see the context in which the user is trying to achieve a specific task, defining the ‘why’ in their confusing becomes more apparent than just the ‘what’ are they clicking on.

Determining a testing audience

The first component of defining any research effort should be to define who you want to talk to. Ideally, you’ll be able to have a mix of both new users and veterans that are able to provide a well-rounded feedback loop on both initial impressions of your application as well as historical perspective on evolution and found shortcomings after repeated use, but not all companies have this luxury.

Once in the door

Focus first on the initial steps the user has to take when interacting with your application. It seems obvious, but if these are not fulfilled with maximum efficiency, the user will never progress into more advanced features.

Increasing the effectiveness of the flow through set-up, configuration, and properly defining a measure of activation will pay dividends to all areas of the application. This should be a metric that is tested, measured, and monitored closely, as it functions as a type of internal bounce rate. Ensuring that the top of the stream for the majority of application users is sound will guarantee improved usage further down the road to the deeper, buried interactions.

These advanced features should be also be tracked and measured with the correlation that starts to paint a profile of conversion. Some companies define conversion as free-to-paid; others do so in a more viral sense–conversion being defined as someone who has shared on social media or similar.

As you start itemize these important features, you’ll get a better sense of the usage profile for where you’re trying to point the user to. For example, adding a listing record, or perhaps customizing a page–these might match a profile for someone who is primed for repeat visitation, someone who has created utility and a lasting connection, and ultimately ready to convert.

Avoiding overlap

If there is a focus on recruiting participants who are newly signed-up users, then you’ll likely overlap with outbound sales efforts. Because your company’s sales and marketing funnel tries as hard as possible to convert trial users to paid, or paid to upgrade, the company’s priority will likely be on conversion, not on research.

Further, if a researcher tries to outreach for usability surveys at this point, from the user’s perspective (especially those deemed potential high-value customers) it would mean different prompts for different conversations with different people from various groups within your company, all competing for spots on their calendar. This gives a very hectic and frenetic impression of your company and should be avoided.

In the case of a SaaS product, sometimes the sales team has already made contact with potential customers, and many of these sales discussions involve demonstrations around populated, best-case scenarios (which showcase the full features) of your product.

As a result, you may find the participant has been able to ‘peek behind the curtain’ through watching the sales team provide these demonstrations, giving them an unfair advantage as to how much he / she knows before trying to finally use the product themselves. For the inexperienced user, your goal is to capture the genuine instinct of the uninitiated, not those who have seen the ‘happy path’ and are trying to trace back the steps to get to that fully-populated view.

To make sure you’re not bumping heads with the sales and conversion team, ask if you can take their castoffs–the customers they don’t think will convert. You can pull these from their CRM application and automate personalized emails asking for their time. I’ll outline this method in further detail in the section following, because it pertains to the veteran users as well.

Photo of people in a conference exhibit hall.
Conferences are a great way to survey new and existing users.

As described in a previous post, guerrilla testing at conferences is a great way of fulfilling what gets seen and what parts of the interface or concept get ignored. These participants are great providers of honest, unbiased feedback and haven’t been exposed to the product other than some initial impressions of the concept.

Desiring the messy room

But what about the users that have been using your product for months now, those who have skin in the game, have already put their sweat and dollars behind customization of their experience? Surveying these participants allows us to see where they’ve found both utility and what areas need be expanded upon. Surveying only the uninitiated won’t provide feedback on any nagging functional roadblocks, those which are found only after repeated use. These are the participants that will provide the most useful feedback, sessions where you can observe the environment that they’ve created for themselves, the ‘messy room.’

Making an observational research analogy, a messy room is more telling of the occupants’ personality than an empty one. Given your limitations, how has the participant been forced to find workarounds? Despite these workarounds, they’ve continued to use the product, in despite of how we’ve expected them to use it–and these two can be contrastingly very different.

Online feedback form for Loggly UK.
Example of a feedback form, initiated via email.
User is able to schedule a 1:1 screensharing session on the confirmation page.

Automated recruitment

Find your friendly marketing representative/sales engineer at your company (or just roll your own) and discuss with them the best way to integrate a user experience outreach email into the company’s post-funnel strategy. For example, post-funnel would be after their trial periods have long since expired and the user is either comfortable in their freemium state or fully paid up.

As mentioned earlier, you can also harvest leads from the top of the funnel in the discarded CRM leads. However, you’ll likely have a greater percentage of sessions with users that are misfires–those indifferent or only just poking around the app, with not yet a full understanding of what it might do. Thankfully, the opt-in approach for participation filters this out for the most part.

Focusing again on the recruitment of the veteran, experienced users, another, more complex scenario would be to trigger this UX outreach email once a specific set of features have been initiated–giving off the desired signature of an advanced, informed user.

Going from purely legacy-based perspective, six months of paid, active use should be enough time to establish a relationship with a piece of software, whether they love or hate it. If there exists enough insight into the analytics side of the sales process, it would behoove you to also make sure that the user has had a minimum number of logins across these six months (or however long you’ll allow the users to mature).

Outreach emails triggered through the CRM should empower the recipient to make the experience of the product better, both for themselves and their fellow customers. Netflix does a great job of this by continually asking about the streaming quality or any delays around arrival times of their product.

I also recommend asking the users a couple of quantitative and qualitative questions, as this metric something you should be doing for your greater UX efforts already. These questions follow the guidelines of general SUS (System Usability Survey) practices that have been around for decades. Make the questions general enough so that they can be re-used and compared going forward, without fear of needing the change the goalposts when features or company priorities change.

Screen grab of the user's desktop.
A peek into an active user’s work environment.

When engineering this survey, be sure to track which tier of customer is filling out these surveys, because both their experience and expectations could be wildly different. Remember also to capture the user’s email address as a hidden field so you can cross reference against any CRM or analytics packages that are already identifying existing customers.

Setting boundaries

It depends on the complexities of your product, but typically 20-30 minutes is enough time to cover at least the main areas of function. Any longer, and you might encounter people not wanting to fit in an entire hour block into their schedule. If these recorded sessions are kept to just a half-hour, I find that a $25 is sufficient compensation for this duration of time, but your results may certainly vary.

In any type session, do iterate that this is neither a sales, nor a support call. You’re researching on how to make the product better. However, you should be comfortable on how to avoid (or sometimes suggest) workarounds to optimize the participant’s experience, giving them greater value of use.

Tools of the trade

For implementation of the questionnaire, I hacked the HTML / CSS from a Google Form to exist as self-hosted page but still pushing results through the matching form and input IDs to the extensible Google Spreadsheet.

There are a few tutorials that explain how to retain your branding while using Google’s services. I went through the trouble so I can share the URL of either the form or the raw results with anyone, without the need to create an account or login. As we discuss the sharing component of these user research efforts, this will become more important. Although closed systems like SurveyMonkey or Wufoo are easy to get up and running, the extensibility or a raw, hosted result set does not compare.

Insert a prompt at the end of the questionnaire for the user to participate in a compensated user research survey, linking to a scheduling applications such as Calend.ly. This application has been indispensable for opt-in mass scheduling like this. The features of gCal syncing, timezone conversion, daily session capping, email reminders, and custom messaging all are imperative to a public-facing scheduling board. Anyone can grab a 30-minute time slot from your calendar with just your custom URL, embeddable at the end of your questionnaire.

To really scale this user research effort to the point where it can be automated, you cannot spend the time trying to negotiating mutually-available times, converting time zones and following up with confirmations. Calend.ly allows for you to cap the number of participants who can grab blocks of your time, so you can set a maximum number of sessions per day, preventing a complete overload of bookings in your schedule.

As a part of the scheduling flow within Calend.ly, a customizable input field asks the participant for their Skype handle in order to screen share together, and I’d advise for the practitioner to create a separate Skype account for this usability effort. With every session participant, you’ll begin to add and add more seemingly random contacts, any semblance of organization and purity for your personal contact list will be gone.

Screen grab of Calend.ly booking utility.
Calend.ly booking utility – a publicly-accessible reservation system.

Calend.ly booking utility – a publicly-accessible reservation system.

Once the user is on the Skype call, ask for permission to record the call and make sure that you give a disclaimer that their information will be kept private and shared with no one outside the company. You might also add ahead of time that any support questions that come up, you’ll be happy to direct to the proper technicians.

Permissions granted, be sure to re-iterate to the participant the purpose and goal of the call, and provide them with a license to say whatever they want, good or bad–you want to hear it. Your feelings won’t be hurt if they have frustrations or complaints about certain approaches or features of your product.

For recording the call, there are plenty of options out there, but I find that SnagIt is a good tool to capture video, especially given the resolution and dimension of the screen share tends to change based upon the participant’s monitor size. When compressing the output, a slow frame rate of 5/10 fps should suffice, saving you considerable file size when having to manage these large recordings.

Tagging annotations

When you’re walking the participant through the paces of the survey, be sure to annotate the time started and any high/lowlights you see along the way. While in front of your desktop, a basic note-taking utility application (or even pad and paper) should suffice. This will allow you to go back after the survey is finished and pull quotes for use elsewhere, such as powerpoint presentations or similar.

I always try to write a running diary of the transcript and a summary at the end just to cover what areas of the application we explored, as well as a quick summary of what feedback we gathered. Summarizing the typed transcript and posting the relative recorded video files should take no more than 10 minutes, which will still keep your total per-participant (including processing) time to under an hour each, certainly manageable as a part of your greater schedule.

Share the love (or hate)

I want to make sure that these sessions are able to be referred to by the executive and product management team for use in their prioritization strategy. Setting up an instance of MAMP / WordPress on a local box (we’re using one of the Mac Minis that power a dashboard display) which allows me to pass around the link internally and not have to deal with some of the issues around large video file sizes being uploaded, as well as alleviate any permissions concerns with these sessions being out in the wild.

Screen grab of the session archive interface.
Our UX session archive, with hundreds of recorded and tagged sessions.

Also important is to tag these posts attached to these files when you upload them. This allows faster indexing when trying to find evidence around a certain feature or function. Insert your written summary into the post content, and you’ll be able to better search on memorable quotes that might have been written down.

These resources can be very good for motivation internally, especially among the engineers who don’t often get to see people using the product they continually pour themselves into. They’ll also resonate with the product team, who will see first-hand what’s needed to re-prioritize for the next sprint.

After awhile, you’ll start to get a great library of clips that you can draw knowledge from. There’s also a certain satisfaction to seeing the evolution of the product in the interface through these screengrabs. That which was shown as confusing at one time may now be fixed!

Follow-up

Fulfillment of a participant compensation can be done through Amazon or other online retailers; you can wire a gift card through an email address, which you’ll be able to scrape as a hidden field from the spreadsheet of user inputs. Keep a running list of those that you’ve reached out to and contacted for responses.

You might also incorporate contacts met during sessions described in the Guerrilla Usability Testing at Conferences article, so you’ll be able to follow up when attending the next year’s conference to recruit again. After enough participants and feedback, think about establishing a customer experience council that you can follow up on with specific requests and outreach, even for quick vetting of opinions.

Conclusion

This article first outlined the strategies and motivation behind the research, advocating creating an automated workflow of continually-scheduled screenshares with customers, rather than trying to recruit participants individually. This methodology was then broken down to distinct steps of recruitment via email, gathering quantitative and qualitative feedback, and automating an opt-in booking of the sessions themselves. Finally, this article went on to discuss how to best leverage and organize this content internally, so that all might benefit from your process.

User research is imperative to the success and prioritization of any software application (or any product, for that matter). Yet, too often we forget to consume or own product. Whether it be server log management as I’ve chosen, or apartment listing or ecommerce purchases, shake off complacency and try to spend 30-mins a week trying to accomplish typical user tasks from start-to-finish.

Also make it a point to conduct some of these sessions among those you work alongside; you’ll be surprised what you can find just by the simple repetition with a fresh set of eyes and ears. The research process and its dependencies does not have to be as intricate as the one listed above.

 

When your company starts to incorporate user opinion into a design and development workflow, it will begin to pay out dividends, both in the perceived usability of your application as well as the gathered metrics of user satisfaction.

 

Forms: The Complete Guide—Part 4

by:   |  Posted on

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.

How to Make a Concept Model

by:   |  Posted on

I can draw.

I went to art school. I studied painting until I fell out with the abstract expressionists and switched to photography. But I can draw.

What I cannot do is diagram. I always wanted to. I have models in my head all the time of how things work. But when it comes time to make a visual model of those ideas, I can’t figure out to to represent them. I find myself resorting to pre-existing models like four-squares or the Sierpinski triangle (I dig fractals.) For example:

Social-Architecture-Diagram

Other than the oh-god-my-eyes color choices, my social architecture diagram has deeper problems. For example, the ideas in it are limited to threes within threes because that’s the form triangles take. The model served to communicate my ideas well enough for the sake of my workshop, but… shouldn’t form FOLLOW meaning? If I had more than four elements for any section, I’d have to either collapse two, or fudge it in some other way. I was sacrificing accuracy for consistency. But I didn’t know how to make to make it better.

A concept model is a visual representation of a set of ideas that clarifies the concept for both the thinker and the audience. It is a useful and powerful tool for user experience designers but also for business, engineering, and marketing… basically anyone who needs to communicate complexity. Which is most of us, these days.

The best known concept model in the user experience profession is probably Jesse James Garrett’s “Elements of User Experience.” The best known in start-up circles is the lean startup process. Both of these models encapsulate the ideas they hold in such a memorable way that they launched movements.

If you wish to clearly present a set of ideas to an audience and represent how they fit together, a diagram is much more powerful than words alone. Dan Roam points this out in his latest book, Blah Blah Blah:

“The more we draw, the more our ideas become visible, and as they become visible they become clear, and as they become clear they become easier to discuss—which in the virtuous cycle of visual thinking prompts us to discuss even more.”

Concept models can serve many purposes. You can use concept models to show your teammates how a complex website is organized before the site is built…

Andrew Hinton’s model of a “virtual shared organizational ‘building’ where people spread all over the country were collaborating to run and participate in the org”.

… or to help teammates understand how the site currently works…

Bryce Glass’s concept model of Flickr use.

… or to show end users how a service works, to help sell it.

Biblios uses a concept model to help users understand the power of social cataloging. What it lacks in elegance, it makes up in clarity.

I teach user experience design, and my syllabus always includes concept models. Students of mine who do a concept model before working on the interaction design and information architecture always make better and more coherent products. The act of ordering information forces them to think through how all the disparate elements of a product fit together.

Stephen’s handout from the workshop on representing types of visual relationships. Advanced and useful thinking.

You can imagine how excited I was to take the Design for Understanding workshop at the 2014 IA Summit. Partly because I will go see anything Karl Fast or Stephen P Anderson talk about and having them together is Christmas come early. But mostly in hopes of learning a way to make a good concept model.

The workshop was brain-candy and eye-opening: They covered how the brain processes information and how ways of interacting with information can promote understanding. BUT I still couldn’t make a model to save my life. I didn’t know where to begin!

At lunch, Stephen was manning the room while Karl grabbed food for them. I had been struggling with a model for negotiation I wanted for a talk I was presenting later in the program. Seeing Stephen idle, I pounced and begged for help.

Stephan P. Anderson is author of Seductive Interfaces and the upcoming Design for Understanding. He’s also a patient soul who will put up with ham-handed diagramming and ridiculous requests. He started to sketch my model and tell me what he was thinking as he drew. Then I had my bingo moment: Stephen had forgotten what it was like not to know how to begin! This happens to all experts. After a while some knowledge is so deeply embedded in their psyche they forgot what it was like not to know. They then teach the nuances rather than the fundamentals.

I suggested we do a think aloud protocol while he made a concept diagram; he would draw, and I’d prompt him to talk about what was going through his mind. He was excited to have me reflect his thinking back to him so he could become a better teacher as well. We arranged to have a sketching session after the workshop.

 

Stephen Anderson draws; I do a think aloud protocol to capture how he works.

Later in the day, we met in the quiet hotel bar with wine and a sketchbook. I asked him what he wanted to draw. “Do you have something you are working on?” he asked. “That way I can focus on the model, rather than rethinking the ideas.”

Did I have a model I was struggling with? Always!  I shared my new theory of the nature of digital products. I’ll be writing that up in another article when it’s done, but for now, the short version is that one must iterate through the elements of digital design, which include the framework, interactions, information structure, and aesthetics. But a product doesn’t become an experience until a person interacts with it; your design cannot be known until you see what happens when a human shows up.

Stephen’s first step was to ask me about my goal for the model. I said it was for students and young practitioners to understand the interdependencies of the elements, so they have a more iterative approach. And for critics to be able to understand why things are different, both good and bad.

Next, he did what I’d call a idea inventory. He brainstormed more elements that might play into the model. He made sure no ideas were left out. He made notes of those he suspected might be important in the margins. He sketched as he thought, sometimes just making meaningless marks, as if warming up his hands.

He then carefully asked about each element in my theory, making sure he understood each. What was an information structure and what was a framework and were they different? I ended up telling a little story about a product to make sure he got what I was explaining. I began to draw too, encouraged by his easy scribbles.

Finally, Stephen noted the relationships of the items to each other. Were some things subsets of others? Were some overlapping, or resulting?

Playing with relationships (my drawing).

Once he knew what each item was, and how they were related to each other, he began to sketch in earnest. He said, “I always start with circles because edges mean something. They mean you have four items, or five. Circles leave room for play.” His circles quickly became blobs and then shapes.

I don’t know if he’d normally talk to himself out loud when not encouraged to do so, but it was fascinating to to hear him free associate concepts, then draw them out. A string of concepts became a string of beads; moving through an experience became moving through a tunnel; intertwined ideas were a braid. Any important idea got a drawing.

Here Stephen tries on various relationship metaphors, including moving through tunnels, holding something, string of ideas, braided together concepts.

Each time he completed a mini-model, he’d evaluate what was missing and what was working and take that insight to the next drawing. He made dozens of these little thumbnail drawings.

Stephen said, “one shape leads to another…a single word sparks a new representation—we’re always ‘pivoting’ from one thumbnail to the next…”

He pointed out what concepts were left out, or where they could be misinterpreted.

“You want to avoid 3-d, because it’s fraught with problems. You want to be able to sketch it on a napkin.” —Stephen Anderson, on keeping in mind the model’s goal

At one point, he became tapped out, and we spoke of other things. We stared out the window at the harbor, and I drank some of my wine, forgotten in the excitement of drawing and talking.

Then suddenly he started in again and produced a flurry of new drawings. I realized resting and mulling was important too. I was a bit annoyed with myself. An article doesn’t come out perfect in one writing session. Why should I expect a concept model to just materialize?

Finally he came to a stop, several pages filled with a jumble of images. We didn’t have a model, but we had many good directions. As we finished our drinks and headed toward the opening reception, Stephen told me, “You gotta get Dan Brown to do this, too.”

Dan M. Brown is best known in the user experience design community as author of Communicating Design and Designing Together. Both books benefit greatly by clear and succinct conceptual models, and the former even talks about how to use them in the design process:

Purpose—What are concept models for?
There really is only one reason to create a concept model: to understand the different kinds of information that the site needs to display. This structure can drive requirements for the page designs, helping you to determine how to link templates to each other. With the structure ironed out, you might also use the model to help scope your project—determining what parts of the site to build when.

Audience—Who uses them?
Use concept models for yourself. Ultimately, they are the most selfish, introspective, and self-indulgent artifact, a means for facilitating your own creative process.”

–Communicating Design: Developing Web Site Documentation for Design and Planning 2nd Edition, Dan Brown, 2010

Clearly, a guy I should be talking to!

The IA Summit was held in sunny San Diego in a hotel with not one but two swimming pools, so Dan had brought his family with him. When I asked him if I could watch him draw a concept model, he said, “I’m at the coffee shop with the boys around 6:30 every morning.”

You take what you can get.

The next morning Dan settled the boys in a corner with books, pastries, and an emergency iPad, and we got to work. We agreed he’d model the same concept, to control for variations. By now I had created a formula for the idea: (F+In+Is+Ae)+P=E. Framework, interactions, information structure, and aesthetics plus a person makes an experience. I was modeling in words as my friends were modeling in pictures.

I took Dan through the same story of an iterative product design process, since it had helped Stephen. I sketched it out. I felt like my hands were waking up from a long sleep, and they were eager to hold a pen now.

As I spoke, Dan wrote down key ideas and also began to scribble. He used the same process as Stephen: collecting the concepts then inspecting them for hidden complexity.

“A question I ask myself is ‘what needs unpacking?’ I can’t diagram an idea until it’s clear in my own brain.” —Dan Brown

He then took each concept and free associated all the sub-elements of the concept. He drew them out loosely, mind-map style.

Dan also started with the goal and wrote it out across the page.

He also asked explicitly who the model was for. To draw, he needed to visualize the audience. This reminded me of a recent presentation workshop at Duarte where we literally drew pictures of our audience. No work can be good unless you know who it’s for.

Duarte has you draw your audience before you design your presentation, so you remember who you are presenting to and how much attention they are (or aren’t) giving you.

Dan made sure he didn’t carry anything in his head: All ideas were put on paper as a note or a sketch. When he had to turn a page, he ripped it out to lay it next to the other pages. I realized how critical it was to have plenty of room to see everything at once. I saw the same technique of storytelling and drawing of ideas.

Around now, Stephen joined us. He was excited to see what Dan came up with, enough to also climb out of bed at the crack of dawn. I listened as the two diagrammers discussed the poster session and the strengths and weaknesses of the ideas that had been presented.

Dan said, “You can look at people’s posters and see their process. They are so close to their own narrative…In one poster, the key framework was rendered in a very pale text. It was a good story, but there are things you want to jump off the page. For her, my guess is those steps were so self-evident she didn’t see need to highlight them.”

 You have to have a beginner’s mind to explain to beginners.

“Speaking of beginner’s mind, so much of my design process is to throw it all out start all over again.” —Dan Brown

Dan Brown draws it all.

Now Dan began to model the concept. He emphasized the importance of sticking with very simple geometry–circles, squares, triangles, lines–not fussing with trying to find a perfect model at the beginning, just exploring the ideas and their relationships.

He also mentioned he begins with any concept in the model and doesn’t worry about representing order at first. He starts with what catches his interest to get familiar with the ideas.

Dan then deviated from Stephen by seeking the focal point. What concept held all the others together? What was the most important or key idea? He tried out placing one idea, then the other, in the center to see if felt right.

After scrapping one bowtie model, he paused. “I sometimes retreat into common structures and see how these common structures might speak to me. For example, time is one of those fundamental aspects, so I ask myself: How much do I need to show time here?”

He demonstrated by drawing swimlanes and sketched the ideas and their relationships in time.

Swim lanes for moving across the elements.

“Are there other elements you often look for, like time?” I asked

“People,” he replied. “People and time are familiar concepts, easy for an audience to relate to. By using them as a foundation for a model, I’ve already made it easier for people to ‘get on board.'”

He stared at the paper, deep in thought.

Stephen then pointed at the page. “What Dan did here,” he said, poking at where Dan wrote out goal and audience, “I did also but didn’t externalize. I was holding it in my memory, but I like having it on the paper better.”

Eventually Dan, too, was tapped out, and his sons began to play Let It Go on the iPad at higher and higher volumes. He separated his sons from the electronics and left to prepare for the swimming pool.

 

After Dan, I knew I wanted to try to get one more person to model. Since I was lucky enough to be at a conference full of diagrammers, I chased Joe Elmendorf of The Understanding Group. He had just given a talk on Modeling for Clarity that my friends were raving about. And, with my luck still holding, I got to have breakfast with him. Happily, at 8 am this time.

Joe Elmendorf brings pace layers into the discussion. My handwriting is the ballpoint; his, the nice black ink pen.

Again, I saw what were becoming familiar concepts (inventory, inspection, relationships, then talk-draw.) I then focused on how he differed from Stephen and Dan. He choose to use the title of the diagram as an element. He did not iterate as widely as Stephen. He was the first person to argue with me about the validity of my theory, which was a great way to understand it (and benefited me by making it better!).

As well, he reinforced something Stephen had mentioned in his workshop and that Dan was obviously doing: Joe had a large mental library of typical models to draw upon, which got him started. Stephen keeps a Pinterest board full of inspiration, if you want to start your own “lego box” of models.

Stephen’s Board http://www.pinterest.com/stephenpa/the-visual-display-of-information/

Overall, there were so many familiar patterns I saw in his approach, the differences were more interesting than important. I had my answer. I knew how they did it.

On the last day of the conference in the afternoon, Stephen and I were scribbling further on the model, playing with petals for the elements, when Dan Willis joined us. Dan is also a master of models as well as an inveterate sketcher.

Stephen further refining ideas, always generating.

Although Dan declined to diagram for me, claiming brain fatigue (a reasonable claim at this year’s Summit) he pulled up a chair and sat sketching next to us. It was companionable, to sit and talk and draw ideas. We moved back and forth from discussing life to discussing the ideas, teasing, joking, drawing. As we chatted, I realized this was a part of the secret. You need a thinking partner. Sometimes it’s paper, sometimes it’s friends; but it’s best when it’s both. It doesn’t always matter what you draw, just that you draw.

Dan Willis drawing nearby makes me happy.

Dan Willis sketch from a tweet

Our brains work better when our hands are busy.

Later, sitting in the back of a session, I lobbed a model at Stephen, and he shot back with his own.

Refining an idea, mine on left, Stephen’s on right.

Then I saw another step, one which Dan had alluded to when he mentioned the poster with the key point too pale to read: You have to refine the model to communicate effectively. Type, color, and labels are all a key part of the communication process. While the model did stand alone without the color and type, adding those–and most especially getting labels right–made the model more effective.

After getting home, I started sketching how concept models were made. I drafted this article and then asked my friend Dave Gray if he’d do a quick edit. Dave was the founder of Xplane, a company that used diagrams–concept and other–to transform companies. Dave has been a proponent of visual thinking and clear modeling for years, and I consider him the master of making ideas visible.

Life then intervened and this article sat. I was busy with several things, including Lou Rosenfeld’s 32 Awesome Practical UX Tips. Dave presented right before me, and watching him sketch, I realized I just had to get one more diagramming session in. It was not enough to have him comment, I needed to see him draw. I was grateful I did; otherwise, I would have missed a crucial piece of the puzzle.

Dave Gray draws on cards so he can rearrange, manipulate, and overlay the concepts.

We hopped on a Google Hangout and he also drew out that same darn design model for me. I saw familiar patterns in his approach: inventory, unpack, relationship exploration. But he added a critical step I hadn’t thought of before: Test the model.

He’s currently writing a book on Agile, and it shows. He said, first design the test, then design the thing. For the model, he suggested using his WhoDo Gamestorming tool as a way to design a test of the effectiveness of the model. He lists who the model is for and what they will do if they understand the model.

If Dave didn’t fully understand the audience for the model, he might do an empathy map for those people.

Designing a test of the model’s success radically clarified the goals for the model. Testing it would make sure it did what you wanted it to do.

So then I sat down to make a model of how to make models. And it came easily.

  • Determine the goal: How will the model be used, by whom? What is the job of the model? To change minds, explain a concept, simplify complexity?

  • Inventory the concepts: Brainstorm many parts of your concept. Keep adding more in the margins as you go.

  • Inspect the concepts: Are there many concepts hiding in one? Do you really understand each idea?

  • Determine the relationships: How do the concepts interact?

  • Decision point: Do I understand the ideas and what I’m trying to communicate? 
    Test: Ask yourself if the model “feels” right.
    If yes, then continue.

  • Iterate with words and pictures: Talk to yourself and draw it out!

  • Evaluate with yourself/the client: Keep making sure the drawings match the ideas you wish to communicate. Don’t punk out early! Rest if you need to!

  • Decision point: Does my audience understand the ideas and what I’m trying to communicate? 
    Test: Can my audience answer key questions with the model? 
    If yes, then continue.

  • Refine: Use color, type, line weight, and labels to make sure you are communicating clearly.

A model for making models.

The concept model is invaluable. But like so many useful things, it takes time to make.

When my daughter first started drawing My Little Pony, she expected to start at the ears and draw it perfectly down to the hooves. She was angry when it didn’t work that way, and it took some convincing to get her to block out key shapes then refine the whole, and to use pencil before ink. When I sat down to make a concept model, I made the same mistake! I’d start in Powerpoint or Grafio, and expect perfection to flow from my mind.

No more! Stephen, Dan, Joe, and Dave taught me to play, explore, refine, test, and play some more until the result was right. Thank you all!

Now go make a model!

Postscript

If your hands do not obey your brain, and/or you need more ideas for shapes and relationship models, I recommend Dave Gray’s Visual Thinking School.

See my interview with Dave on how he’d make the experience model

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

Grouping

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 placehold.it 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:

$(this).parent().parent().find('.help').show();

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

Phew!

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.

Conclusion

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

Text

Type some text

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

Password

Password

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

Email

Email address

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

Keyboard displayed based on attribute
Keyboard displayed based on attribute

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

Invalid email address notification

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

URL

URL

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

Keyboard displayed based on attribute
Keyboard displayed based on attribute

Again, desktop browsers validate these automatically:

Invalid URL

Phone number

Phone number

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

Keyboard displayed based on attribute
Keyboard displayed based on attribute

Number

Number

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

Keyboard displayed based on attribute
Keyboard displayed based on attribute

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

Spinner

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

Autosuggest

Empty:

Empty autosuggest

Typing:

Autosuggest while typing

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

Other types

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

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

The rest

Checkboxes

Checkboxes

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

Radio buttons

Radio buttons

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

Sliders

Sliders

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

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

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

Slider with indicator

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

Drop-down lists

Closed:

Closed dropdown list

Open:

Open dropdown list

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

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

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

Textareas

Textarea

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

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

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

Buttons

Buttons

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

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

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

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

Other clever Foundation stuff

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

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

Input and label

You can see the code for that here.

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

Input with button

The code for that one is here.

Important attributes

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

autocomplete

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

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

autofocus

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

disabled

Disabled

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

maxlength

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

multiple

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

Select multiple

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

pattern

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

placeholder

Placeholder

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

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

required

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

Required field

tabindex

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

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

Special considerations

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

Autocorrect fail

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

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

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

Conclusion

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

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

Managing Website Accounts in Cross-Platform Contexts

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 Mint.com does–access to general information like blog posts and commentary should be provided in a mobile friendly format to users of their native apps–which Mint.com does not do. Since all the major mobile platforms have web viewing features built into their native app libraries, Mint should make its existing mobile friendly web content available to both website users and people using their native apps.

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

Streamline account creation

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

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

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

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

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

Using device features to enrich the experience

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

Simplify account and profile management

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

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

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

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

Allow password reset

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

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

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

Social media and user accounts

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

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

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

Fatal operations on a mobile device

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

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

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

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

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

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

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

Conclusion

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

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

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

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