1 Keyboard Shortcuts at the Atlassian Design library.
--- # Captcha - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/Captcha - Examples: 13 screenshots on the page ## Problem summary The application needs to verify that the data submitted originates from an actual human and not a robot. ## Usage Websites featuring the ability for visitors to comment, register as a user, or otherwise actively post content on the website are often exposed to attacks from spam-robots. The content posted by such spam-robots can be compared to spam sent by e-mail. The main purpose of spam-robots on the web is to create and spread links to a specific website, in order to increase the websites search rating on search engines like google.com. These spam-posts rarely have anything to do with the subject of the website, hence the spam categorization. To avoid such spam, captchas are introduced. The whole idea behind Captchas is to create a way to distinguish real human beings from automated robots. - Use when your web application experiences attacks from malicious web-robots trying to post spam-content on your site - Use to protect your website from automated robots - Use when the capability to post content to your website is not blocked by the need to be logged in. Registration processes are included. ## Solution The most popular form of Captchas are images that represent letters and numbers inside. The user is prompted to write in a separate form field what the image reads in a separate form field. To prevent spammers from using OCR software to read the image, the image is manipulated in different ways, which makes it hard for computers while maintaining readability for humans. If the user succeeds in typing what the image says, his content is posted to the website. If not, the action will be refused. It is common to allow a number of tries to enter the captcha text, as some captcha images are even unreadable to humans due to the strong image manipulation is has been exposed to. ## Rationale Captchas are short for ‘Completely Automated Public Turing test to tell Computers and Humans Apart’. The whole idea behind Captchas is to distinguish humans from computers letting the user perform an action a computer can’t. A captcha is a simple Turing test. There is a fine line between making a captcha unrecognizable for OCR scanners and still readable for human beings. Readability for the human has to come first. Other problems with implementing captchas to protect your website include a lock-out from visually impaired users as they can’t use voice software to speak what the captcha reads. Other forms of protection from malicious spammers are asking questions like “what is 2 + 3” or “what is two plus three” or using voice captchas, --- # Rule Builder - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/rule-builder - Also known as: Query Builder, Smart Filter, Segment Builder - Examples: 6 screenshots on the page ## Problem summary The user needs to, often repeatedly, conduct a search query based on a custom set of rules ## Usage - Use to build a search query based on several conditions - Use to save a segment rather than static selection - Use to help users build dynamic lists, making the selected rules static rather than the actual search result - Use when a search query involves an unknown number of undefined conditions - Do not use when users can find what they need using only a text input. - Do not use when the type of search query requires the same types of variables to be chosen every single time. ## Solution Let the user build a dynamic list of rules to narrow down matching results from a dataset. Each rule is represented by a separate line or box and divided from each other vertically. ### Any or all The user must specify whether a rule is needed (AND) or is optional (OR). A common approach to simplify the implementation of this pattern is to provide an option to choose whether **all** rules chosen should be matched – or just **any** of the rules. A more nuanced approach is to allow *each rule* to be a required match or just an optional match. ### Treat each rule type differently? As the user choses the kind of rule he or she wants to impose, those rules can have very different impacts on what corresponding data needs to be entered for the rule to give meaning. This is why many rule builders provide smart mini-forms that vary depending on what kind of rule is selected. One rule might impose a text search, wherein options like “contains”, “does not contain”, “matches”, or “do not match” make sense. Other rules could be to select an option from a dynamic list or to provide numeric- or range inputs. ### Adding and removing rules The smartest feature rule builders provide is to dynamically add and remove rules. The “Add” button is typically located either directly under the rules and remains so as new rules are added or removed, or it located alongside the remove rule button. In the case of the latter, this allows for new rules to be inserted directly beneath a desired rule. Removing a rule is most often allowed at the beginning or end of the line the rule is presented on. ## Rationale A rule builder allows a user to specify unique conditions to discover and group items across one or more datasets. The results returned by an active rule can be dynamic in nature as its related datasets change over time. An active rule can trigger a set of actions to be performed when the conditions, criteria and values of the rule are met. Rules sets can be grouped into discrete units and linked together with condition logic to create highly complex rule conditions. ## Discussion ### Pattern authors - [Richard Barrett](http://richardbarrett.co/) - [Anders Toxboe](http://ui-patterns.com) ## Sources1 UI design for rule builder by Two Rivers Consulting
2 Interesting StackExchange discussion
--- # Inplace Editor - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/InplaceEditor - Also known as: Direct Manipulation - Examples: 1 screenshots on the page ## Problem summary The user needs to quickly and easily edit a value on a page ## Usage - Use when the user only needs to edit one value (or very few) and not many - Use when the value the user needs to edit is of a simple format, i.e. a text string, in a dropdown box. - Use if you want the user to be able to edit a value without actually going to an administration page, but by staying on the same page. ## Solution Let users edit values in the same place as they are displayed. Provide an easy way to let users edit parts of a page without having to be redirected to an edit page. Typically, hover effects are used to invite editing. The Inplace Editor pattern allows for localized editing of elements on the fly. The pattern provides ease of editing by placing the controls right next to the elements they affect. For example, when in editing mode of an application, a page title element will display editing controls when the user hovers their mouse over it. The elements background color is highlighted and a tooltip is shown prompting the user to click the element to edit it. Once the user clicks the element, it is transformed into an input field (text, dropdown, etc.). A save button and a cancel button are also displayed. Often, the input field matches the styling of the original element. If the original element was a header written in size 20pt, the size of the font in the input field would also be 20pt. This styling is mirrored to ensure that the user can connect the original element with the new editable The user can then edit the value of the input field (which is the same as the original elements value) and click save or cancel. If ‘save’ is clicked, the value is saved through an AJAX call to the underlying database, the value of the element is updated and the element is returned to normal view. If cancel is clicked, the element is changed back to the original view without any changes. This pattern is often combined with AJAX techniques, which is an asynchronous call to the server through javascript that does not require a refresh of the page. There are many javascript libraries available online that deliver ready-to-use inplace editors. ## Rationale An in-place editor provides an easy way to let the user edit parts of a page without having to be redirected to an edit page. Instead, the user can just click around on a page and edit the elements he or she wishes to change – without reloading the page. --- # Preview - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/LivePreview - Also known as: Live Preview - Examples: 5 screenshots on the page ## Problem summary The user wants to check how changes in form fields affect an end result as quickly as possible. ## Usage - Use when you want to provide the user with a real-time preview of what he or she is creating - Use when it is hard for the user to comprehend how the final output will be without having a preview to reference - Do not use when the input is straightforward and the resulting output does not depend on a specific layout ## Solution Let users preview consequences of an action before committing to it. Update a preview of what modifying a form will result in throughout the entire interaction with the form. Instead of waiting for the user to submit the form, the changes are shown immediately in a preview. Each user event of significance results in a browser-side processing. ## Rationale Previews make it easier for users to decide whether or not to commit to a change and thus invite safe exploration and playful creativity. Show feedback immediately in live previews to further spark fun, play, and exploration. The result is increased interactivity. The user does not need to wait for page reload on a form submit to find out whether data was inputted correctly into the form. The feedback is immediate. --- # Autosave - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/autosave - Examples: 1 screenshots on the page ## Problem summary The user wants to keep their data safe and saved while focusing on working without having to remember to do so. ## Usage - Use when you want to help the user focus on producing great content without worrying about whether their data is safe and saved. ## Solution Prevent accidental data loss by automatically saving user input at fixed intervals or at events of interest. Consider at what frequency it makes sense to auto-save inputted content for your application, and at what events it makes sense to trigger an auto-save. The most obvious event is clicking the save-button, but the event of moving the focus to another field might also be interesting to observe. ### The save button To better guide users as to what state their document is in, consider changing the label of the save button from “Save”, when the form contains uncommited changes to “Saved” when the current form represents what has been saved in storage. ## Rationale Let users worry about creating great content rather than about loosing it. Removing the save button entirely can create fear, so consider keeping it around to make users feel safe. Leave an unobtrusive trace of conducted user actions and consider complementing with the Undo pattern. ## Discussion When implementing auto-save functionality, consider not removing the “Save” button. Users tend to panic, when there is no “Save and close” button. Even though the “Save” button does nothing or only closes the window, it provides confidence and reassurance in users that their data is safe. It’s an issue of trust. Did the system hear me? Am I sure that I am sure? --- # Password Strength Meter - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/PasswordStrengthMeter - Examples: 5 screenshots on the page ## Problem summary You want to make sure your users' passwords are sufficiently strong in order to prevent malicious attacks. ## Usage - Use when you want your users to choose passwords for their user accounts that are hard to break or guess by either human or computerized help. - Use when you want to increase the complexity of your users’ passwords and raise the barrier for attackers tampering with your system. - Use when you want to be sure that your users know what a good password is and that their chosen password follows such guidelines. ## Solution A password’s strength is measured according to predefined rules and is displayed using a horizontal scale next to the input field. If the password is weak then only a small portion of the horizontal bar is highlighted. The greater the strength of the password the more the horizontal bar is highlighted. The password strength is also appropriately indicated by coloring the bar in a color associative with good or bad: Green indicating a strong password and red indicating a weak password. ### How strong a password? The definition of a strong password can be intensely argued. A forced complex password at first glance only spells increased security, but forcing too complex and rigid rules on password can have the opposite effect. As passwords are forced to be complex, they also become increasingly harder to remember by the user. This occasionally leads to a self-destruction of the increased security, as some users simply write it down on a small sticky note and paste it up on their screen in order to remember their new complex password. This is especially a problem in places with the policy of forced password renewal every 3 months. ### What is a strong password? With the above mentioned in mind, I should stress that a sufficiently strong password does not necessarily need to fulfill all of the rules below, but merely a few will do. Consider the following rules, for each rules followed add a point to the passwords strength level (so that 0 points is the weakest, and 5 is the strongest). UI-patterns.com defines a strong password when it…: - Has more than 8 characters - Contains both lowercase and uppercase letters - Contains at least one numerical character - Contains special characters - Has more than 12 characters This would result in 6 levels of password strength depending on how many of the above mentioned criteria are being met. ### Dictionary attacks While the above mentioned password check can easily be done using only client-side javascript, it does not prevent against dictionary attacks. To ease the memorization of passwords, people tend to use real words as passwords and merely substitute characters with numbers or special characters. An example of such a password could be “P@ssw0rd”, which really isn’t a strong password. Modern password breaking software is fairly good at guessing such number/letter substitutions. To check against such strength, you would need to do ajax calls that would check with your own dictionary if the password was strong or not. ### Choosing an appropriate level of password strength You need to determine the password strength and complexity according to what you want to protect. You need to draw the line somewhere. For 99% of the content out there it can easily be argued that merely the first 2 or 3 rules mentioned above will be sufficient. ### General guidelines on choosing a password - Use a password of a seemingly random selection of letters and numbers - Use a password that you can type without you having to look at the keyboard (decreases possibility of people stealing your password) - Change your password regularly - Do not use your network ID in any form (capitalized, reversed, doubled, etc.) - Do not use your first, middle or last name or anyone else’s in any form. - Do not use your initials or any nicknames you or somebody else might have. - Do not use a word contained in any dictionary (English or foreign), spelling list, abbreviation list, etc. - Do not use information that people can easily obtain about you (license plate, pet name, date of birth, telephone numbers) - Do not use password of all alphabetical characters or only numeric characters – mix them up. - Do not use keyboard sequences (for instance qwerty or asdf) ## Rationale By showing a password strength meter beside the password field, the user is forced to consider using a password with an appropriate strength. By putting a minimum level of password strength you can even use the password strength meter to force a heightened security to your website. Using a password strength indicator on the website, adds another level of security is added to the site. This not only makes the current users of the site feel more secure, but potential clients might use this as a requisite when deciding to conduct business with a company. --- # Fill in the Blanks - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/FillInTheBlanks - Also known as: Natural language form - Examples: 16 screenshots on the page ## Problem summary The user needs to enter data into the system ## Usage - Use when you find yourself creating labels for input fields that do not really explain what the input field is all about. - Use when you find yourself creating long and complicated labels for input fields, which in turn makes it hard for users to understand. - Use when you can possibly express the context of the input field by placing it in a sentence. - Use when filling out the input field is mandatory or strongly appreciated. Leaving parts of a sentence unfilled creates annoyance in the user. - Use when you have a relatively small set of input fields to place as part of the sentence. If you have many input fields, placing them all in a sentence can seem tiresome for the user, as the sentence structure forces the user to read all sentences and place all input fields in the context of those sentences. - Do not use if you have many fields that are not required to be filled out. ## Solution Order input fields in the form of a sentence with input fields as blank spaces to be filled by the user. Write a sentence and let the user fill in the blanks of the sentence by selecting or filling out input fields that are in place of words. When the input field is not inserted at the end or the beginning of the sentence, it is important for the general readability and understandability of the interface, that the input fields does not take up more space than the height of one text-line. Input text boxes, and drop-down lists therefore work the best for this sort of usage. The pattern is often seen in applications that filter large lists out by conditions. In Apple’s iTunes, the pattern is used to create conditions for smart playlists (See examples at bottom of page). The biggest drawback of the pattern is its poor ability to be localized into different languages as the placement of each input will possibly have to be rearranged to match the grammar of each language. Using “Fill in the blanks” in this way hinders immediate conversion of a user interface to other languages. ## Rationale We all know how to finish a sentence. By inserting input fields into a sentence of words, the user interface is made self-explanatory, possible misundestandings are minimized, and the context is understood more clearly. Sometimes, it can be hard to find a describing label for an input that does not alienate the user to the system. Consider the example in the bottom of the page from the Ruby On Rails wiki. Here, both the submit button (“Save”), the input field for the author name, as well as a back in history link are presented all in the same sentence. These three options could have easily been represented on separate lines with a separate label for each option. Instead, the three options are presented as a sentence, and thus put in context of each other. Furthermore, the example above uses the [Input Prompt pattern](/patterns/InputPrompt) to encourage users to fill out the text field. The “Fill in the blanks” makes the interface somewhat self-explanatory. Our semantic capabilities as human beings allow us to fill in the missing parts of a sentence. --- # WYSIWYG - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/WYSIWYG - Also known as: What You See Is What You Get - Examples: 1 screenshots on the page ## Problem summary The user wants to create content that contains rich media and formatted text but does not the knowledge or time to write HTML. ## Usage - Use when you want to give the user a clear indication of what their content will look like when it is published. WYSIWYG is an acronym for **W**hat **Y**ou **S**ee **I**s **W**hat **Y**ou **G**et. - Use when the users of a site are not comfortable with formatting text using HTML codes or a markup language such as [textile](http://textism.com/tools/textile/) or [markdown](http://daringfireball.net/projects/markdown/). - Use to lower the barrier of letting your users add formatted content to your site. - Use when you want an easy way to integrate media into the formatted content of your site that does not require HTML or any other syntax knowledge. - Use when the user is inclined to spend time correcting small details on their content. WYSIWYG allows users to see formatted results as they edit, this increases their confidence and allows for quick and good looking results. - Do not use if you want to keep the HTML syntax clean. Many WYSIWYG editors are known to produce bloated and untidy HTML code. - Do not use if you want the editor to function in all browsers. WYSIWYG editors rarely support all browsers, and if they do, it is often only the latest releases of the browsers. ## Solution There are many javascript libraries available online that will convert a `` HTML element into a fully functioning WYSIWYG editor. The editor displays a work area that is both input and the final formatted output. The content is stored as HTML in a database. Editors can be customized to your user’s needs. You can disable unnecessary functions. You might choose to not allow image inserts, tampering with font color or size – or even force the user to only use a predefined list of CSS classes. ## Rationale WYSIWYG (What You See Is What You Get) was initially introduced in word processors such as WordPerfect and Microsoft Word. It was then a revolutionary way to write documents, where the editor on the screen mimicked the result *in print*. Recently, WYSIWYG editors were introduced to forms on the web. Previously, long text was inserted into `` fields, with no formatting options what-so-ever. WYSIWYG editors now allow the input to mimic what will be seen *on screen*. --- # Input Feedback - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/InputFeedback - Also known as: Confirmation notice, Error notice, Alert, Inline Form Validation - Examples: 21 screenshots on the page ## Problem summary The user has entered data into the system and expects to receive feedback on the result of that submission. ## Usage - Use when you want to provide feedback to the user upon submitting content to your site. - Use when you want to notify your users about errors that happened during form submission. - Use when you want to let your users know that everything went as planned upon content submission. ## Solution When users submit content to your site via forms, errors in the are bound to happen from time to time. The goal of this pattern is to improve the user experience by minimizing input errors. A paradigm called data validation is well suited for catching errors at the time of submitting a form. A common way to tell if data validates is to set up rules for each input field in the form. The data entered must pass these rules to be considered valid. Such validation rules can be: - **Validate presence of content** – at least *some* content *must* be entered - **Validate exclusion of content** – prohibited values – for instance inserting ‘admin’ as username - **Validate inclusion of content** – data must contain certain data or must be within a certain range - **Validate acceptance** (of for instance terms of service) – often with a checkbox - **Validate confirmation** – two input fields needs to match – seen with for instance passwords - **Validate format** – an email for instance needs an ‘@’ sign and a number of dots \- for instance that the user must be above 18 year of age. - **Validate length** – A password must in many cases be at least 6 characters long. - **Validate uniqueness** – Many systems only allow one user with a given username If the data submitted by the user validates, it is good practice to let the user know that everything went as planned. Even better, redirect the user to a page, where he or she can see the newly submitted content in a context. However, if the data submitted by the user does not validate, an error message should be presented to the user explaining how to correct the data and request for a re-submit. Such an error message should explain that: - **An error has occurred**. Display box at the top of the page (so that the user does not need to scroll the page to find out that an error occurred), preferably colored red to signal an error. - **Where the error occurred**. This can be done by listing the fields that caused the error in the error message, as well as highlighting the fields (by changing their colors) that caused the error. - **How the error can be repaired**. Provide information on what needs to be different in order for the field to validate. This can either be listed in the top error box or directly next to the field causing the error. The visual representation of the input feedback should correspond with the message you want to give. If the submission went successfully, consider letting the user know in a green box. If the message is neutral, a color often used is yellow. If something went wrong, red is often used. But beware – red means danger – is the user experiencing a dangerous situation? ## Rationale As the user fills out a form on a web page, he or she is conducting the process of converting mental data structured in one way to a written form structured in another way. As all humans do not think alike, we are bound to enter the data in different ways as we try to convert our individually structured data to a shared structure defined by the system. Data entered in web forms is prone to contain errors, which we must be prepared for in our design. The user must be made aware of the fact that the data entered did not match the structure that we designed for. Using visually distinct feedback notices, the user will be made aware of such errors and how to correct them. ## Discussion It can be argued that you should focus more on preventing errors *before* the user submits his or her data than on providing a good error message *after* data has been submitted. Consider constraining input with select boxes. Consider the language of your error messages, as these may have an emotional impact on your users. What tone of voice is appropriate for your users? ### Provide clear feedback after every action Users will feel more confident and informed when they receive feedback from the system. Feedback includes notifications, dialog message boxes, colored or disabled buttons, loading animations, inline alerts, tooltips, hover effects and so on. Bridge the gap created between performing an action and evaluation of the system after an action. --- # Calendar Picker - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/CalendarPicker - Also known as: Date picker, Date selector - Examples: 8 screenshots on the page ## Problem summary The user wants to find or submit information based on a date or date range ## Usage - Use when the user wants to easily choose a date or date range in order to submit, track, sort, or filter data. - Do not use in isolation, when the user is more familiar and efficient with another way of inputting a date. Some users prefer inputting a date via a text field. - Do not use when the date to be inputted is more easily inputted via writing the date as text – an example is birthday (18, 30, 50, or 70 years back – requires many clicks for selection) ## Solution The calendar picker is activated in a variety of ways: - When clicking a link prompting for selecting a date - When selecting an field for inputting a date - When clicking a calendar icon most often placed next to the field used for inputting a date On activation, a box with a month-calendar is displayed on the current page, prompting the user to select a date in the box. It is most common to only show one month, but some interfaces show up to 3 month calendars next to each other to ease the click-burden of the user and provide a better overview. ### Shortcuts The month-box calendar comes with several different shortcuts: - Select a date - Go to the previous/next month - Go to the previous/next year - Go to today (Especially important when today’s date is not the default) - Close the calendar picker ### Locking-in the period of selection For some interfaces, it makes sense to not allow the selection of certain dates. An example often used is to only make it possible to select banking days, days in the future, or days within the few forthcoming months. ### Two ways of inputting data: speedy and easy When designing for efficiency in web application, an area that often gets little attention is the contexts of input. On most desktop computers the most common way of inputting data is via keyboard or mouse. On mobile devices touch, keyboard and camera are the most common input methods. Using a calendar picker is an easy way of inputting a date. But also consider a quick and effortless way to input a date – one were the user does not need to switch between input devices but can rather accomplish their task with a single input device. For accommodating text inputs, consider using the [Forgiving Format](/patterns/ForgivingFormat) pattern to lessen input errors. ### Good defaults Use the [Good defaults](/patterns/GoodDefaults) pattern to achiee better data and spelling accuracy on input by pre-selecting appropriate dates. The defaults you pre-select will depend on the context but will most often be the current date or time. However, If you were designing a public transport route planner, you might default the start time to a half hour from now, as most travellers won’t be starting their journey right away when searching for a fare. ### Check date range validity If the user is selecting a date range, it is good practice to never let end-date be before the start date. That means listening to the start-date for changes and changing the end-date if the start date is set to anything bigger. ### Display complete weeks Display complete weeks, even when a month does not begin at the end of the week. Grey out visible dates from previous and next months, but be sure they are still selectable. ### Make link targets big Make sure that link targets are big and thus easy to click on. ## Rationale The calendar picker is a familiar graphical interface that is commonly understood among users. It helps the user easily choose a date or date range for use in submitting information or filtering data. ## Discussion ### International considerations In some countries it is typical to display a calendar with Sunday as the first day of the week, where in many European and Asian countries, Monday is typically depicted as the first day of the week. Some countries (E.g. Germany and Scandinavian countries) use week numbers for general planning purposes. In these countries, using the week number is almost as common as using the month name for describing a date range. Consider displaying the week number for each week row. --- # Morphing Controls - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/morphing-controls - Examples: 1 screenshots on the page ## Problem summary The user wants to only be presented with controls available to the current mode ## Usage - Use when some controls don’t need to be displayed at the same time - Use when you want to declutter the screen with unnecessary and unavailable controls - Use when your user experience contains several modes (playing/pause, on/off) ## Solution Information presented and actions available in a user interface element depend on its mode. When a video is paused, the play command is available, but pause is not. Design affordance in each mode toward the most common or wanted interactions and emphasize asymmetry, incompleteness, or something being wrong to push users toward changing modes. Be sure to keep a consistent look between each state of the control that morphs. Font and text size should stay the same, but colors may differ. Morphing Controls work well with binary actions, such as: - On/Off - Like/Unlike - Follow/Unfollow --- # Expandable Input - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/expandable-input - Examples: 1 screenshots on the page ## Problem summary The user wants to experience a main interface with as much screen real estate and with a minimum of distractions ## Usage - Use when you want the main focus to be on the main interface rather than its input controls - Use when you want to keep distractions out of the main interface ## Solution Expand the size of input fields as they come in focus or are filled with content Design your controls in two modes: expanded and contracted. As the user taps a contracted control, it expands to its larger size. This can help keeping secondary functions out of the way until the user is in need of them. ## Rationale Expandable inputs can help unclutter user interfaces by staying out of sight until needed. For multiple purpose user interfaces, it can be helpful to let optional actions, such as searching, posting, or commenting, attract a minimum of attention. --- # Settings - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/settings - Also known as: Options, Preferences - Examples: 2 screenshots on the page ## Problem summary The user needs a central place to indicate preferences for how the application should behave ## Usage - Put preferences in the Settings area, when they are used by the majority of users - Put prefernces in the Settings area, when they are used by a minority of users, but are essenatial to supporting their needs. - Use to provide a place for infrequently accessed preferences. - Use to capture user preferences - Do not use settings for frequently accessed actions. Move these to a toolbar. ## Solution Let users indicate their preferences for how your product should behave. Provide a central place for users to customize your product to their specifications. Keep configurable options well-organized, predictable, and manageable in number. Group and move less important settings to their own screens. ### Provide an overview Let the user be able to quickly understand all available settings and their current values. If there are many settings to comprehend, prioritize the ones most likely to interest users. Group and move less important settings to seperate screens. ### Good Defaults Consider good initial values for preferences – choose the default most users would choose and be neutral and pose little risk. ### When to group To avoid in-comprehensive lists of preferences, consider [clustering](http://ui-patterns.com/patterns/Chunking) settings into multiple shorter lists. Good heuristics are (you might change numbers): - **7 or fewer preferences:** Don’t group at all. - **9 to 16:** Group related settings under two or more section dividers. - **16 or more:** Consider constructing subscreens, but keep a consistent terminology in mind: make sure titles of subscreens match the label of the setting which opens it. ## Sources1 Settings Design Pattern at the Google Material Design spec.
--- # Forgiving Format - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/ForgivingFormat - Examples: 6 screenshots on the page ## Problem summary The user needs to quickly enter data into the system, which then in turn interprets the user's input. ## Usage - Use when the more explicit select boxes, radio buttons, and checkboxes make entering data a too complicated process for the user to engage with the system. - Use when the time it takes to complete a task proportional exceeds the importance of the goal the user wants to accomplish. - Use when the input you want to collect is relates to one topic. For instance a physical location or an event with a given start time. - Use when the expected user input can be somewhat easily interpreted by a computer program. - Do not use when the user can possibly ask or input anything. Only use for a narrowly defined purpose. ## Solution Allow users to enter text in their own format and syntax, and let the system interpret it intelligently Let users focus on getting things done rather than typing in things correctly. Lower the barrier for users to interact by allowing a broad spectrum of formats and syntaxes to be inputted. Consider nudging users to provide more easily interpreted information by paying attention to how you ask for input. Transfer the problem inputting data from a user interface problem to a programming problem. Behind the scenes, an interpreter checks for different word patterns, and converts them into a formatted value. ## Rationale Using the forgiving format pattern saves space and decreases the barrier for the user to interact with the system. Depending on how widely defined the input topic is, it can be increasingly hard for the backend program to interpret the input field. The success of this pattern has much to do with how information requested – how the user is prompted. --- # Undo - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/undo - Also known as: Multiple Undo, History, Global Undo - Examples: 1 screenshots on the page ## Problem summary The user wants to revert a mistaken input ## Usage - Use when you want to provide users with more confidence and willingness to play around - The more costly it is to lose data, the more important it is to provide undo. - Whenever there is an opportunity to lose work, the program should allow undo actions. - Never use a warning when you mean undo. ## Solution Allow users to easily reverse their own actions ## Rationale Users aren’t perfect – they tend to make mistakes. Promote safe exploration and playfulness by providing confidence that mistakes aren’t permanent. Multi-level undo lets users incrementally construct and explore work paths quickly and easily. The more costly it is to lose data, the more important it is to provide the opportunity to undo. ## Discussion A great side effect of utilizing the Undo pattern, is that it provides users with more confidence and more willingness to try new and different things. By promoting trial and error, users are able to learn and master your application more quickly. ## Sources1 Undo Design Pattern at Quince
2 Undo Design Pattern at Patternry.com
3 Multi-level Undo Design Pattern by Jenifer Tidwell
4 Goodbye Back Button by Michael Zuschlag
5 The importance of Undo by Paul Boag
6 Never Use a Warning When you Mean Undo by Aza Raskin
--- # Input Prompt - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/InputPrompt - Examples: 5 screenshots on the page ## Problem summary The user needs to enter data into the system ## Usage - Use when the label of an input field does not fully explain what should be filled into it or when using such a label feels like over-explaining the interface. - Use when an example text or question answers what should be filled into an input field just as well as a label. - Use when you want to save the space that a label otherwise takes up. - Use in combination with a label, to further explain what kind of input is needed. ## Solution An input field is pre-filled with example text or a question that prompts the user with what to do or type. The Input Prompt pattern is most successfully used with dropdown lists and text fields. As dropdown lists have a fixed set of choices, words like *Select* or *Choose* are used for prompts. For text fields, the prompting string often begins with a call to action: *Enter*, *Type*, *Search*. End the string with the noun the input is describing, for instance *Enter city* or *Enter an address*. Text fields use the Input Prompt pattern combined with scripting to remove the prompt text from a field, when the user’s focus is set. Once the user enters the input field to type in content, the prompting text is removed and replaced with nothing so that the input field is free for the user to fill out. ## Rationale When a user fills out a form it is most often with the purpose of filling it out as quickly as possible to get on with the service offered. This is why the user often just scans through form fields and labels without giving the labels much of a glance. By using input prompts, immediate attention is drawn to what the user needs to fill in. The user can’t miss it. Although you must beware of removing labels entirely, as the input prompt is removed once focus has been set to the text field. Input prompt is often used for small forms that are key to the core functionality of a site as inserting the label inside the text field itself helps save space. For more elaborate forms, there is often more than enough room available to explain each input field. --- # Good Defaults - Type: User interface design pattern - Category: Getting input > Forms - URL: https://ui-patterns.com/patterns/GoodDefaults - Examples: 8 screenshots on the page ## Problem summary The user needs to enter data into the system, where some input values are most likely to match default values. ## Usage - Use when the user has to choose among many options, where some are most likely to match the default values chosen by other users. - Use when it is possible for the system to make qualified guesses regarding what the user might choose. - Use when it seems a complicated task to fill out the form without the default: when the number of required choices hinders the user from finishing filling out a form. - Do not use for input fields that are important for the user to think about. For instance for signing up to a newsletter or accepting the terms and agreements of a website. ## Solution Pre-fill form fields with best guesses at what the user wants. Drop down boxes and text fields are prefilled or preselected with reasonable default values. The default values are intelligent guesses as to what the user would possibly select. When appropriate, reduce the cognitive load on users by pre-filling forms with default values. Use contextual information to make intelligent guesses as to what the user would most likely select. Do so only when you are reasonably sure your users would agree with your default values – otherwise, you will create extra work. Pre-filling controls to your own benefit rather than your users’ will most often backfire. ## Rationale By providing default values in often complex forms with many choices, you save the user from the hassle of selecting all the relevant choices. Filling out a long form can sometimes be enough reason for the user to go somewhere else, where the process is easier. The default values might not be right, but at least you provided the user with an example that he can change with as much effort as he would have put in if there was no example. ## Discussion ### Explore the decision before changing the default If users hesitate over an important selection, begin with usability evidence and the stakes of the choice. [Learning Loop's free Persuasive Patterns reference](https://learningloop.io/playbook-collections/persuasive-patterns/) and [behavioral design tools guide](https://learningloop.io/guides/behavioral-design-tools/) can help teams compare alternatives such as simpler options or clearer explanations. A default should be transparent and easy to change, particularly when choices affect consent, privacy, or costs. --- # Wizard - Type: User interface design pattern - Category: Getting input > Explaining the process - URL: https://ui-patterns.com/patterns/Wizard - Also known as: Setup Wizard - Examples: 35 screenshots on the page ## Problem summary The user wants to achieve a single goal which can be broken down into dependable sub-tasks. ## Usage - Use when the user needs to perform a task or a goal that dictates more than one step. - An example is adding an image to a website which can include uploading the image and cropping the image; the image cannot be cropped before it is uploaded to a server. - Use when the user needs to perform a complex task consisting of several dependable sub-tasks. - Use when the user needs to input complex data into a system but the tasks is more easily achieved by splitting the process into a series of smaller and simpler steps. - Use when the user needs guidance: the user wants to achieve an overall goal, but may not be familiar in the steps needed to reach the goal. - Use when the steps needed to reach a final goal may vary due to decisions made in previous stages. - Use when the user lacks necessary domain knowledge. - Use when the user must complete steps in a specific sequence. ## Solution Break down a single goal into dependable sub-tasks. The task of inputting data into the system is parted into multiple steps. Each step is presented to the user one at a time. The user should be presented with information about the steps that exist, progress through the process and which steps are completed. The *Wizard* pattern is very similar to the *Steps Left* pattern. The difference between the two is the focus. Where *Steps Left* is focused only on explaining the steps of a process, the *Wizard* pattern is about parting dependable sub-tasks needed to perform a complex goal into separate steps. The *Wizard* pattern is also different from the [Steps Left pattern](http://ui-patterns.com/pattern/StepsLeft) in that the steps needed to perform a goal can vary depending on the information inputted in earlier stages. In this way, the *Wizard* pattern separates itself from being merely an visible aid for the user. ### Buttons Basically, a wizard is a series of screens or dialogue boxes walking users through from start to completion. Each screen asks the user to input information by either making selections or filling in fields. After inputting data, users navigate through the wizard by clicking navigation options like “Previous” and “Next”. At the final step users click “Finish” instead of “Next”, which thus indicates the completion of the wizard. It is also good practice to include a “Cancel” button on all screens that will lead the user back to where he or she came from. Typically, a “Cancel” button is located near other navigation buttons, but in a position that clearly separates the button from the “Previous” and “Next” buttons. Furthermore, it is also good practice to provide a warning if data inputted up to that point will be lost clicking the “Cancel” button. It is fair for to assume that the user expects that he or she can return to the wizard later and start from where they left off3. In order not to frustrate the user more than necessary, the consequences of exiting the wizard should be communicated. Wizards are meant to be fast and easy. For this reason, it is a good idea to keep the content of a screen as well as its navigation above the fold. ### Keep the purpose clear: explain Keep the wizard’s purpose clear on every screen by placing a clear and concise label on every screen. Optionally accompany the label with a brief explanation of the wizard’s purpose on the first screen. This will help users remember why they entered the wizard in the first place and how they will benefit from finishing the wizard. ### Use plain language Users of a wizard aren’t necessarily experts, why you should refrain from using technical jargon to prompt users. The language used should fit in to the user’s frame of reference5. ### Summarize choices It is good practice to present a summary of choices made throughout the wizard to the user near the end of the wizard. This will allow the user to review and double-check inputted data before the final “Finish” button is clicked. In the case the user wishes to change the data entered, he or she should be able to navigate back to the given page where the date was entered. If the amount of steps in the wizard is greater than 8-10, it is a good idea to provide links directly to the screen of the data input. ### Good defaults A wizard is a perfect place for using [Good defaults](http://ui-patterns.com/pattern/GoodDefaults). Most wizard users are not familiar with the task they are performing and are thus unfamiliar with the values for the choices they are asked to make. ## Rationale By splitting up a complex task into a sequence of chunks, you can effectively simplify the task. Each chunk represents a separate mental space, easier to deal with alone than as a whole. Contrary to the Steps Left pattern, the steps needed to perform a goal can vary depending on the information inputted in earlier stages. By separating complex tasks needed to achieve a goal into several steps, the process of inputting data can take several different directions depending on what input is entered. The complex task of inputting large amounts of dependable data can be adjusted and streamlined to fit the decisions of a user throughout a process. In the context of decisions the user makes in each step, unnecessary steps can be cut out and important steps can enter into the focus. In a system with many variables, a user can reach their goals by manipulating these variables in different ways. The *Wizard* pattern can be used to group such variables into separate goals. This will convert the task of completing a complex goal from multiple disparate actions into a coherent process. When users are forced to follow a set of pre-defined steps they are less likely to miss important aspects of a process and will thus commit fewer errors. ### Minimum of training Wizards are often made for the untrained user. For this reason, make sure your wizard can be completed without training. A rationale behind using a wizard is to avoid training for rare or intimidating tasks – not to develop expertise5. ## Discussion Using the *Wizard* pattern helps the user perform a complex task, but can at the same time it effects the performance time of the task. An effective wizard breaks down a complex tasks into sub-tasks and possibly sub-sub-tasks. Sub-tasks are sequenced in a way that feels familiar and comfortable for the user using task analysis. Task analysis is conducted before screen design begins and is best done observing real users performing the task in their own work environment. The output of the task analysis is an outline and information architecture for the wizard. ### Keep the amount of screens low By breaking a task up into too many screens, there is a chance of disorienting the user. If it takes too long to finish the wizard, the user may get annoyed and possibly abandons the wizard before finishing it. ### Be careful not to make each step too long While the amount of screens should be limited, you should **not** always keep the amount of screens to a minimum. When a screen of a step in your wizard grows to a height that does not fit into a regular screen solution, there is a risk of annoying the user and making the wizard tiresome to finish as it forces the user to scroll to enter data and navigate back and forth. Consider breaking such steps up into two or more screens. To find out whether you have hit the right balance between a low number of screens and short screen heights, put your wizard through a usability test. It is hard to define other means of checking when a good balance between the two has been found. ### Allow alternatives to using the wizard A wizard support users performing a task by lowering the learning curve. Use of a Wizard supposedly increases user performance, in much less time than without the use of a wizard. It however comes with the cost of “dumbing down” the task as users perform tasks without fully understanding them and being aware of the underlying decisions5. The result is users not being able to perform a task if the wizard is not available as well as not being able to fine tune decisions made by manipulating other parts of the system. A wizard should not be the only way for users to complete a task, but merely an alternative to another more complicated method of completing the same task. Use a wizard for allowing the untrained user to get started quick and let the more experienced users, who prefer more flexibility than the wizard allows, use the more complicated method. ## Sources1 Wizard design pattern by Jenifer Tidwell.
2 Wizard design pattern by Martijn van Welie.
3 Crafting a wizard by Jodi Bollaert.
4 More Web-based wizard tips and tricks by Jodi Bollaert.
5 Designing wizards by Saul Carliner
6 Wizards and guides by Bob Baxley at Boxes and arrows.
--- # Inline Help Box - Type: User interface design pattern - Category: Getting input > Explaining the process - URL: https://ui-patterns.com/patterns/InlineHelpBox - Also known as: Inline hints, Walkthrough - Examples: 26 screenshots on the page ## Problem summary The user needs assistive information located close to the interaction they are about to perform. ## Usage - Use when an interaction with your website is not necessarily intuitive and self-explanatory in itself. - Use inline tips to document your interface - Use when you want to motivate the user to start using the system. - Use when you want to aid the user in getting started with your web application. - Use when you want to guide the user to get a good start with your web application. - Use to gently introduce functionality to the new and untrained user. - Use the ‘hide’ functionality to avoid frustration of the experienced and trained user. ## Solution Document your interface in-line with descriptive help blocks. If important information needs to be communicated to the user, it can be easily explained with an inline help box located above or below the main content of a screen. The inline help box needs to be differentiated from normal content. As the help box itself is not part of the main functionality, it is a good idea to add a style to it that visually separates the help box from that functionality. An easy way to do this is by applying another background and font color to the help box. Additionally, to avoid the user’s discontent with the help box, a great feature of the in-line help box is to have a “hide this box” functionality. Once the user has clicked this link, the help box will never be shown to the user again. However, you might want to provide an option for the user to re-enable all help boxes, to allow the user to get that first-hand help that he or she started out getting. ## Rationale Providing your users with assistive information, located close to an interaction, makes accessing and consuming instructional info simple and easy. In Line help boxes are far more engaging than reading disconnected FAQ’s or help sections. By allowing the user to easily close/hide each help box, the user is not bothered with unnecessary information once it has been understood. --- # Steps Left - Type: User interface design pattern - Category: Getting input > Explaining the process - URL: https://ui-patterns.com/patterns/StepsLeft - Also known as: Workflow - Examples: 79 screenshots on the page ## Problem summary The user is about to go through the process of filling in data over several steps and is in need of guidance. ## Usage - Use when a user goal can be split into a series of smaller steps that is easier displayed on separate screens. - Use when the steps of a process is so long that the user might get the impression that it will go on forever without the guidance of steps. - Do not use when there is only 1 or 2 steps in submitting data to the website. - Do not use when the process of filling out data is easily foreseeable. ## Solution Add a navigation block describing the steps involved in submitting data to the system. The block should always appear on the page. As the user progresses through the process, the navigation block is updated accordingly. The current step is highlighted, giving a clear indication to the user how far they have come and how much further there is to go. Remove unnecessary distractions like extra navigation, advertisements, and the likes. ## Rationale The *Steps Left* pattern is used when it is critical to maintain the user’s focus throughout the process of filling in data to the system. This is for instance critical in e-commerce websites, where the checkout process is often guided by this pattern. In e-commerce websites, the checkout process is the most critical part of the site, as this is the part that captures the customer’s money. The *Steps Left* pattern provide the user with a great overview of how far in the process the user has gone: it provides a visible end to the process, which the user can aim for. This pattern is similar to the Wizard pattern most commonly found in desktop applications, which guide the user step by step. ## Discussion ### Workshop exercise for multi-step journeys For onboarding or checkout flows, map the steps users expect, identify the points where they lose their place, and compare clear progress feedback with simpler alternatives. [Learning Loop's Ideas first, Patterns later exercise](https://learningloop.io/plays/workshop-exercise/ideas-first-patterns-later) can help a team explore alternatives before selecting a UI pattern. Measure task completion and user understanding, not just clicks to the next step. --- # Completeness meter - Type: User interface design pattern - Category: Getting input > Explaining the process - URL: https://ui-patterns.com/patterns/CompletenessMeter - Also known as: Progress Bar, Percentage Done Meter, Progress Indicator - Examples: 37 screenshots on the page ## Problem summary The user wants to complete a goal but needs guidance in when it is reached and how to reach it. ## Usage - Use when you want to keep the user on track when completing a specific goal. - Use when you want to ensure that your users complete a set of minimum tasks that make up their presence. - Do not use when the end-goal is dependent of a series of sequential tasks. - Do not use for critical goals, but rather for goals that would be nice to have reached. The idea of this pattern is to make the user perform a few more tasks than he or she would normally do. ## Solution Let users gauge progress toward reaching an end goal. Divide the end goal into smaller sub-tasks, and increase the percentage of completeness as each task is completed. Divide and end-goal into several sub-tasks. The end-goal can be arbitrarily defined, such as “Completeness of your profile” or “Elite member”. As each sub-task is completed, the percentage of completed tasks goes up – reaching 100% when the goal is finished. It is often seen that along with stating the progress of the goal (for instance: “34% done”), one or more links or hints to how the progress can be improved is also provided. This will help keep the user on track and immediately move to the next task once one has been completed. There are several approaches to presenting and celebrating an end-goal state. One option is simply to indicate that all tasks have been completed (as in “Your profile is complete!”) along with a “100%” mark. Another is to award the user with a collectible achievement: a badge, trophy, or similar award that he or she can decorate his personal profile with and show off to his or her friends. A third way to celebrate completing the goal and its sub-tasks is to announce it in his or her profile feed, or even on a centralized site-wide feed. ## Rationale Extrinsically motivate users by triggering their desire for achievement, curiosity, and completion by providing a feedback loop that lets users gauge their progress toward reaching an end goal. This pattern uses a set of psychological drivers that pushes the user to move forward towards the end goal. One is **curiosity**. We are curious to find out what happens when we reach 100%. Will I be rewarded or will my profile look different? Another is the **feedback loop**. As the user completes sub-tasks, his or her progress moves towards 100%. A clear link between completing tasks and reaching the end goal has been established. ## Discussion As humans, we feel inclined to complete the goals we have decided to start. Most often we choose goals for ourselves based on what we want to spend our time on, afterwards we put our minds into it. The Completeness Meter pattern is an attempt to present such a goal to the user in order for him or her to decide on completing it. By presenting easily completed sub-tasks, it is possible to convince and persuade the user into spending time he or she in other circumstances wouldn’t have. --- # Pay To Promote - Type: User interface design pattern - Category: Getting input > Community driven - URL: https://ui-patterns.com/patterns/pay-to-promote - Also known as: Boost post - Examples: 2 screenshots on the page ## Problem summary The user wants to pay to prioritize own content above the regular content feed in order to gain increased reach and traction. ## Usage - Use when you want to provide users and businesses a chance to skip the content prioritization algorithm to get in front of the desired audience. - Use when you want to provide users an opportunity to elevate content on feeds for a fee ## Solution Let users pay to promote their content On social platforms like Quora, Twitter, OKCupid, and LinkedIn, users can post content. Allow users to boost visibility of their own content by paying money. This form of advertising allows users to gain traction while maintaining a look and feel native to the platform. Sites like Quora and Facebook allow users to boost their posts by paying money, which in return gives them greater visibility in the content feed above the regular non-paid content. Dating-sites like OKCupid allow users to boost their profile in views. LinkedIn does the same albeit as part of a paid membership plan rather than by individual content like on Facebook. ## Discussion The Pay to Promote pattern is part of the native advertisement concept, which blends regular content with paid content. The two look the same with the only difference of the paid kind having a “Sponsored” label or “Advertisement” label. --- # Rate Content - Type: User interface design pattern - Category: Getting input > Community driven - URL: https://ui-patterns.com/patterns/RateContent - Examples: 33 screenshots on the page ## Problem summary The user wants to promote a specific piece of content in order to democratically help decide what content is of higher quality. ## Usage - Use when you want a mechanism to handle risk for your users: is an item of content worthwhile spending time and/or money on. - Use when you want your users’ help to democratically decide what content is of higher quality. - Use when you want to let the voice of your users guide other users in what is good and bad. - Use when your website has a large user-base. - Use when you feel that you can trust your users’ subjective opinion on which items are of higher quality than others. - Do not use when your website has a small community. A large user base and a strong community is important for enough votes to be generated and in turn for comparison between items to render meaningful. ## Solution Let users rate content in order to democratically help decide what is of higher quality. User ratings act as a mechanism to handle risk for your users: is something worthwhile to spend time or money on? Promote community participation by letting users democratically decide what is of higher quality. Consider accompanying quantitative ratings with qualitative comments or reviews. This pattern is much like the [Vote To Promote](http://ui-patterns.com/patterns/VoteToPromote) pattern. It differs from the [Vote To Promote](http://ui-patterns.com/patterns/VoteToPromote) pattern by having different outcome. The outcome is to allow users to guide other users about what is good and bad rather than to promote what is interesting. The pattern consists of a number of mechanisms that work together: - **Voting mechanism**. Provide a mechanism for your users to rate an item on a numeric scale. The most popular scale is 1-5, where a rating of one is worse than a rating of 5. A user gets one vote and can possibly add an explanatory comment along with the rating. When a user rates an item, feedback should be given back to the user informing them that the rating has been recorded. - **Display the average rating an item has received**. The average of all ratings an item has received shows the perceived quality of an item, and will guide new users in whether an item is worthwhile. - **Display explanatory comments from users rating an item**. An item can often be rated either low or high for a number of different reasons all originating from different users’ subjective opinion. A perceived flaw by one user is not necessarily a perceived flaw of another. To add a more quality and depth to the given ratings, allow the users to review an item by letting them explain themselves in free text. - **Show the highest rated items**. Sum up the highest rated items in lists on a main page. - **Favor quality items**. Favor items rated high in search results, when browsing tags, and showing related information. - **Related items**. When showing one item, display its rating. Additionally, use the people who also rated the item highly, to create a list of related items, by showing other similar items these people rated highly. ## Rationale The Rate Content pattern promotes community participation and can assist you in separating good quality content from bad quality content. This is especially useful when your website relies on user submitted content. Rating content is about handling risk from the user’s point of view. Will a user on eBay cheat me or is a book on amazon worthwhile my time and money? ## Discussion The main reason to use the Rate Content pattern is assist the user in managing risk. Examples of such risk are spending money on buying a product or from investing time on another user. When implementing a rating system, you need to consider a number of things in relation to what it should be used for and how it should be communicated: 1. Who is doing the rating 2. What is being rated 3. What behavious are we trying to encourage or discourage? **Who is doing the rating** When reading reviews about an item and seeing how other users rate a given item a number of concerns are bound to be raised by the user: “Is the rating and review honest and authentic?”, “Are the users who rated a given item like me?”, and “Do the reviewers posses the relevant competence to review the product or service in question?”. Amazon and Netflix have solved this problem by letting people rate the ratings: was this review helpful for you? **What is being rated** Be clear when communicating what is being rated and make sure that the user knows exactly what he or she is rating. If what is being rated seems ambiguous, the value of the review for other users in turn diminishes. For instance, if a website collects good computer deals that can be rated by the website’s users, is it the trustworthiness of the seller, the products, or the price that is being rated? Consider making your rating system multi-dimensional, or simply be clear about what – exactly what – is being rated. **What behavious are we trying to encourage or discourage?** Like with the [similar community driven patterns](http://ui-patterns.com/patterns/VoteToPromote), several pitfalls can make or break the success of the Rate Content pattern. Are some users trying to promote or demote certain items? – perhaps their own or their competitors product – maybe their friends or foes. You might want to setup a number of measures to prevent users from misusing the system, such as [limiting the maximum activity of a user, looking out for malicious activity, or promote trusted key users to count more than others](http://ui-patterns.com/patterns/VoteToPromote) Design your rating system so that you encourage the behavior you want. Making your rating system multi-dimensional by breaking up the full rating into sub-parts that by their title explain exactly what you want measured (rated), is one way of solving this problem. ## Sources 1. [On a scale from 1-5](http://boxesandarrows.com/view/on-a-scale-of-1-to-5) *at [Boxes And Arrows](http://boxesandarrows.com) by Alex Kirtland and Aaron Schiff.* 2. [Vote To Promote design pattern](http://ui-patterns.com/patterns/VoteToPromote) *at [ui-patterns.com](http://ui-patterns.com) by Anders Toxboe.* --- # Vote To Promote - Type: User interface design pattern - Category: Getting input > Community driven - URL: https://ui-patterns.com/patterns/VoteToPromote - Examples: 14 screenshots on the page ## Problem summary The user wants to promote a specific piece of content in order to democratically help decide what content is more popular. ## Usage - Use when you want your users to democratically decide what is interesting content. - Use when you want your users to democratically submit content to your website. - Use when you want to trust your users subjective opinion - Do not use when your website has a small community. A large user base and a strong community is important so that a sufficient amount of votes can be generated and meaningful comparisons can be made. ## Solution Let users participate in content curation by letting them promote quality content. Use the power of your community to help curate what is more popular. Display a voting mechanism next to each candidate item. As users click, their vote is counted in favor of promoting that item. Consider providing an embeddable and stand-alone voting mechanism that third-party publishers can include on their site. ### 4 Mechanisms working together This pattern consists of a number of mechanisms that work together: - **Voting mechanism**. Provide a mechanism whereby users can vote for or against each item of content on your website. A user gets one vote and can change that vote at a later time. When a user casts a vote on an item, this information should be provided back to the user as feedback. Let the user see his or her prior votes and in some cases allow the user to change those votes. - **Display number of votes an item has received**. This will give your visitors a clear indication of how popular an item is and allow for comparison with other items. - **Sum up popular items**. Provide lists of popular content summed up on a main page. - **Favor popular items**. Favor popular items in search results, when browsing tags, and showing related information. - **Content submission mechanism**. You can let users submit content in several ways. ### Let users submit **Provide a webpage with a submission form.** The most basic and traditional way to let your users submit content is via a form on a webpage that you host. After content has been submitted, your users can freely vote on the submitted content’s quality. ### Make voting embeddable **Provide a widget for the user to to place on his or her website.** If the type of content your users are submitting, you can provide a widget to your users to place on their own website. This will allow third-party publishers to submit content directly from their own website. The widget is really a javascript include code, that will add the address of the webpage, if the webpage has not been added to your site yet. ## Rationale The Vote To Promote pattern promotes community participation and can potentially help pick up and promote the newest and hottest content around. By using your community to judge what is more popular, you avoid the need to hire paid professional reviewers. ## Discussion Using the Vote To Promote pattern on your website brings the user to the center of your site. It is used to implement a democratic control over the content of your website with the following pros and cons. - Is democratic control the best mechanism for promotion if all users do not share the same opinion among each other - Is democratic control the best mechanism for promotion if all users do not share the same opinion as your site or product - Is democratic control the best mechanism for promotion if all users do not possess what you believe is good taste. Each user votes from their perspective of what defines good quality: their opinion is subjective. This raises the question whether the numeric number of votes on each item can really be compared and if the item with the most positive votes really is the item with the highest quality. This dilemma raises the question whether some users should have more authority than others: if some users’ votes should count more than other users’ votes. This might be necessary if you want your site to retain the definition of quality that *you* like. *Popular* content is not necessarily the same as *quality* content. Consider a number of measures to prevent users from misusing the system: - **Limit user’s activity**. Limit the number of votes a user can cast for a given time-period. - **Watch for malicious activity against specific users**. A user might get in a malicious mood and start demoting another user’s content. Limit the number of times a user can demote another user’s content. - **Some votes count more than others**. Consider giving votes from users to their friends less value than to strangers. - **Some content is more important than others**. Consider promoting original content rather than citing content. ### Wisdom of crowds When the amount of content submitted each second is larger than what your staff can handle, you will have to rely on what is referred to as the “wisdom of crowds” to decide what is good content and what is not (spam, untrue stories, “lame stuff”, bad categorizations, etc.). This could possibly work, if each user evaluated the quality of an item of content isolated from what other users have already voted. However, it is not always the case that voting is done in isolation. Instead, crowd members communicate and affect each other’s qualitative judgment towards the *lowest common denominator* of opinion. The reason for this is the mix up of using measurable values when judging quality. The crowd has no wisdom: it will always be affected by the lowest common denominator of what others have voted. --- # Wiki - Type: User interface design pattern - Category: Getting input > Community driven - URL: https://ui-patterns.com/patterns/Wiki - Examples: 4 screenshots on the page ## Problem summary You want to create a repository for your website or application where users can produce and manage information while collaborating on public content. ## Usage - Use when you want the user to be able to contribute to a page by adding or editing the content of the website. - Use when you have a collection of documents you want to keep updated over time. - Do not use when publishing editorial content: content that stems from the publishers of the page that is not to be tampered by anybody else. For instance the terms and agreements of a website or other legal information. - Do not use for content that ages – that is relevant for a certain time period only (news, blog posts, etc.) ## Solution A wiki is a page concept itself, and not just a pattern that functions as a part of a website. The format however represents enough value in itself to represent a design pattern and not just a page concept. A wiki page can be edited by anyone. Anyone can modify information and add new pages to the document collection. All pages are under version control, and can easily be rolled back to earlier versions. A wiki allows users to easily create, edit and link web pages together. A wiki enables documents to be written collaboratively, in a simple markup language using a web browser. A single page in a wiki is referred to as a “wiki page”, while the entire body of pages, which are usually highly interconnected via hyperlinks, is “the wiki”. A wiki is essentially a database for creating, browsing and searching information. \[[Wikipedia.org](http://en.wikipedia.org/wiki/Wiki)\] ## Rationale Wikis are often used to create collaborative websites, power community websites, and are increasingly being installed by businesses to provide affordable and effective Intranets or for use in Knowledge Management. \[[Wikipedia.org](http://en.wikipedia.org/wiki/Wiki)\] --- # Flagging & Reporting - Type: User interface design pattern - Category: Getting input > Community driven - URL: https://ui-patterns.com/patterns/flagging-and-reporting - Examples: 1 screenshots on the page ## Problem summary The user wants to mark inappropriate content for moderation ## Usage - Use when your site is based on user generated content where you can’t possible moderate everything yourself because of the vast number of updates. ## Solution Let users report content for moderation ## Rationale For sites based on user-generated content and user interaction, flagging and reporting is a vital design pattern. Let users help discover content necessary for administrators to review for removal or categorization. Users are most often happy to help with the overwhelming task of surveilling and managing user-generated content produced in a community. --- # Account Registration - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/AccountRegistration - Also known as: Sign up wall, Sign-In Wall, User Sign-Up - Examples: 215 screenshots on the page ## Problem summary You wish to know who the active user is in order to provide personalized content or opportunities to conduct a purchase. ## Usage - Use when you want to restrict access to certain content. - Use when you want to control which users have access to content. - Use when contextual information must be presented to the user. The context can depend on the user’s geography, timezone, age, interests, or even the user’s prior interactions with your site (friends added, submitted content, etc.) - Use when you want to protect your user’s information. ## Solution Ask users to register an account in order to provide a personalized experience. Let users register an account to allow saving information with your service, provide a personalized experienced, or give access to limited resources. Common design flaws for registration and sign-in features include: - **Visibility:** make sure the “Sign-in” and “Sign-Up” buttons” are clear, easy to see and easy to access. Don’t hide the “Sign-in” button/form. - **Call to Action:** Draw attention to crucial operations such as “Register new account” “Sign-in”, and “I forgot my password”. Ensure your action buttons are appealing and encourage new users to join. - **Nudge:** Exploit sign-up opportunity at key locations, don’t just rely on one point of action. - **Redundancy:** Provide plenty of “Sign-In” buttons at key locations. Users often wait to the last moment to sign in. Key locations are points of action; for instance when the user wants to add a comment to a blog post. - **Complicated:** Don’t frustrate users with complicated password requirements. The strength of the password you require needs to match the need for protection. A password policy that is too strict can hinder sign-up and may discourage potential customers. You can make your account registration easier on your users including: - Provide a simple and understandable description of the requirements for usernames and passwords. - Additionally, you might want to provide a password strength meter to provide instant feedback on how well the entered password meets the requirements instead of displaying an error message after the user has clicked the submit button. - Similarly, you might also want to use AJAX to check for the availability of the username on every keystroke, so that the user does not need to submit the entire form several times before he is allowed entrance. - When logging in, return to the page the user came from. If the point of action was submitting a comment to a blog post, redirect the user to the comment form after login. - Consider incorporating a social sign in options such as “Facebook Login” into your website/application and avoid the entire new password paradigm entirely. ## Rationale Account registration enables personalized and contextual content to be presented to authenticated users. Account registration allows for remembering details about the user; product wish lists, preferences, interests, shipping and billing addresses, VAT number for billing purposes, and more. Benefits of letting the users register an account with your site include: - You know who is using your system - You know how often they visit - You know what they do on your site. - You can store information your users might need later, such as billing info or wish lists for future purchases. - You can use account registration to reserve special content from your regular users. - You can differentiate prices, information displayed, and access rights depending on who the logged in user is. ## Discussion ### Is account registration necessary? And when? Customers do not like to identify themselves until they actually need to. They need to when he or she has decided take action – for instance to purchase a product. Until then, you do not want to block users from taking action or browsing your website. In general, you will only want to protect the pages that actually requires you to know the user’s identity. Users hate having to register an account to do something simple. An example of premature sign-in would be forcing users to sign in before they can browse your online shop’s products. User’s want to get an idea of what is offered before they commit to creating an account, not the other way round. What kind of site do you run? Is it really necessary to develop a relationship with your customers (or users) or is the typical behavior of your kind of customers to stay anonymous? In the latter case, you might want to consider not requiring an account registration at all – even when the user is purchasing a product. ### Why should the user register? You need to clearly state what benefits the user will get from registering an account with your website as this step is a burden for the user. One way to do this is to directly communicate the benefits in written sentences such as “Track your order”, “Change your reservation at a later time”, or “Receive our newsletter” (Yes, this actually is a benefit to some people). Another way to communicate the benefits of registering an account is to block points of action. Examples of this are submitting a comment or content to the site. ### Asking too many (unnecessary) questions Knowing your users is important, but wanting to know them too well can hinder account registration. Even though your marketing department is eager to know the exact interests, phone number, or even size of yearly paycheck of your users, asking them this is not always a good idea. With spam e-mails being a common known phenomenon, the average internet user is reluctant to trust you with such data. In certain cases you may require personal information from users, to maintain trust, declare exactly why you need it. A simple “In case we need to contact you, please provide a phone number” will do. Making up a user name and thinking of a new password are big tasks for the user already. The fact that the user needs to think and make up their mind about these things means it has taken away the user’s focus from the task he or she had at hand. --- # Social Login - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/SocialLogin - Also known as: Social Sign-in, Single Sign-On (SSO), Sign in with Google, Sign in with Apple - Examples: 8 screenshots on the page ## Problem summary The user wants to start using the product without creating and remembering yet another username and password. ## Usage - Use when your audience already has accounts with a widely trusted provider, such as Google, Apple, or Microsoft. - Use when signup happens on mobile, where typing an email address and a password is slow and error-prone. - Use when business users expect to sign in with their company’s identity provider. - Use when you want to prefill parts of setup, such as name, photo, or company, from information the user has already given elsewhere. - Do not use when the provider’s data access would worry your audience, for example in privacy-sensitive products. - Do not use when your users are unlikely to have, or want to use, the accounts you offer. ## Solution Let users create an account and sign in with an identity they already have. Place one to three sign-in buttons above the email form, and keep signing up with email available for users who prefer it. ### Choose providers for your audience Offer the providers your users actually use: Google and Apple for consumer products, and Google, Microsoft, and SAML-based single sign-on for business tools. Every extra button is one more decision. Three well-chosen options are quicker to scan than a wall of logos, which is the point of [Limited Choice](/patterns/Limited-choice). Canva leads with Google and Facebook, then email, while Amplitude offers Google, Slack, and GitHub, the services its developer and product audience already uses. ### Ask only for what you need Request the minimum permissions, usually name and email address. If you need more, such as access to contacts or a calendar, ask later in context and explain why. A permission screen that asks for more than the product obviously needs makes users stop and reconsider. ### Use what you get After sign-in, use what the provider shares to shorten setup. Prefill the user’s name and photo (see [Smart Prefill](/patterns/SmartPrefill)), and suggest joining an existing workspace when the company email domain matches one. The user should not be asked again for information they just gave you. ### Make the button text and the outcome predictable Use the provider’s standard button and a clear label such as “Continue with Google”. “Continue” works for both new and returning users, so people don’t have to remember whether they already have an account. ## Rationale Social login replaces several fields and decisions (email, password, password rules, confirmation) with one recognizable action. It removes the need to invent and later remember a password, a task that is easy to abandon at signup and a frequent cause of failed sign-ins later. Familiar provider buttons also lend credibility at a moment of uncertainty. The user recognizes the button from many other products and knows what will happen when they press it. It is a case of [recognition over recall](/patterns/Recognition-over-recall): the user doesn’t have to remember which email address and password they used last time. ## Discussion ### Too many choices A row of six or seven provider logos recreates the problem social login was meant to solve: the user has to stop and choose. Look at which providers your users sign in with, and remove the ones few people use. ### Duplicate accounts Users often forget which method they used last time. Someone who signed up with Google may later try “Sign in with Apple” or type their email and create a second, empty account. Detect matching email addresses and offer to link the accounts, and show which method was used before when someone returns. ### Trust and privacy Some users are wary of connecting a social account to a new product, especially when they don’t know what will be shared. State what the product receives, and never post on the user’s behalf without asking. ### Social login or magic link? Both remove the password. Social login borrows an identity from a third party and brings profile data with it, which helps with [Smart Prefill](/patterns/SmartPrefill). A [Magic Login Link](/patterns/MagicLoginLink) depends on nobody but the user’s email provider, and suits audiences that distrust connecting accounts. Many products offer both next to the conventional [account registration](/patterns/AccountRegistration) form. ### Measuring it Compare signup completion by method, and follow each method through to activation. A method that is quick at signup but leads to fewer active users may be attracting the wrong expectations. --- # Magic Login Link - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/MagicLoginLink - Also known as: Magic Link, Passwordless Login, Email Sign-in Link, One-time Code - Examples: 11 screenshots on the page ## Problem summary The user wants to sign up or sign in without having to create, remember, or reset a password. ## Usage - Use when users sign in infrequently and are likely to forget a password between visits. - Use when your audience reliably has access to their email on the device they are using. - Use when you want to verify the user’s email address as part of signing in. - Do not use when users sign in many times a day, or on shared devices where opening email is impractical. - Do not use when email delivery is slow or unreliable for your audience. ## Solution Ask for the email address only. Send a one-time login link, or a short code, to that address, and sign the user in when they use it. There is no password to create at signup, and nothing to remember at the next login. ### Tell users exactly what happens next After the user submits their address, say where the email is coming from, what the subject line is, and how long the link or code is valid. Offer a way to resend, and a way to correct a mistyped address. ### Offer a code as well as a link A link only works smoothly when the user reads email on the same device they are signing in on. A short numeric code can be typed on any device, so many products send both. ### Keep the user in place Let the link open the product in the state the user left it: the page they were on, or the canvas they were about to start. The detour to the inbox should feel like one more step in the flow. ### Offer a password as a fallback Some users prefer a password, or can’t open email on the device in front of them. Netflix keeps a secondary “Create password instead” button below “Resend link” on its “Check your inbox” screen, so the passwordless route is the default and not the only route. ### Remember the device Keep users signed in for a reasonable time on their own devices, so they only need a login link occasionally. ## Rationale Passwords add a memory task at signup and a failure point at every later sign-in. A magic link removes both. It relies on something the user already has, access to their email, and it verifies the email address in the same step, so a separate confirmation step is no longer needed. Compared with a conventional [account registration](/patterns/AccountRegistration) form, the user does one thing instead of several: open an email and press a button. ## Discussion ### The inbox is an interruption Switching to the inbox is itself an interruption. The user may get distracted by other email, or the message may land in a spam folder. When the first session should not depend on email at all, let the user start right away and ask for verification later. ### Security Magic login links are only as secure as the user’s email account. Make links single-use and short-lived (Netflix’s email says “This link will expire in 15 minutes”), and bind them to the session or device that requested them where possible. ### Link scanners Some corporate email systems open every link in a message to check it for threats, which can use up a single-use link before the user gets to it. Let the link lead to a page with a confirm button, and complete the sign-in only when the user presses it. A short code is not affected by this problem. ### Lazy registration instead If the user could try the product without an account at all, consider [Lazy Registration](/patterns/LazyRegistration) and ask for the email address later. ### Measuring it Track the share of sent links or codes that lead to a completed sign-in, and the time between request and sign-in. A long delay or a large drop-off usually points to delivery problems or unclear instructions. --- # Deferred Verification - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/DeferredVerification - Also known as: Delayed Email Verification, Verify Later - Examples: 4 screenshots on the page ## Problem summary Requiring email confirmation before anything else sends users to their inbox at the moment they are most ready to act, and many never come back. ## Usage - Use when the first session can be useful without a confirmed address. - Use when users sign up in a short window of opportunity, such as on mobile or between meetings. - Do not use when unconfirmed accounts could be used for abuse, such as sending invitations or messages to others. - Do not use when the product must contact the user before they can benefit. ## Solution Let the user into the product immediately, and ask for confirmation later, at the moment it matters. ### Send the email, then get out of the way Send the confirmation email as soon as the user signs up, and let them carry on. The user should land in the product, not on a “Check your inbox” page that waits for them to come back. ### Remind with a calm banner Show a dismissible banner at the top of the product that says what to do and where the email went, with a “Resend” link. Airtable’s says “Please verify your email address by clicking the link sent to …” next to a “Resend verification email” button, and can be closed. Keep it quiet: it should not cover the product or reappear on every screen. ### Explain what verification unlocks A request that only says “you must verify” is an order. A request that says what the user gets is a reason: “To get access to Airtable AI, confirm your email by clicking the verification link.” State the benefit, and put the request next to the thing it unlocks. ### Ask at the moment it matters Require confirmation before the user can do something that affects others or costs money: sending invitations, publishing, paying, or exporting data. Airtable lets the user build in a base straight away, and shows “You must verify your email to perform this action” when they try to run one of its automated agents. ### Keep the user’s work Confirming later should take the user back to where they were, with everything they did in the meantime. If they never confirm, tell them how long their account stays active. ## Rationale Email confirmation is a step the system needs, not one the user wants. Putting it first moves it into the user’s path to their first result, and sends them to an inbox full of other messages at the moment their attention is highest. Deferring it keeps the user in the product during their [window of opportunity](/patterns/Kairos), and asks for the confirmation once they have a reason to give it. People are also more willing to do a small chore after they have started something. Having built something in the product, the user has an investment to protect, which makes the request for a click on a link easier to accept ([Commitment and Consistency](/patterns/Commitment-consistency)). ## Discussion ### Deferred Verification or Lazy Registration The two patterns defer different things. [Lazy Registration](/patterns/LazyRegistration) defers creating the account: the user can try the product before they have given any details. Deferred Verification defers confirming the email address: the account exists, with an address attached, and the user can use it before proving the address is theirs. A product can use one without the other, or both. ### The cost of deferring An unconfirmed address can be mistyped or belong to someone else. Messages sent to it never arrive, or arrive with a stranger. Decide what an unverified account may do, and what it may not. Airtable lets users try its main features, and blocks the actions that affect others. ### Banners that turn into nagging A permanent, alarming banner turns a deferral into pressure. Make it dismissible, and bring it back only when the user is about to do something that requires a confirmed address. After a few days, an email reminder is a better place for it than the product. ### Verifying with a magic link If the product already uses a [Magic Login Link](/patterns/MagicLoginLink), the first login link also confirms the address, and no separate step is needed. That is the simplest form of verification: it has no extra step to defer. ### Measuring it Compare activation before and after the change, and track the share of users who eventually verify. If activation goes up and few users verify, the banner is probably not doing its job. --- # Lazy Registration - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/LazyRegistration - Also known as: Immediate Immersion, Gradual Engagement - Examples: 15 screenshots on the page ## Problem summary The user wants to immediately use you and try your website without conducting a formal registration beforehand ## Usage - Use when it is critical for your website to let the user browse around and interact with your website before actually registering an account - Use when giving away the personal information required for a formal account registration is a big step for your users - Use when you want to allow your users to try out your website (and in turn compare it to alternatives) before making the decision to register an account with your website - Use when registering an account requires an exchange of money, why the user might want to “browse around” your product first in order to make a decision. - Use when you don’t want to force your users to register at first – when you don’t want to put too much pressure on your users - Use to make your users start entering data into your system right away. When they have already invested time in your system, the step to registering an account is smaller than if no time has been invested. ## Solution Allow users to access a limited set of features, functionality, or content before or without registrering. Let users interact enough with your system so that an actual registration is just another small step in a larger process: a small step, not an obligation. The light version of this pattern is the shopping cart of an e-commerce site, where the user can accumulate relevant products in a cart and then in turn register an account if he or she chooses to make a purchase. In the heavier version of this pattern, an anonymous user account is immediately created for the user – full with an auto-generated database ID and a complimenting cookie with the account’s ID that will ensure that the user’s details and the information he or she has entered will be remembered upon the next visit. With appropriate intervals, inactive anonymous accounts are cleared from the database in order to not clutter it up. As the user interacts with the system, data is accumulated to the account. While some data might not be shown to the user other kinds of data will. It is the latter kind of data that in turn will make the user register – the visible evidence that the user has invested energy into using the system. A smart way to gather such data is to expose holes of data that the user can populate. Two such holes are the username and password: the two bits of information that will allow the user to log into his account from more than one computer. ## Rationale Deliver value before prompting for conversion. Shopping carts are a classic pattern that plays on Lazy Registration: users can browse and choose products, but only have to register when they proceed to check out.x The Lazy Registration pattern allow users to use your system and **take action before or without registrering**. The idea is to let users interact enough with your system so that the actual registration is just another small step in the larger process. It’s a small step – not an obligation. The classic [Shopping Cart](http://ui-patterns.com/patterns/ShoppingCart) pattern is a good example of Lazy Registration: users can browse and choose products and only have to register when they proceed to check out. For this pattern to work, you need to provide the users with an incentive to give you the registration data you are looking for. You need to provide a worthwhile service to your users for them to give you their data back in return. You want to use classic [*Carrot and stick*](http://en.wikipedia.org/wiki/Carrot_and_stick) motivation – and just as important: communicate the benefit you are providing. If the registration data you are looking for with the user is sensitive, you must be able to assure your users that their data will be safe and secure. ## Discussion Questions to ask when planning your Lazy Registration - Consider how you can avoid sign up forms in favor of a more gradual engagement. - If you choose to use the Lazy Registration pattern, make sure that you focus on showing off how you deliver value: how potential customers can use your service and why they should care. - Auto-generated accounts are great, but if you choose to use them, then make sure to design a clear way for users to access their accounts. Chances are that people will either ignore or not see your account creation mails – and might be uncertain if they even have an account or not. 1 ### Lazy Registration or Deferred Verification The two patterns defer different things. Lazy Registration defers creating the account, so the user can try the product before giving any details. [Deferred Verification](/patterns/DeferredVerification) defers confirming the email address: the account exists, and the user can start using it before proving the address is theirs. A product can use one without the other, or both together. ## Sources1 Sign up forms must die by Luke Wroblewski
--- # Guest Access - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/GuestAccess - Also known as: Guest Mode, Recipient View, Shared Link Access - Examples: 1 screenshots on the page ## Problem summary People who receive something shared with them must sign up before they can see it, so many never do. ## Usage - Use when recipients only need to view, comment, approve, book, or reply. - Use when the shared object is valuable on its own, without the rest of the product. - Use when recipients are potential users, and their first experience should be the product working. - Do not use when the content is confidential and needs identity verification. - Do not use when anonymous access could be abused. ## Solution Let recipients open what was shared with them directly, and take the first relevant action without creating an account. ### Put the shared object first Open the document, video, booking page, or update itself, not a page about the product. Make the first action available right away: reading, commenting, booking a time, approving, or replying. ### Make clear who shared it and why Show the sender’s name and, where possible, a short message. Recipients act more readily when they know the request comes from someone they know. ### Ask for an account later Offer an account when it gives the recipient something of their own: “Save this”, “Get notified about replies”, “See all updates in one place”. A small, persistent link such as “Get started free” is enough until then. ### Keep the recipient’s work If the guest later signs up, carry over what they did as a guest: their comments, bookings, or replies. ## Rationale The recipient’s first experience of the product is the product working, instead of a form. Guests who get value from a shared link have a reason to sign up later, which people who met a signup wall never get. It is [Reciprocation](/patterns/Reciprocation) at work: the product has already been useful before it asks for anything. Guest responses also bring the original user back, which strengthens their habit. ## Discussion ### Preview walls Some guest views are signup walls with a blurred preview, or push recipients to register before they have finished what they came to do. These recreate the barrier the pattern is meant to remove. ### Abuse and privacy Open links can be forwarded. Let senders choose who can open a link, set expiry dates for sensitive content, and limit what guests can do, for example comment but not edit. ### Guest access or lazy registration [Lazy Registration](/patterns/LazyRegistration) lets a new user try the product for their own purposes before creating an account. Guest Access is for people who didn’t come to the product at all, but were sent something by someone who did. The two combine well: a guest who becomes a user can keep what they did, as the pattern recommends. ### Well-known examples Calendly booking pages, Loom video links, and published Notion pages all let recipients use the product before they ever sign up. ### Measuring it Track the share of recipients who act on a shared link, the time to their first response, and the share of guests who later sign up. --- # Onboarding Carousel - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/OnboardingCarousel - Also known as: Intro Screens, Welcome Carousel, Feature Carousel - Examples: 6 screenshots on the page ## Problem summary Many products open with a sequence of screens explaining what they do, which users click or swipe through without reading. ## Usage - Use when the product needs to explain one key concept before its first screen makes sense. - Use when permissions or setup need a brief explanation of their benefit first. - Do not use when the screens only list features. - Do not use when the product could simply start with its first useful action. ## Solution Introduce the product in a short sequence of screens that the user steps through before starting. ### Keep it short Three screens or fewer is a good limit. Every extra screen delays the first action, and people remember little of what they pass through before they have a reason to care. Trello’s runs to four, and shows that in a row of segments at the top, so users know where the end is. ### One idea per screen Give each screen one benefit the user cares about, with a headline that says it and a line of text that explains it. “Consolidate all your to-dos with Inbox” is a benefit. “Features” is not. ### Show the real product Use a picture of the product in action, and not a stock illustration. Trello’s screens show its own Inbox and board, so what the user sees in the carousel is what they will see next. ### Let users move at their own pace Offer clear forward and back controls, and show progress. Trello puts both arrows at the top, beside the segments, and highlights the next arrow when it is the expected action. Let users close the carousel at any point: an “X” in the corner, or a “Skip” link on every screen. ### End on a way to start The last screen should lead into the product with one clear action, not just close. Trello’s final screen says “One last thing!” and moves on to the next step. ### Consider replacing it A carousel explains. A first action lets the user do it. Where possible, turn the screens into a short [Playthrough](/patterns/playthrough), or move the explanations to where they matter, as [Inline Hints](/patterns/inline-hints) or a [Hotspot](/patterns/Hotspot). ## Rationale A carousel sets expectations and makes the value easy to picture, at the moment the user is most open to it. A few screens with a picture each are quick to take in, and a visible end keeps the effort small ([Steps Left](/patterns/StepsLeft)). The risk is the opposite. People tend to click through introductions to reach the product, and what they skip they do not remember. A carousel works when each screen is short, concrete, and ends in the user doing something. ## Discussion ### Carousels that nobody reads Users learn quickly that the screens before the product are skippable, and treat them that way. Count how many users skip, and how many of those who stay do better afterward. If skipping makes no difference, the carousel is not needed. ### Carousel or playthrough A [Playthrough](/patterns/playthrough) lets the user do the thing it explains. Trello’s sequence is both: it has the structure of a carousel, with segments and arrows at the top, but most of its screens ask the user to try something, such as sending an email to the Inbox or dragging a card to a list. This makes it more likely that the user remembers it, and it is a good model for a longer introduction. ### Walkthrough, tour, or carousel A [Walkthrough](/patterns/Tour) or a [Guided Tour](/patterns/Guided-tour) explains the interface in place. A carousel comes before the interface, and so it has to explain without pointing at anything. That is why it needs a picture of the product on every screen. ### Permission requests A carousel is not the place to ask for permissions without context. If the product needs a permission, explain its benefit on the screen where it matters, before the system asks. ### Measuring it Track the skip rate, the completion rate, and activation for users who saw the carousel compared with users who started directly. --- # Welcome Screen - Type: User interface design pattern - Category: Onboarding > Getting in - URL: https://ui-patterns.com/patterns/WelcomeScreen - Also known as: Welcome Modal, Welcome Message, First-run Screen - Examples: 5 screenshots on the page ## Problem summary The first screen after signup either confirms the user’s choice and points them toward value, or confronts them with an empty product and a list of setup tasks. ## Usage - Use when users arrive from different promises or entry points, and the first screen can reflect the one that brought them. - Use when the next step is not obvious from the interface itself. - Use when you want to point new users to a small number of good starting points. - Do not use when the product can drop users straight into a meaningful first action, which is often the better welcome. ## Solution Greet the user, restate the outcome they came for, and point to what to do first. Keep it to one screen and make it easy to move past. ### Greet and confirm Use the user’s name, and say in one sentence what this place is for. The welcome is the first in-product touchpoint that can keep or break the promise that brought the user in, so make it sound like that promise. ### Lead to the first action Offer the next step that moves the user toward value, as a button or as a small set of starting points. A single primary action is strongest. If the product supports a few distinct first steps, such as starting from a template, connecting tools, or inviting a team, show them side by side and keep the set short. ### Reflect how the user arrived If the user came through an invitation, a campaign, or a template, say so. A user who was invited to a team should land in that team, with a welcome that names who invited them. ### Let users move on A welcome should be easy to dismiss, and should not return at every login. Where the product needs information to personalize the path, combine it with a short personalization form instead of stacking another screen. ## Rationale The welcome screen confirms the decision the user has just made, which makes them more likely to continue ([Commitment and Consistency](/patterns/Commitment-consistency)), and it gives direction at the moment uncertainty is highest. Without it, the user meets an interface that does not yet say what to do. ## Discussion ### Welcome screens that become tours Welcome screens grow, because each new feature wants a mention. A welcome that turns into a feature tour, or one modal followed by another, delays the first action it was meant to bring closer. It should lead somewhere within one click. ### One action or several A single primary action is clearer and easier to measure. Several starting points work when they are genuinely different routes to the same goal, as when a user can start from a template, connect existing tools, or invite a team. Keep them equal in weight only when you do not know which the user needs, and use a [personalization form](/patterns/PersonalizationForm) to find out. ### Welcome versus blank slate A [blank slate](/patterns/BlankSlate) fills an empty screen with guidance for the content that belongs there. A welcome screen speaks to the person, and often sits on top of, or inside, a blank slate. In practice the two are often combined, as in the Slack example. ### Measuring it Track click-through on the primary action and the time from signup to the first meaningful action. --- # Personalization Form - Type: User interface design pattern - Category: Onboarding > Setting up - URL: https://ui-patterns.com/patterns/PersonalizationForm - Also known as: Onboarding Survey, Welcome Survey, Onboarding Quiz, Use-case Picker - Examples: 21 screenshots on the page ## Problem summary Users arrive with different goals, roles, and levels of experience, but a single onboarding path treats them all the same. ## Usage - Use when your product serves clearly different use cases, roles, or levels of expertise. - Use when the answers will visibly change what the user sees next: the template, the first task, or the guidance. - Use when a wrong first path is costly, for example when a beginner is dropped into an expert setup. - Do not use when the answers would only be used for marketing segmentation. - Do not use when the product has one dominant use case that almost everyone shares. ## Solution Ask one to three short questions at the start of onboarding, and use the answers right away to tailor the first experience. ### Ask few questions, with big answers Typical questions are “What do you want to do first?”, “What is your role?”, and “How big is your team?”. Offer a handful of large, clearly worded options, ideally with icons, so answering takes a tap rather than thought. Canva asks a single question, “What will you be using Canva for?”, with four options (personal projects, work and business, education, nonprofit) and one line of explanation under each. Include “Other” or “Something else”, and let users skip. ### Say why you are asking A short line such as “We’ll set up the right starting point for you” makes the form feel like a service. Users answer more willingly when they can see what they get for it. ### Use every answer Each answer should change something the user can see: the [template](/patterns/TemplateGallery) they start from, the first task on their [checklist](/patterns/OnboardingChecklist), the example data, or the features shown first. If an answer changes nothing, remove the question. ### Show the result After the last question, show the tailored starting point immediately, and make it obvious that it was chosen for them. Let users change their answers later from settings. ## Rationale Different users need different first steps. A personalization form lets the product tailor the path to each user’s goal and experience, instead of guessing or showing everyone the same generic tour. Answering also gives users a small sense of ownership over what follows. Having said what they want, they are more inclined to follow the path that was set up for it, in line with [Commitment and Consistency](/patterns/Commitment-consistency). Large, labeled options keep the effort low: choosing among a few visible alternatives is easier than answering an open question, as [Limited Choice](/patterns/Limited-choice) explains. ## Discussion ### Form creep Personalization forms tend to grow, because every team wants one more question: marketing wants to know how the user heard about the product, sales wants company size, research wants a job title. Each question adds effort before the user has seen any value. Ask attribution and research questions later, or not at all. ### Questions users can’t answer yet New users may not know their role in the product, or which feature they will need. Ask about goals and situations they recognize (“Share team updates”) instead of product concepts (“Configure workspaces”). ### What happens when the user skips Some users will skip, and the product should still work for them. Prepare a sensible default path, built from [Good Defaults](/patterns/GoodDefaults), and let users change their answers later in [settings](/patterns/settings). A skipped form is a signal too: it may mean the questions are not worth answering yet. ### Ask later, not never Anything the product doesn’t need on the first day can wait. Following [Progressive Disclosure](/patterns/ProgressiveDisclosure), ask for role, team size, or tools when the user reaches a place where the answer changes something. ### Measuring it Track completion of the form, and activation by answer. Comparing activation across answers shows whether each tailored path actually works for the users who choose it. --- # Smart Prefill - Type: User interface design pattern - Category: Onboarding > Setting up - URL: https://ui-patterns.com/patterns/SmartPrefill - Also known as: Autofill, Auto-detection, Prefilled Fields - Examples: 5 screenshots on the page ## Problem summary Setup asks users to type information the product could already know, such as their name, company, language, or time zone. ## Usage - Use when reliable signals exist: a work email domain, a social login profile, device settings, or location. - Use when the inferred value is easy to check and correct. - Use when typing is costly, for example on a phone. - Do not use when the inference is unreliable or sensitive. - Do not use when users would be surprised that the product knows the information. ## Solution Fill in the fields with what the product can infer, and let the user confirm or change them. ### Use signals the user expects you to have Derive the company name from a work email domain, language and time zone from the device, and name and photo from a social login. Use only signals the user would expect the product to have, and be ready to explain where a value came from. ### Show what you filled in Present inferred values for confirmation (“We set your time zone to Central European Time. Change.”), and mark them as detected. Never submit inferred data on the user’s behalf without showing it. ### Make every value easy to change A prefilled field should look and work like any other field. Users who find the guess wrong must be able to correct it in one step. ### Check the guess before showing it Clean inferred values before showing them. A name taken from the part of an email address before the @ sign needs the same care as any other data: strip tags and aliases, and fix capitalization. ## Rationale Confirming takes less effort than typing, and an accurate guess signals that the product is paying attention. Each field the user does not have to fill in makes setup shorter and lowers the chance that they abandon it. Prefilled fields work like [Good Defaults](/patterns/GoodDefaults): most people leave a preset value as it is, the tendency described by [Status Quo Bias](/patterns/Statusquo-bias). That is why the value has to be right, and why defaults that change who gets access need extra care. ## Discussion ### Wrong guesses cost trust A wrong guess is worse than an empty field, because the user has to notice and correct it. A name taken from the part of an email address before the @ sign comes out wrong when the address uses an alias with a plus sign. One product we looked at filled in the alias as the user’s name, while another removed it and capitalized the rest. Prefilled values need a sanity check, and the field must stay editable. ### Defaults that change who has access Some prefilled settings do more than save typing. Both Slack and Notion offer a pre-checked option that lets anyone with the company’s email domain join the new workspace. That may be what the user wants, but it widens access, so say clearly what it does and make it easy to uncheck. ### Invasive inferences Users are comfortable with a time zone or a company name taken from the email domain. They are less comfortable when the product shows it knows their location, employer, or contacts without being told how. Explain the source of anything that could surprise them. ### Measuring it Track how often prefilled values are edited, and the setup completion time. A value that is edited most of the time is a guess you should stop making. --- # Connected Accounts - Type: User interface design pattern - Category: Onboarding > Setting up - URL: https://ui-patterns.com/patterns/ConnectedAccounts - Also known as: Integrations Setup, App Connections, OAuth Connect - Examples: 9 screenshots on the page ## Problem summary The product only becomes useful once it can reach data and actions in the user’s other tools, but connecting accounts feels technical and risky. ## Usage - Use when first value depends on data or actions in another service, such as a calendar, a file store, or an issue tracker. - Use when users already work in tools that your product can connect to. - Use when connecting saves work the user would otherwise do by hand. - Do not use when the connection could wait until after first value. ## Solution Show the integrations the user is most likely to want, make connecting each one a single clear action, and explain what connecting will do. ### Show familiar tools as a short list Present integrations as rows or cards with recognizable logos, grouped by what they do (calendar, files, assistants). Recommend the one or two that matter most for the user’s goal, instead of showing the whole directory first. Offer “See all apps” for the rest. Canva’s “Connect your first ad account” screen shows three platforms side by side, each with a one-line description and its own connect button, and its Apps page recommends integrations such as Gmail, Notion, and Google Drive with a sentence on what each one does. ### Explain before the permission screen Before the provider’s permission screen appears, say in plain words what the product will read or do, and what it will never do. A permission screen the user did not expect is the point where many connections end. ### Show the result immediately After connecting, show what the connection brought: the first imported events, files, or items. Seeing the result makes the effort worth it. ### Keep it optional and reversible Let users skip the step and come back to it later, and make disconnecting easy to find. ## Rationale Explaining the benefit and the limits before the permission screen reduces the perceived risk of connecting, and showing the result right away rewards the effort. Placing the step where the product has just shown it needs the connection makes the request feel like part of the task, which is the timing [Kairos](/patterns/Kairos) argues for. ## Discussion ### Asking for too much Broad permissions requested “just in case” make users stop and reconsider. Request the narrowest access the feature needs, and ask again later in context if more is needed. ### Connections that could wait If the product can deliver first value without the integration, offer it afterward. A connection step placed before value asks the user to take a risk without a reason to. ### Connected accounts and data import Connecting an account keeps two systems in sync, while a [data import](/patterns/DataImport) copies data once. Some products offer both, and users should be able to tell which one they are choosing. ### Connected accounts and social login [Social Login](/patterns/SocialLogin) is a connection too, made at signup and limited to identity. A connected account at the integration step asks for more, so it needs its own explanation and its own consent. ### Measuring it Track the connection rate at the integration step, the failure rate, and the activation of connected users compared with unconnected users. --- # Data Import - Type: User interface design pattern - Category: Onboarding > Setting up - URL: https://ui-patterns.com/patterns/DataImport - Also known as: Import Tool, Data Migration, Bring Your Data - Examples: 6 screenshots on the page ## Problem summary Users switching from another tool face an empty product, and the effort of recreating their work is a strong reason to stay where they are. ## Usage - Use when your users typically switch from spreadsheets or a competing product. - Use when the product’s value depends on the user’s own data. - Do not use when imports are so complex that a broken import would damage trust. Start with a guided manual path instead. ## Solution Offer import as a first-class starting point, alongside starting from scratch or from a template. ### Support the sources users come from Accept the formats and tools your users actually use, such as CSV and Excel files and the leading competitors. Let them drop a file, pick one, or paste the data in. Amplitude’s “Select a data source” screen groups sources by platform and category, lists popular ones first, has a search field, and offers “Request Integration” for the ones that are missing. ### Ask where the data comes from A question during setup (“What tools are you currently using?”) lets the product offer the right import path, and signals that migration is expected. ### Preview before committing Show how the imported items will look before the import runs. Map fields automatically where possible, and let users fix mappings. ### Handle size and failure well Run large imports in the background and tell the user when they finish. Report clearly what was imported, what was skipped, and why. Make imports reversible. ### Keep the data up to date If the user will keep working in the other tool, offer a [connected account](/patterns/ConnectedAccounts) that syncs the data instead of a one-time import. ## Rationale Import removes the largest part of the switching cost and fills the product with material the user cares about. People value what they already have and have worked on, as the [Endowment Effect](/patterns/Endowment-effect) describes, and the effort already spent in the old tool is a [sunk cost](/patterns/sunk-cost-effect) that keeps them from leaving. That makes first value both faster and more relevant, because the user sees their own work in the new tool. ## Discussion ### Silent failures Partial imports that fail without saying so do more harm than no import. Show a summary of what happened, and give users a way to retry the items that failed. ### Import versus sync An import copies data once. A connected account keeps two systems in step. Make clear to users which one they are choosing, and what happens to the data in each place afterward. ### Measuring it Track import completion rate, error rate, and the activation of importing users compared with users who start empty. --- # Role-based Invite - Type: User interface design pattern - Category: Onboarding > Setting up - URL: https://ui-patterns.com/patterns/RoleBasedInvite - Also known as: Invite with Permissions, Role Picker, Access Levels - Examples: 2 screenshots on the page ## Problem summary Senders hesitate to invite people because they don’t know what access they are giving, and recipients land in an experience designed for someone else. ## Usage - Use when people take different roles, such as viewer, commenter, editor, or admin. - Use when sharing too much would be a real risk. - Do not use when all users have the same role. ## Solution Let the sender choose what each invited person can see and do, in the invite dialog itself. ### Offer a few clearly named roles Let the sender pick a role, with a one-line explanation of what it allows (“Can comment, can’t edit”). Three or four roles are enough for most products, and the names should describe what the person can do. ### Show who has access, and how List the people who already have access with their roles, and show a separate setting for people who only have the link, with its own role and a clear statement of who can open it. ### Default to the least access Preselect the lowest role that lets the recipient do the expected task. Granting more should be a deliberate choice, which is what [Good Defaults](/patterns/GoodDefaults) means for permissions. ### Tailor the recipient’s first experience to the role Use the chosen role to decide where the recipient lands: a reviewer on the item to review, an admin on settings and permissions. ## Rationale A clear preview of what each role allows reduces the sender’s uncertainty, which is often the reason an invitation is never sent. Role-specific first experiences give each recipient the context they need instead of an interface built for someone else. ## Discussion ### Defaults that grant too much Defaults that grant more access than needed erode trust the first time a sender notices. Default to the least access that lets the recipient do the expected task. ### Link access is a role too Sharing by link is a role choice, with its own audience (restricted, an organization, anyone) and its own level (viewer, commenter, editor). Show both in the same place, so the sender sees the whole picture. ### Invites and guests A role-based invite works with [Invite Friends](/patterns/invite-friends), which is about getting people to send invitations at all. For recipients who only need to look at one thing, [Guest Access](/patterns/GuestAccess) lets them in without creating an account, and a viewer role is the natural setting for it. ### Measuring it Track invitation completion rate, and first-action rate by role. --- # Permission Priming - Type: User interface design pattern - Category: Onboarding > Setting up - URL: https://ui-patterns.com/patterns/PermissionPriming - Also known as: Pre-permission Prompt, Permission Rationale, Soft Ask - Examples: 3 screenshots on the page ## Problem summary The system dialog for notifications, location or camera gives no context, and users who deny it are hard to ask again. ## Usage - Use when a feature needs a system permission to work, such as notifications, location or the camera. - Use when the benefit of the permission is not obvious at the moment of asking. - Do not use when the permission is not needed for what the user is doing right now. ## Solution Show the product’s own screen first, explaining in one sentence what the permission gives the user, and only then trigger the system dialog. ### Ask when it matters Ask at the moment the user reaches for the feature that needs the permission, not at launch. A request that arrives with a reason the user can feel, “Get a reminder when your team replies”, gets a better answer than one that arrives before the user has seen anything. ### Explain the benefit in one sentence Say what the user gets, not what the app needs. Strava’s screen asks “Want an occasional nudge?” and follows with a single sentence: “Allow notifications so you can get check-ins and reminders to help you reach your goals.” The word “occasional” also tells users how much to expect. ### Prepare the user for the system dialog The system dialog looks the same in every app and cannot be changed, so tell users what to expect. Strava adds “Make sure you select ‘Allow’ on the next step to receive notifications from Strava” above a button that says “Choose permissions”, so the button names what it does and the next screen is no surprise. ### Make declining easy Include a secondary choice such as “Not now”, and let users continue if they decline. Offer the permission again later, in context. If they denied it at system level, explain how to enable it in settings. ## Rationale The system dialog can usually be shown once. If users deny it, the product loses the permission, and a denial is hard to reverse. A first screen of your own is a soft ask: users who say no to it have not used up the system prompt. Timing and context raise motivation at the moment of the decision. This is the idea of [Kairos](https://learningloop.io/plays/psychology/kairos): the right moment for a request. A reason the user can understand and a benefit they want makes a yes more likely than a bare dialog does. ## Discussion ### Priming is not a disguise A priming screen that imitates the system dialog, or that hides the way to decline, trades a short-term gain for lasting distrust. Make clear that it is your own screen, and keep the decline option visible. ### Early or in context Strava asks for notifications at the end of its sign-up flow, before the user has recorded an activity. That is simple to build, and the benefit (“check-ins and reminders”) is stated in general terms. Asking after the user’s first activity, with a reminder tied to what they just did, gives a more concrete reason. ### Tie it to what the user just decided Duolingo asks for notifications right after the user has set a daily goal, and the priming screen picks up that thread: “I’ll remind you to practice so it becomes a habit!” The reason follows from the choice the user has just made, which makes the request easier to accept than one that arrives out of the blue. The system dialog then appears over the priming screen, with an arrow pointing at “Allow”. ### Measuring it Track the permission grant rate, and use of the feature that needed the permission. --- # Playthrough - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/playthrough - Also known as: Interactive Tutorial, Warm-Up Exercise - Examples: 9 screenshots on the page ## Problem summary The user wants to know how to use the different features of the application. ## Usage - Use when you want to introduce the core interactions of your product before letting them enter the full product - Use when you want to let users learn and explore the core skills needed to use the product - Use when you want to allow modeless assistance - Use when you want to allow users to get out into the full product world without facing horrible failure if they hadn’t gone through this - Use when you want to let users learn by doing - Use when you want to create a risk-free space for users to build skills and earn starting achievements - Use when you want users to develop a set of core competencies that help users transition to advanced actions - Use when you want to provide a positive first impression through giving a person an early success - Do not use when there is a chance that users will feel that you are providing too much instruction or hand-holding. At least make it possible to skip. ## Solution A dedicated and authentic space where beginners can safely explore and learn core skills. Spare users from facing horrible failure by introducing them to core interactions. Let users learn and explore core skills before they enter the full product experience. Provide modeless text assistance and basic goals so they can play the interface but also learn the interface as they play. A Playthrough is something that you provide, before letting someone enter a full product experience, that introduces them to the core interactions and let’s them learn and explore those core skills. This pattern is known from games, where new players are encouraged to try out a starter level, where they get modeless text assistance and some basic goals, so that they can play the game, but also learn the game, as they play. ### Let users learn through real tasks By asking users to make their first move on the application, an application can get users engaged right off the bat. This is common in applications that depend on curation by the user to get the app working. ### Continue the experience seamlessly into the full product Carry any [achievements](http://ui-patterns.com/patterns/CollectibleAchievements) earned in the Playthrough forward into the full, and normal, product experience. Make the transition from the Playthrough to the normal product experience as seamless as possible. ### Provide a skip option Some people just want to get into deep waters form the start. Always allow escaping a Playthrough by skipping it. ### Don’t drag it out Limit the playthrough to relevant core tasks and user test your way into finding out what length is comfortable for users. Some users might like longer playthroughs than others, so be sure to allow escaping the experience, but still letting users keep their achieved artifacts. ## Rationale By allowing users to get out into the full product world early and safely, you can keep users from facing horrible failure if they hadn’t had an introduction. ## Sources1 UX Flows: How to Turn Onboarding into an Amazing First Date with Your User by MK Cook
2 UI design pattern tips: walkthroughs and coach marks
3 Patterns for new user experiences by Krystal Higgins
--- # Guided Tour - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/Guided-tour - Also known as: User Guided Tutorial, Just-in-time Tooltips - Examples: 32 screenshots on the page ## Problem summary The user wants to learn about new or unfamiliar interface features. ## Usage - Use when you want to help users along getting accustomed to your user interface. - Use when you want to notify your users of new or unfamiliar features - Use when your user interface is not self-explanatory ## Solution “Just-in-time” guidance is triggered as the user explores. Allow users to learn at their own pace using tooltips, overlays, models, and alerts hinting optimal use of an interface within the context of everyday use. Connect hints with clear completion states. Too many and too plain hints lead to frustration. Don’t overdo it and be sure to allow escape. Create a series of individual hints that progressively appear during the first-time use of a product or interface. Hints can be anything from tooltips, overlays, to modal alerts. Some users appreciate the help and others don’t. Be sure to always allow escape; to dismiss your guided tour. ### Product-guided vs User-guided. Decide whether you want to let the tour be product guided or user-guided. In a product-guided tour, hints are automatically progressed in linear succession, while hints in a user-guided tour are triggered as the user reaches appropriate points in their experience. For user-guided tours, hints may appear in different orders for different users. ## Sources1 Patterns for new user experiences by Krystal Higgins
--- # Walkthrough - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/Tour - Also known as: Intro Tour, Joyride, Guided Tour - Examples: 35 screenshots on the page ## Problem summary The user wants to learn the products and services you offer in order to make a decision to join a service or buy a product. ## Usage - Use to give users an insight into what a product is about before they spend time or money on the full product. - Use to help sell your product. - Use to allow users to make an “informed” purchase decision. - Use to instruct users in how to solve common tasks. - Use to teach users about your product and what it can do. - Use to teach users about uncommon features. - Use to teach users about non-website related issues. ## Solution Present the main features of your product before the user starts using it. Present your product and/or value proposition before the real user experience begins. Walkthroughs are often presented as either a static or animated slideshow or with video. Keep it short and to the point as users often skip or breeze through in order to get started. A Walkthrough explains a product or service in terms of features, benefits, and in general what the product or service allows you to do. It is most often split into more than one section, which is sometimes put on separate pages. With this in mind, here are a few principles to keep in mind when developing a Walkthrough. ### Focus on users’ tasks Whether the Walkthrough is strictly a marketing tool or a tool to teach, a focus on the users’ tasks is important. How can you help them? Aim for a good balance between only describing essentials and explaining everything. Only describing essentials might not give users an elaborate enough view of your product to aid their decision to engage with your product. If you are too elaborate you might on the other hand scare then away. Resist the urge to show off the latest and greatest features – the most important thing is to convince your users that your product will help them with their fundamental problems. New users aren’t interested in your bells and whistles; they just want to accomplish their goals1. ### Provide visual references Don’t just write about your product and its features. Show it! Include screenshots, illustrations, and even video clips of how to use your product. This will allow your users to get a better feeling of where exactly to click – but also how easy your product actually is – how it was meant to work and be used. ### Include direct links As users use Walkthroughs to learn about your product or service, they will go back and forth between the Walkthrough and the product. It is their reference point, so make it easy for them to go back and forth between the two. Provide direct links, if possible, to the sections you explain. ### Address issues or concerns up front Address the top concerns your users might have when they are trying to decide whether or not to use your product or not. “Is it safe”, “Can I import my data easily?”, “Can I export my data if I decide to move?”. Put any concerns to rest so that your users can start using your product or service with confidence. ## Rationale A Walkthrough of your product or service helps inform users about: - What your product can do - If your product is what they’ve been looking for - If your product will help users accomplish their tasks - Whether or not they should join your service or pay for your product Purchasing a product or service can be costly and users will need a significant amount of persuasion and encouragement before buying in. A Walkthrough allows users to get a glimpse of your product without having to sign up. ## Sources1 Guided tour design pattern at welie.com by Martin van Welie
2 Submit now – Designing persuasive web sites, New Riders, 2003
--- # Coachmarks - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/coachmarks - Also known as: Instructional Overlay - Examples: 7 screenshots on the page ## Problem summary The user needs help to understand a complex user interface ## Solution Display text, arrows, and images atop a modal overlay explaining the function of the interface. Coachmarks represent multiple help call-outs that appear on a transparent overlay. By using text and often arrows and images, they point to and explain the functionality of the user interface. ## Rationale Coachmarks can help explain overly complicated or novel user interfaces to users, but they do not help solve the underlying problems of poorly composed interfaces. Consider other onboarding patterns before settling with coachmarks. ## Discussion Using coachmarks adds another mode (or layer) to your user interface. They thereby obstruct interaction to the elements they help explain. If users are in the middle of a task, coachmarks can be perceived as an obstruction, which they may want to quickly dismiss without reading. This makes the Coachmark pattern borderline an anti-pattern: they do not solve the underlying problems of a confusing user interface. Adding a new level of complexity to help explain an already complex interface is treating symptoms and not the root course. Furthermore, attention is diverted from one single tip to the explanation of the entire user interface. You are essentially asking the user to memorize not only how to solve the task at hand, but also all other tasks that might come at hand. Multiple coachmarks increase the cognitive load – especially on shot-term memory. ### Address underlying issues first Before settling on using Coachmarks, try to see if you can solve the problem in other ways first. Address any underlying user interface issues before you introduce Coachmarks. Consider a [Playthrough](http://ui-patterns.com/patterns/playthrough) or a [Guided Tour](http://ui-patterns.com/patterns/Guided-tour), which allow users modeless assistance where they can interact with the elements about which they are being instructed. If you must use Coachmarks, be easy on the users cognitive load. We can only remember 3-4 things at a time. Lay out coachmarks in a readable and easy-to-skim way. Instead of merely displaying a screenshot, try placing the Coachmarks above the user’s normal view of the user interface. ## Sources1 Patterns for new user experiences by Krystal Higgins
2 Instructional Overlays and Coach Marks for Mobile Apps
--- # Hotspot - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/Hotspot - Also known as: Beacon, Pulsing Hotspot, Discovery Dot - Examples: 2 screenshots on the page ## Problem summary Some features are useful but not urgent, and explaining them with tours or modals interrupts users who are busy with something else. ## Usage - Use when the feature is optional or secondary. - Use when users should discover it at their own pace. - Use when you want to point at a specific element in context without interrupting the task. - Do not use when the user must act on the information. - Do not use when several hotspots would compete on the same screen. ## Solution Place a small, softly animated dot next to the feature, and let the user open it when they are curious. ### Keep the dot small and calm A slow pulse draws the eye without demanding attention. A fast or large animation turns a hint into an alarm, and users learn to ignore it. ### Explain in one sentence When the user clicks or hovers, show a short tip: one sentence about what the feature does and why it is useful, and optionally an action. Longer explanations belong in a [guided tour](/patterns/Guided-tour) or a help page. ### Let the user dismiss it Remove the hotspot once it has been opened, or once the user has used the feature. A tip with an obvious close or “Got it” button gives the user control over when to learn. ### Use few Show one or two hotspots per screen, and only for features that are relevant to this user right now. ## Rationale A hotspot invites instead of interrupting. The animation draws attention through salience, and curiosity does the rest, leaving the user in control of when to learn. It points at the exact place the feature lives, so the user does not have to find it after reading an explanation elsewhere. ## Discussion ### Hotspots that never go away A dot that stays after the user has seen it turns into visual noise. Retire it once it has been opened, or after a fixed number of sessions. ### Too many dots Several pulsing dots on the same screen compete with each other and make the interface look broken. If more than two features need attention, use a [guided tour](/patterns/Guided-tour) or a [feature spotlight](/patterns/FeatureSpotlight) instead. ### Hotspot, coachmark, or tour A hotspot is a single, optional pointer that the user opens. A [coachmark](/patterns/coachmarks) explains an element and is often shown automatically. A [guided tour](/patterns/Guided-tour) walks the user through several elements in a fixed order. [Inline hints](/patterns/inline-hints) sit permanently next to the thing they explain. Use the lightest form that does the job. ### Accessibility A pulsing dot is easy to miss for users who navigate with a keyboard or a screen reader, and animation can be a problem for users who prefer reduced motion. Make hotspots reachable and readable without a mouse, and respect the reduced-motion setting. ### Measuring it Track the open rate, and the use of the feature after the hotspot was opened. --- # Inline Hints - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/inline-hints - Also known as: Inline Cues - Examples: 4 screenshots on the page ## Problem summary The user wants to learn about new or unfamiliar interface features in an unobtrusive way ## Usage - Use when you want to improve readability of guided help, as Inline Hints are formatted consistent with other content - Use when you don’t want to interrupt or obscure a content experience - Use to provide helpful information in combination with [Blank Slates](http://ui-patterns.com/patterns/BlankSlate) - Do not use when you want to be absolutely sure users have seen your hint, as the subtle appearance that flows the rest of the content is at the risk of being ignored. - Do not use for conveying mission-critical instructions. ## Solution Blend in hints and coaching with content for a seamless experience. Use the language of the existing layout to seamlessly blend in tips and coaching. The integrated experience of using the shapes of normal and everyday content allows for a more easily readable and relevant form of instruction that doesn’t interrupt or obscure a content experience. Hints are integrated seamlessly into the layout of surrounding content so that they do not obstruct or interrupt user interaction. Inline hints do not need to be dismissed although they are seen to be dismissible, to disappear after continued use, or, in the case of [Blank Slates](http://ui-patterns.com/patterns/BlankSlate), when the user populates the screen1. Do not use this pattern if you want to be absolutely sure users have seen your hint, as the subtle appearance that flows the rest of the content is at the risk of being ignored. Use Inline Hints to reinforce other instructions provided elsewhere in the interface. As Inline Hints blend in with the rest of the content, users get easily confused if the hint’s information is not relevant to its surrounding content. Do not overuse them; make sure they are relevant and do not overwhelm the primary content experience. ## Rationale By having inline hints take the shape of normal, everyday content, designers hope that they will be more easily readable and relevant than other forms of instruction. ## Sources1 Patterns for new user experiences by Krystal Higgins
--- # Onboarding Checklist - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/OnboardingChecklist - Also known as: Getting Started Checklist, Setup Checklist, Onboarding Tasks - Examples: 4 screenshots on the page ## Problem summary New users don’t know which of the many things they could do will actually lead to value. ## Usage - Use when value depends on a handful of setup and usage actions. - Use when users will complete them across several sessions. - Use when you know which actions predict that users stay. - Do not use when the product can deliver value in a single action. - Do not use when the checklist would only list features. ## Solution Show a short list of the tasks that lead to value, with progress through them. ### Three to seven tasks, phrased as outcomes Phrase each task as something the user wants (“Launch a welcome flow”), not as a feature (“Visit Automations”). Order the tasks so the earliest produce value quickly, and say roughly how long each takes. ### Make every task a shortcut Each task should take the user straight to where it is done. Mark it complete automatically when the user does it anywhere in the product, not only through the checklist. ### Count what is already done Start with something ticked, such as the account or an imported brand. Progress that has already been made makes the rest feel closer. ### Keep it compact and dismissible Keep the checklist visible but small. Let users dismiss tasks or the whole list, and retire it once it is complete. ### Choose the tasks from evidence Pick tasks by looking at which actions predict retention among your users, not at which actions the business wants. ## Rationale A checklist makes the path to value explicit and finite. Visible progress draws on the goal-gradient effect (effort rises as the goal gets closer) and on endowed progress (a head start makes people more likely to finish). Unfinished items also draw users back, because people tend to remember and resume tasks they have started, the [Zeigarnik Effect](/patterns/zeigarnik-effect). ## Discussion ### From pattern to workshop If research shows new users struggle to find the first useful action, [Learning Loop's behavioral design workshop guide](https://learningloop.io/guides/behavioral-design-workshop/) offers a way to diagnose the barrier and compare alternative onboarding designs. The [Ideas first, Patterns later exercise](https://learningloop.io/plays/workshop-exercise/ideas-first-patterns-later) helps teams generate ideas before referring to behavioral patterns. A checklist is not automatically the right intervention; validate whether it helps people reach value. ### Whose tasks are they? Checklists that list what the business wants (invite teammates, upgrade) before what the user wants undermine the pattern. Put the tasks that give the user value first. Never mark a task complete that the user has not done. ### Checklist, meter, and steps A checklist lists separate tasks the user can do in any order. A [completeness meter](/patterns/CompletenessMeter) shows how close the user is to a goal, often as a percentage. [Steps Left](/patterns/StepsLeft) shows position in a fixed sequence. Many products combine the first two, as Mailchimp does, with a bar above the list. ### Measuring it Track completion per task, and the retention of users who complete the checklist compared with similar users who don’t. Test causation before you push everyone through it: users who complete a checklist may simply be more motivated. ## Sources - Nunes, J. C. & Drèze, X. (2006). The endowed progress effect: How artificial advancement increases effort. *Journal of Consumer Research*, 32(4), 504–512. --- # Feature Spotlight - Type: User interface design pattern - Category: Onboarding > Finding your way - URL: https://ui-patterns.com/patterns/FeatureSpotlight - Also known as: Feature Announcement, What’s New, New Badge, Feature Discovery - Examples: 8 screenshots on the page ## Problem summary The user never discovers features they haven’t used yet, whether those are new releases or capabilities the product has had for years. ## Usage - Use when a feature is relevant to the user’s current work, and they have not used it yet. - Use when users keep using a slower workaround for something the product can do directly. - Use when a new feature changes how existing users work. - Use when you want onboarding to continue after the first sessions, as users and the product grow. - Do not use when the feature is minor or relevant to only a few users. - Do not use when the spotlight would interrupt a task in progress. ## Solution Bring a feature to the user’s attention at the moment it is useful, and match the size of the spotlight to the size of the feature. ### Time it to the user’s behavior The best moment to spotlight a feature is when the user’s behavior shows it would help: after they have formatted a table by hand for the third time, or exported data to do something the product can do itself. A feature shown at that moment explains its own value, which is the idea behind [Kairos](/patterns/Kairos): the right message at the right moment. ### Match the format to the feature - **A contextual hint or [hotspot](/patterns/Hotspot)** suits a feature in its place in the interface, shown when the user is near it. - **A “New” badge** on a menu item or button suits a minor new feature. It is easy to notice and easy to ignore. - **A short modal** suits major changes only. Show it at the start of a session, never in the middle of a task. - **A “What’s new” page** or changelog gives interested users the full list of recent changes, and gives the other formats something to link to. ### Target the spotlight Show each spotlight to the users the feature is relevant to: those who use the related part of the product, or who have been using a workaround the feature replaces. A feature that is new to the product is often old news to some users and unknown to others. ### Link straight to the feature Every spotlight should take the user to the feature itself, ready to try. ### Retire it Remove the badge or hint once the user has tried the feature, or after a few sessions. Permanent “New” labels stop meaning anything. ## Rationale Onboarding usually ends after the first few sessions, but users keep growing and the product keeps changing. Most users only ever learn a fraction of what a product can do. Feature spotlights extend onboarding into continuous onboarding, so users’ capability keeps growing with the product. A spotlight tied to the user’s own work makes the value easy to see, and short, relevant spotlights spark curiosity. ## Discussion ### New to the product, or new to the user? A feature announcement is one kind of spotlight: the feature is new to everyone. But for any given user, most undiscovered features are not new at all. Products that only spotlight new releases miss the larger opportunity of showing each user the existing features they have not found yet. ### Spotlight fatigue A modal at every login teaches users to close everything unread, including the spotlights that matter. Use the smallest format that will be noticed, and keep large spotlights rare. ### What a good one looks like Canva introduces its Grow feature in a modal with a headline, three one-line benefits (create, launch, learn), and a single button, “Start with Grow”. It appears over a screen the user was already using, and has one way forward. Canva’s Apps page does the quieter version: a featured integration at the top and “Top picks for you” below, in the place where users already go to look for new capabilities. ### Spotlight, tour, or coachmark A spotlight points at one feature. A [guided tour](/patterns/Guided-tour) or [coachmarks](/patterns/coachmarks) explain several elements in sequence, and are better kept for the first session. Reaching for a tour every time something new ships turns it into an interruption. ### Release notes and spotlights A changelog lists what changed. A spotlight tells a specific user why a feature matters to them. Write spotlights in terms of the user’s work (“Schedule your update to send automatically”), and lead with that benefit before the feature’s name. ### Measuring it Measure adoption of the spotlighted feature among the users who saw the spotlight, compared with similar users who did not. --- # Blank Slate - Type: User interface design pattern - Category: Onboarding > Reaching first value - URL: https://ui-patterns.com/patterns/BlankSlate - Also known as: Empty State - Examples: 79 screenshots on the page ## Problem summary The user wants to get started using the application but needs guidance in the form of an example of how the application will look, feel and behave when in full function and filled with data. ## Usage - Use when your application feels without life and empty before the user has started to enter data into the system. - Use when you want to motivate the user to start using the system. - Use when you want to aid the user in getting started with your web application. - Use when you want to show best practices of using your web application. - Use when you want to guide the user to get a good start with your web application. ## Solution Comfort, guide, or encourage users when there is no content to show. Although Blank Slates aren’t typical, they are important opportunities for good design to avoid user disappointment or confusion. Make sure users feel safe and know what to do next when they use your product for the first time or have cleared all content. Give the user an impression of how the system will look once filled with data – or guide and encourage them to start filling it with data. You can present the user with several kinds of helpful information on a blank slate: 1. Show a sample screenshot of how the page will look once filled up with content, 2. insert quick tutorials and help texts, 3. explain the best ways to get started, 4. ask questions the first-time user will ask: What is this? What do I do now?, and 5. set expectations to help reduce frustration, intimidation, and overall confusion. (Source: *[Getting Real by 37signals](http://gettingreal.37signals.com/toc.php)*) ## Rationale The blank slate is generally the first screen the user is presented with when they start something new in an application. It can the screen they are directed to after creating an account or the first screen they see when using part of an application they haven’t used before. *The blank slate tells the user what the page they are on will look like, once it has eventually been filled with content*. Creating a blank slate sets the user’s expectations for your service. New users are often intimidated by empty screens with little or no guidance. Guiding users with a prepopulated starting state is the best way to establish trust and gain understanding. Make sure the first impression the user gets of your web application is positive. Let them know why they should stick around. --- # Template Gallery - Type: User interface design pattern - Category: Onboarding > Reaching first value - URL: https://ui-patterns.com/patterns/TemplateGallery - Also known as: Templates, Starter Templates, Template Picker - Examples: 10 screenshots on the page ## Problem summary Facing a blank canvas, the user doesn’t know what a good result looks like or where to begin. ## Usage - Use when users create documents, boards, projects, designs, or workflows from scratch. - Use when good results follow recognizable structures that can be reused. - Use when you want to show what the product can do by example. - Do not use when templates would push users toward uses that don’t fit their goal. ## Solution Offer ready-made starting points that the user can pick, open in one click, and adapt to their own needs. A template gallery is the natural companion to a [Blank Slate](/patterns/BlankSlate): where the blank slate explains what belongs on an empty page, the gallery fills it. ### Preview every template Give every template a visual preview, so users can recognize what they want at a glance. A name such as “Weekly team update” helps, but a [thumbnail](/patterns/Thumbnail) of the finished result helps more. Canva’s template page goes further: it shows the template at full size with all its pages, a “Customise this template” button, and a “More like this” grid for comparing alternatives. ### Start small and relevant During onboarding, show a small set of templates matched to the user’s goal, for example based on their answers in a personalization form. Group the full collection into clear categories with search for later. ### Make starting instant Let users start from a template with a single click, and drop them straight into an editable copy. Fill the template with realistic example content, so the user can see how it works and replace it piece by piece. ### Keep a blank option Experienced users often know exactly what they want. Include a “Blank” option alongside the templates. Amplitude’s “Create Guide” dialog lists each guide type (tour, announcement, checklist, banner, tooltip) with a preview, and keeps “Start a blank guide” right beside “Use template”. ### Let users share their own Over time, let users and teams publish their own templates. A community gallery becomes an entry point to the product in its own right, and shows uses its designers never planned. ## Rationale Editing is easier than creating. A template gives the user a model to imitate, shortens the path to a result they are proud of, and teaches the product’s structure by example: the user learns how a good board or document is built by changing one. Changing a template also makes it the user’s own. The [IKEA effect](/patterns/ikea-effect) describes how people value what they have put effort into, and a template that was adapted feels more like the user’s work than one that was generated for them. ## Discussion ### Too many templates A gallery with hundreds of undifferentiated options recreates the blank-page problem as a choice problem, the situation [Limited Choice](/patterns/Limited-choice) warns about. Curate a short list for new users, and use categories, search, and recommendations for the rest. ### Templates that don’t fit A template that looks impressive but doesn’t match the user’s goal can lead them into a structure they later have to undo. Describe what each template is for, and who it suits. ### Measuring it Track template use, time to the first meaningful result, and retention of users who started from a template compared with users who started blank. --- # Suggested Action - Type: User interface design pattern - Category: Onboarding > Reaching first value - URL: https://ui-patterns.com/patterns/SuggestedAction - Also known as: Next Best Action, Next Step Prompt, Recommended Action - Examples: 7 screenshots on the page ## Problem summary After finishing a step, or on arriving at an empty page, users often don’t know what to do next, and the momentum fades. ## Usage - Use when there is a clear next step that builds on what the user just did or where they are. - Use when the product can infer that step from the user’s progress. - Use when a single suggestion would help more than a menu of options. - Do not use when the suggestion would interrupt a task in progress. ## Solution Show one primary suggestion that follows from where the user is, with a short reason. ### One suggestion, one reason Say what to do and why in a sentence: “Send a ready-made email straight to your inbox so you can see how it works.” A reason makes the step easy to accept, and one suggestion at a time keeps the decision small. ### Put it where attention already is Place the suggestion in the user’s line of sight: in the empty state, after the action, or at the top of the page. Make it the most prominent element, with any secondary option clearly lighter. ### Make the first step easy and safe The best first suggestions are quick, low-risk, and visible: sending a test to yourself, trying a template, or opening a sample. They give the user a result before they commit anything. ### Let users dismiss it Allow the suggestion to be dismissed, and don’t bring it back unchanged. ## Rationale A suggested action turns a finished step, or an empty page, into the start of the next one. It keeps the user in the window of opportunity, the moment [Kairos](/patterns/Kairos) points to, and reduces decision effort, because the product has already chosen a sensible next step. ## Discussion ### Suggestions that serve the business Suggestions that mainly serve the business, such as upgrades or invitations, work against the pattern when the user has not yet reached value. Keep early suggestions about what the user came to do. ### One versus several Offering several equal options is a menu, not a suggestion. When the next step isn’t obvious, an [onboarding checklist](/patterns/OnboardingChecklist) or a [personalization form](/patterns/PersonalizationForm) is a better fit than a long row of cards. ### Persistent banners A suggestion can live in a banner that stays until the task is done. Amplitude’s empty home screen carries a banner, “Connect your data to start gaining insights”, with “Set Up Amplitude” as the primary button and “Invite Members” as the secondary one. Keep such a banner honest: it should go away when the step is done, and should not return for steps that are optional. On an empty page, pair it with a [blank slate](/patterns/BlankSlate). ### Measuring it Track click-through on suggestions, and the share of users who complete the next key action. --- # Success State - Type: User interface design pattern - Category: Onboarding > Reaching first value - URL: https://ui-patterns.com/patterns/SuccessState - Also known as: Completion Screen, Celebration Moment, Confirmation Screen - Examples: 3 screenshots on the page ## Problem summary The first meaningful success often passes without the user noticing it, and without leading anywhere. ## Usage - Use when the user has just completed a meaningful first action. - Use when the result is not obvious from the interface alone. - Do not use when the action was trivial. Celebrating it would feel patronizing. ## Solution Mark the moment the user succeeds, say what they achieved in their own terms, and show what to do next. ### Name the achievement Say what happened, in the user’s words and not the system’s: “The email was saved as a card in your Inbox”, or “Your first update is on its way to six people”. A generic “Success!” confirms that something happened. A named result tells the user what it was. ### Show the result Show the outcome next to the message: the new card, the sent update, the published page. Trello’s confirmation shows the email it just turned into a card, sitting in the Inbox beside the message. ### Offer the next step Give one clear way forward, such as “Continue” or “Plan the next one”. The success is the best moment to suggest what to do next, because the user has just seen that the product works. See [Suggested Action](/patterns/SuggestedAction). ### Keep the celebration in proportion A small animation or a friendly illustration fits a real milestone. Confetti on every click loses its meaning quickly. Save the larger moments for the ones the user will remember: the first sent update, the first published page, the first completed checklist. ### Make it easy to move on A success state should not block the next action. Let the user dismiss it, or continue, with one click, and don’t bring it back for the same achievement. ## Rationale People remember the end of an experience, and a clear success makes the experience a positive one. A visible confirmation tells users that they did it right, which builds their belief that they can use the product (self-efficacy). It also links the first success to the next action, so value becomes a path to follow instead of an endpoint. Without a success state, users who just did something important can miss that they did. A message that appears and vanishes, or a change somewhere on the screen that they don’t see, leaves them unsure, which is the problem [Input Feedback](/patterns/InputFeedback) addresses for forms. ## Discussion ### Praise that overstates Praise that is out of proportion to the achievement is noticed and discounted. A celebration for marking a to-do in a tutorial is a demonstration, and users know it. The same celebration for a real first task, done on their own data, carries weight. ### Success is not the end A success screen that only congratulates leaves the user at a dead end. Attach the next step to it, and let the product continue from there. In Trello’s tour the message that the first to-do is complete is followed by “One last thing!”, which leads to the next step. ### Honest confirmation Only show a success state when the thing actually happened. A confirmation that appears before an email is sent or a payment is processed causes confusion when the result fails. When something can take time, say so, and show the result when it arrives. ### Success state and suggested action A [Suggested Action](/patterns/SuggestedAction) points the way forward from any moment. A success state is the moment right after an achievement, and it is where a suggested action works best. ### Measuring it Track click-through to the next step, and the second-session return of users who saw the success state compared with those who did not. --- # Streak Counter - Type: User interface design pattern - Category: Onboarding > Coming back - URL: https://ui-patterns.com/patterns/StreakCounter - Also known as: Streaks, Activity Streak, Habit Streak - Examples: 4 screenshots on the page ## Problem summary Repetition is invisible, so users cannot see the habit they are building and each return feels like a new decision. ## Usage - Use when the product’s value comes from a regular behavior, such as exercise, learning or writing. - Use when a missed day or week is meaningful but recoverable. - Do not use when the behavior is irregular by nature. - Do not use when losing a streak would create more anxiety than the habit is worth. ## Solution Show how many days or weeks in a row the user has done the key behavior, near the place where they do it, and make the next step to keep it obvious. ### Count in the unit that fits the behavior Daily streaks suit short habits like a language lesson. A weekly streak suits behavior that needs rest, such as running: Strava counts weeks, so a rest day does not break anything, and the count (“28 Weeks”) is still a number worth protecting. ### Show the pattern, not only the number A single number says little. Strava puts the count above a calendar where each active day carries a shoe icon, and a column of weeks on the side that ticks off finished weeks and ends in a flame for the current one. The user sees the habit, and sees the open week they can still fill. ### Make the next step obvious Put the streak next to the action that keeps it alive. If the user has to hunt for what counts, the streak becomes a source of worry instead of a reason to act. ### Offer a way to recover Let users protect a streak on a missed day, as Duolingo does with its Streak Freeze, or let them restart without losing their history. A streak that can only break creates fear. ### Celebrate modestly Mark milestones such as the fourth or the tenth week with a small acknowledgment. Save larger moments for the ones users will remember. See [Success State](/patterns/SuccessState). ## Rationale Repetition is hard to see from the inside. A streak makes it perceptible, and gives users a small, recurring reason to return: the next day or week they act, the number grows. The pull also comes from [Loss Aversion](https://learningloop.io/plays/psychology/loss-aversion): a streak is something the user has built, and losing it feels worse than gaining one more day feels good. This makes streaks effective, and it is also why they need care. ## Discussion ### Explore meaningful return behavior When a product already provides recurring value, use [Learning Loop's behavioral design tools guide](https://learningloop.io/guides/behavioral-design-tools/) to distinguish retention diagnosis from ideation and testing. The [free Persuasive Patterns reference](https://learningloop.io/playbook-collections/persuasive-patterns/) can inspire hypotheses, while the optional [Habits & Engagement deck](https://shop.learningloop.io/products/persuasive-patterns-habits-engagement) gives teams physical prompts for discussion. A streak is a poor fit where user needs are irregular or the count creates pressure. ### Habit or obligation Streaks that turn a habit into an obligation make users act out of fear of losing a number. Habit research suggests that an occasional miss does not undo a forming habit, so design for recovery rather than punishment. Avoid “you’re behind” language, and choose a unit that matches how often people can realistically act. ### Start from zero, with an action A streak needs a few repetitions before it means anything, so the first session should show the first step toward it, not an empty number. Strava’s home screen shows the streak at zero right after sign-up, with “Start your streak by logging an activity” and a “Record now” button beside it. The counter becomes an invitation instead of a score. ### Introduce it at the moment of success Duolingo introduces the streak right after the first lesson, when the user has just done the behavior. “Can you practice every day?” appears under a one-day streak, and accepting it is a single tap. It also gives four Streak Freezes up front, so the first missed day is covered before the user has had to think about it. ### Measuring it Track return frequency, and retention after a broken streak compared with an intact one. --- # Suggested Prompts - Type: User interface design pattern - Category: Onboarding > AI features - URL: https://ui-patterns.com/patterns/SuggestedPrompts - Also known as: Starter Prompts, Prompt Suggestions, Example Prompts - Examples: 7 screenshots on the page ## Problem summary An empty prompt box asks new users to know what the system can do and how to ask for it, before they have any experience with it. ## Usage - Use when the product accepts open-ended, natural-language input, such as an AI assistant, generator, or search. - Use when new users don’t yet know which requests produce good results. - Use when you want to show the range of what the product can do without a tour. - Do not use when the suggestions would be generic and unrelated to the user’s goal. ## Solution Show a few concrete, clickable example requests in the empty state, next to the prompt box. ### Write suggestions as good requests Each suggestion should be a complete request the user could have written, and one that produces a good result: “Summarize this document”, “Draft a reply to the last email”, “Build a contact form”. Users learn how to ask by seeing well-formed requests. Canva AI shows three suggested tasks above an empty prompt field, and one of them, “Bring your context into the chat”, shows the apps that can be connected, so a suggestion also teaches what the system can reach. ### Base them on real jobs and context Pick suggestions from the most common jobs users come to do, or from the user’s current context: the document they have open, the data they have connected, the role they gave during signup. ### Let users edit before sending Clicking a suggestion can fill the prompt box instead of sending immediately, so users can adapt it to their situation and learn that the request is theirs to change. ### Keep them fresh Rotate or refresh suggestions, and update them as the user’s work changes. A small “refresh” control lets curious users see more without crowding the screen. ## Rationale An empty prompt box is a recall task: the user has to come up with a request from nothing. Suggested prompts turn it into recognition, which is far easier, as [Recognition over Recall](/patterns/Recognition-over-recall) describes. It is the AI version of an [Input Prompt](/patterns/InputPrompt), which hints at what to type in a field. They also teach, by example, what a well-formed request looks like and what the system is good at. ## Discussion ### Showing off versus helping Suggestions are tempting places to show off impressive capabilities. Users get more from suggestions that match what they came to do, even if those are less spectacular. ### From suggestions to skill Suggested prompts are a starting point. Pair them with feedback on results and [Refinement Controls](/patterns/RefinementControls), so users learn to steer the system and stop depending on the suggestions. Show where answers come from with [Source Citations](/patterns/SourceCitations) so users learn when to trust them. ### Measuring it Track how many first-time users start from a suggestion, and the quality and reuse of their first results compared with users who typed their own first request. ## Sources - Amershi, S. et al. (2019). [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/). Proceedings of CHI 2019. --- # Refinement Controls - Type: User interface design pattern - Category: Onboarding > AI features - URL: https://ui-patterns.com/patterns/RefinementControls - Also known as: Regenerate, Variations, Response Refinement, Steering Controls - Examples: 1 screenshots on the page ## Problem summary Users stop at the first AI output because they don’t know they can improve it, or how. ## Usage - Use when AI output is a starting point that usually benefits from adjustment. - Use when users are new to AI features and don’t yet know what they can ask for. - Do not use when the output is deterministic and has a single correct answer. ## Solution Place a small set of refinement actions next to every result, so the next step is one click away. ### Offer the common adjustments as buttons Offer regenerate, show variations, and the adjustments people ask for most, such as “Shorter”, “Elaborate”, or “More formal”. Buttons are easier than writing a new prompt, especially for users who don’t yet know what the system can do. ### Keep a free-form option Next to the buttons, keep a text field for requests the buttons don’t cover (“Format this by…”). The buttons teach what is possible, and the field handles the rest. ### Let users edit directly and keep earlier versions Users should be able to edit the output by hand, and to go back to a version they preferred. ### Point them out after the first result During onboarding, draw attention to the controls once the first result is on screen, so steering is learned as part of the first success. ## Rationale Refinement controls teach users that working with AI is iterative. A disappointing first result becomes a next step instead of a reason to leave, and users build the skill of reproducing success. Buttons for common adjustments also lower the effort of the second request, which is where many users give up. They are the refinement counterpart of [Suggested Prompts](/patterns/SuggestedPrompts): suggestions help with the first request, controls with the next. ## Discussion ### Too many controls So many controls that users can’t tell which matters. Start with three to five adjustments, and let usage data decide which stay. ### Refining or starting over Make it clear whether a refinement changes the current result or creates a new one, and keep the original available, or offer [Undo](/patterns/undo). Users who fear losing a good draft will not experiment. ### Measuring it Track refinement actions per result, and whether users who refine return more often than users who don’t. ## Sources - Amershi, S. et al. (2019). [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/). Proceedings of CHI 2019. --- # Source Citations - Type: User interface design pattern - Category: Onboarding > AI features - URL: https://ui-patterns.com/patterns/SourceCitations - Also known as: Citations, Confidence Indicators, Inferred Labels, Source Attribution - Examples: 2 screenshots on the page ## Problem summary The user can’t tell which parts of an AI answer to rely on and which to check, so they either trust everything or trust nothing. ## Usage - Use when AI output draws on documents, data, or the web. - Use when mistakes in the output would have consequences for the user. - Use when you want new users to learn when the system is reliable and when to verify. - Do not use when the output is creative and has no factual claims to verify. ## Solution Show where each part of an answer comes from, and how certain the system is. ### Link claims to sources inline Attach a small citation marker to each claim, linked to the source it came from. Show the sources in a list as well, with titles and domains the user can recognize. A citation placed at the end of a whole answer says much less than one attached to the sentence it supports. ### Distinguish read from inferred Mark content the system concluded rather than read directly: “inferred from 3 tickets”, “based on last week’s data”. Users need to know when a statement is a summary of sources and when it is the system’s own reasoning. ### Express uncertainty in plain language Where it helps, say how sure the system is (“Confidence: medium. One source is a year old.”). Plain words work better than percentages most users can’t interpret. ### Teach the signals early During onboarding, point out these signals and what they mean, so users learn when to check a source and when the answer can be used as it is. ## Rationale Citations calibrate trust. Users learn where the system is reliable and where their own judgment is needed. Accurate trust lasts longer than maximal trust: users who were told the system is always right stop trusting it entirely after the first visible mistake, a case of [Negativity Bias](/patterns/Negativity-bias). Showing where an answer comes from lets users decide for themselves, and makes the first mistake a reason to check a source, not to leave. ## Discussion ### Citations that don’t support the claim A citation that doesn’t actually support the claim it is attached to creates false confidence, which is worse than no citation. Check that sources support the sentences they are attached to, and prefer fewer, accurate citations to many loose ones. ### Clutter Answers with a marker after every word are hard to read. Group citations by sentence or paragraph, and keep the source list compact. ### Citations and suggested prompts Citations work best when users also know what to ask. [Suggested Prompts](/patterns/SuggestedPrompts) steer people toward questions the system can answer from sources, and [Refinement Controls](/patterns/RefinementControls) let them narrow an answer after reading it. ### Measuring it Track how often users open sources, and the error rate of decisions made with AI output. A sudden drop in source opening can mean over-trust as easily as satisfaction. ## Sources - Amershi, S. et al. (2019). [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/). Proceedings of CHI 2019. --- # Feature Gate - Type: User interface design pattern - Category: Onboarding > Upgrades and exits - URL: https://ui-patterns.com/patterns/FeatureGate - Also known as: Locked Feature, Upgrade Prompt, Premium Preview - Examples: 4 screenshots on the page ## Problem summary Paid features are either hidden, so users never learn they exist, or locked without explanation, which frustrates users who try them. ## Usage - Use when a paid feature would clearly help with the user’s current task. - Use when the product has a free tier and the paid features are discoverable in the interface. - Do not use when the gate would interrupt the user’s first experience of value. - Do not use when the free product would feel incomplete without the gated feature. ## Solution Show the feature where it would be used, marked with a small label, and explain it when the user tries it. ### Mark locked features in place Keep the feature visible, with a small, consistent mark such as a crown, a “Pro” label, or a lock. Users learn what the paid plan includes by seeing it in context, not by reading a pricing page. ### Preview what the feature would do When the user tries a gated feature, show what it would do with their own work, or with a convincing sample: a preview, a sample result, or a short trial. A dialog that lists benefits next to a picture of the feature in use is stronger than a list alone. Amplitude’s locked Heatmaps page shows what a heatmap looks like, explains what it tracks, and names the plans that unlock it. Canva previews its Brand Kit in the upgrade dialog and offers a free trial. ### Say which plan includes it and what it costs Name the plan that unlocks the feature, the price after any trial, and when the trial ends. If the user chooses a trial, promise a reminder before it ends. ### Offer a way to continue without it Make closing the dialog easy, and let the user continue with what the free plan offers. The user should return to the task they were on. ## Rationale A gate in context shows the value of a paid feature at the moment the user wants it, which is more persuasive than asking them to imagine it from a pricing page. It connects the upgrade to the user’s current goal, so the offer feels like help with the task rather than a sales pitch. ## Discussion ### Gates everywhere Gates scattered across the interface until the free product feels like an advertisement. Keep the core free experience complete, and gate only the features that add clear value for the users who need them. ### Feature Gate and Paywall A [Paywall](/patterns/Paywall) stops the user at a fixed point until they pay or register. A *Feature Gate* leaves the rest of the product open and only asks at the moment the user reaches for a specific paid feature. The gate is lighter, and works well in freemium products. ### Trials make gates stronger A gate that offers a short trial lets the user feel the feature before paying, and people value what they have started to use, the [Endowment Effect](/patterns/Endowment-effect). Pair the trial with a [Trial Countdown](/patterns/TrialCountdown) and a [Pricing Table](/patterns/PricingTable) that shows which plan unlocks what. ### Measuring it Track the upgrade rate from each gate, and complaints or drop-off after gate encounters. --- # Paywall - Type: User interface design pattern - Category: Onboarding > Upgrades and exits - URL: https://ui-patterns.com/patterns/Paywall - Also known as: Permission Wall, Sign-Up Wall - Examples: 30 screenshots on the page ## Problem summary The user needs to pay to get access to a restricted area on a website. ## Usage - Use when you need a way of directly making money on the content you produce - Use when your users are willing to pay for the content you produce - Use when the perceived value of your content is greater than the amount of money you are requesting for it - Do not use when your website is solely dependent on making money on banner impressions, as the highest possible number of pageviews is then the most important. ## Solution Restrict access to users who have paid. There are a variety of Paywall strategies found in use today. vary. Some strategies close block all content until payment is made, some lure you in with bait and asks for money after viewing an amount of articles, other websites cherry pick content that’s not free for all. Below is an overview of the main variations. ### Strategies - **Paywall:** All content is behind one big paywall that surrounds the entire site. Examples are [The Times](http://thetimes.co.uk) - **Freemium:** In the freemium model, some content is free for all and some are behind a pay wall. Examples are [The Wallstreet Journal](http://wsj.com), [Berlingske](http://b.dk), [Aftonbladet](http://aftonbladet.se) - **Taxometer:** The first few articles are free to view whereafter the paywall kicks in. Examples are [The New York Times](http://nytimes.com), [Financial Times](http://ft.com) - **Time limits:** You buy a day, week, month or year pass or access to the archive for a number of days. Examples are [The Observer](http://observer.guardian.co.uk), [The Guardian](http://www.guardian.co.uk/) - **Bulk sales:** Upsale and sale to companies. Examples are [Financial Times](http://ft.com) and [Mediawatch](http://mediawatch.dk/) - **Sale by the piece:** Purchase of single stories and services. Examples are [Tænk](http://taenk.dk), [PeepCode](https://peepcode.com) ### Payment doesn’t have to be monetary Most paywalls include a monetary exchange, however there are several ways a user can pay to get behind a paywall: - **Monetary exchange:** The traditional paywall includes some kind of monetary exchange – it can payment for a single piece of information or by subscription - **Subscription to print media:** Instead of buying a subscription to use the website only, require users to own a subscription of the print edition of the media in order to enforce both revenue streams: online and offline. - **Permission:** Let your users give you permission to call them up, send them emails, to get your information from facebook, to contact your friends, etc.. Getting permission to build a long term relationship can sometimes be more worth than a simple monetary exchange. - **Lead:** You could also let users give their permission for an advertiser or other third party to contact them. - **Time:** Let your users take a questionnaire – do you want to know about the profile of your users and their behavior – or could an advertiser or other third party be interested in knowing about your users? You could also let your users watch a video commercial from an advertiser or otherwise grow from their valuable time. - **Social sharing:** Let users gain admission to content by first socially sharing a link. Some websites and applications use “pay with tweet” and “pay with like” services. ## Rationale Paywalls are used as an alternative income source for online media websites, where banner advertising has been the tradition. As users move their habits from print to online, media companies find it harder to base their business on advertising revenue only. Paywalls has been widely introduced to make up for the lost revenue. --- # Usage Meter - Type: User interface design pattern - Category: Onboarding > Upgrades and exits - URL: https://ui-patterns.com/patterns/UsageMeter - Also known as: Usage Limit Indicator, Quota Meter, Plan Usage - Examples: 3 screenshots on the page ## Problem summary Users hit a plan limit without warning, at a moment when they are in the middle of their work. ## Usage - Use when the plan limits seats, projects, storage, credits, or actions. - Use when users can reach the limit through normal use. - Do not use when the limit is so high that few users ever approach it. ## Solution Show current usage against the limit in a calm, persistent place, and warn in plain language before the limit is reached. ### Show used and total Show the amount used next to the limit and fill a small bar to match: “0 MB / 10 GB”. A number with its limit tells the user how much room is left. A bar alone does not. Airtable’s workspace summary lists records per base, attachment storage, and API calls this way, each with its own bar. ### Put it where users look for it Settings or a sidebar are the usual homes: a place that is easy to find and does not interrupt work. Link the meter to the plan page, so the way to more room is one click away. Dropbox places its storage meter on the same page as the plan, with the price of more space beside it, and splits the bar by kind of content so users can see what fills their space. ### Warn before the limit Tell users when they approach the limit, at around 80 percent, for example. Claude’s weekly bar turns amber as it fills, and a banner above the input says “Approaching weekly usage limit” with the reset date, which is calm, factual, and arrives while there is still room. Say what is about to happen, and give the options: upgrade, free up space, or wait for the reset. A warning that arrives while there is still room gives the user time to choose. ### Be kind at the limit When the limit is reached, let the user finish what they were doing where possible. Block the next action, not the whole product, and show what they can do now. ### Say what counts Name each limit by what it counts, and give reset times for limits that renew: “Public API calls per month”. Claude shows two limits side by side, a session limit that resets in a few hours and a weekly limit that resets on a set day and time, each with its percentage used. A limit users can’t predict is one they can’t manage. ## Rationale Predictable limits give users real control over the decision. A user who can see how close they are to a limit can decide when to upgrade, rather than being forced to by a sudden block. This turns an interruption into a planned choice, and an upgrade that follows is more likely to feel like the user’s own decision. A meter also makes the plan concrete. “50,000 records” means little. A bar that is 80 percent full shows what the limit looks like in the user’s own use, which is the kind of loss that people take seriously ([Loss Aversion](/patterns/Loss-aversion)). ## Discussion ### Meters that pressure Alarming colors, flashing indicators, and countdowns that are designed to rush users into upgrading cross the line from information to pressure. A meter should state a fact. Use calm colors, and reserve red for limits that have been reached. ### Meter, paywall, and gate A meter warns about a limit that is coming. A [Paywall](/patterns/Paywall) is the wall itself, and a [Feature Gate](/patterns/FeatureGate) marks a feature that a plan does not include. The three work together: the meter makes the wall predictable, and the gate shows what is on the other side. ### Free plan limits at the start At the beginning, a meter at zero shows the limits before they matter. That helps users who are choosing a plan, and can look like a warning to the ones who are not. Show it in settings first, and move it to a more visible place when usage grows. ### Measuring it Compare the number of upgrades after a warning with upgrades after a hard stop, and track churn after limit events. --- # Trial Countdown - Type: User interface design pattern - Category: Onboarding > Upgrades and exits - URL: https://ui-patterns.com/patterns/TrialCountdown - Also known as: Trial Banner, Trial Status, Days Left - Examples: 10 screenshots on the page ## Problem summary Users lose track of when their trial ends, and the end comes as a surprise, either an unexpected charge or a sudden loss of access. ## Usage - Use when the product offers a time-limited trial. - Use when a charge or a loss of access follows the end of the trial. - Use when you want users to decide on evidence of what they have done in the product. - Do not use when there is no trial or deadline. ## Solution Keep the trial’s status and end date visible in a small, persistent element, with a clear way forward. ### Keep it small and always there Show the days remaining in a compact element that is visible on every screen, such as a line at the top and a block in the navigation. It should state a fact (“Trial ends in 3 days”), not exert pressure. ### Link to what happens next Link the element to a page that explains what happens at the end and what the user can do: choose a plan, continue on a free plan, cancel, or export their work. Put “Choose plan” and “Cancel trial” side by side on that page, with equal prominence. ### Warn before anything is charged Send a reminder a few days before the trial ends, especially before any charge, and say what the charge will be. ### Show progress toward value Combine the countdown with what the user has done so far, so they can judge whether to continue on evidence and not on a feeling of deadline. ## Rationale Transparency about time gives the user control over the decision, and an end date makes the user aware of what they could lose, which is why a countdown has to be honest. See [Loss Aversion](/patterns/Loss-aversion). A user who knows when the trial ends can use the remaining days well, and a reminder before charging builds trust that outlasts the trial. ## Discussion ### Information, not urgency A countdown informs, while fake urgency pressures and abuses [Scarcity](/patterns/Scarcity). Invented deadlines, countdowns that reset, and “last chance” offers fail the ethics test, and in many jurisdictions consumer-protection rules. The deadline should be the real one. ### Trial length A short trial puts the countdown in front of the user at the very start. Shopify’s trial is three days, so the element shows up on the first screen. Short trials need a path to value that fits in the time, or a way to extend or continue at a low price. ### Charging without notice Charging at the end of a trial without a clear warning is a reliable way to produce complaints and chargebacks. Say what will be charged, when, and how to stop it. Canva shows the whole timeline before the trial starts: “Today: get free access”, “9 Nov: we’ll remind you your trial is about to end”, “16 Nov: we’ll automatically renew your plan, unless you cancel beforehand”, with “Due today 0 kr” next to it. ### Countdown, paywall, and cancellation The countdown leads to a decision, and that decision is usually a [Paywall](/patterns/Paywall) or a [Pricing Table](/patterns/PricingTable). Make sure the way out is as clear as the way forward: link to the [Cancellation Flow](/patterns/CancellationFlow) from the same page. ### Measuring it Track trial-to-paid conversion, refund and chargeback rates, and complaints at trial end. --- # Cancellation Flow - Type: User interface design pattern - Category: Onboarding > Upgrades and exits - URL: https://ui-patterns.com/patterns/CancellationFlow - Also known as: Cancel Flow, Offboarding, Exit Flow - Examples: 7 screenshots on the page ## Problem summary Users who want to leave face either a generic retention offer or deliberate obstacles, and neither addresses why they are leaving. ## Usage - Use when users can end a subscription or close an account. - Use when you want to learn why people leave, and to offer something that fits. - Do not skip it when there is nothing to retain. Every product with subscriptions or accounts needs a clear way out. ## Solution Make leaving easy to find and complete in a few steps, and respond to the user’s situation without blocking the exit. ### Make it easy to find Put the option where users look for it, in account or billing settings, and name it plainly. Some jurisdictions require cancelling to be about as easy as signing up. ### Offer something that fits, once Ask one optional question about the reason. Respond with something that fits the answer: a pause for low usage, a cheaper plan for price, a route to support for a technical problem, and a clean exit for everyone else. Present the offer as an option beside the exit, never in front of it. ### Say what happens to the data Explain what will be deleted and whether it can be recovered, and let users export their data before they go. ### Confirm and close the loop Ask for a deliberate confirmation (such as the account password), then show a clear confirmation of what happened. Invite feedback after the exit instead of before it, and make it optional. ## Rationale Responding to the actual reason for leaving helps the users who would stay for the right offer, and respects the ones who wouldn’t. A clean exit builds trust and leaves the door open to return. It is the counterpart of a [Trial Countdown](/patterns/TrialCountdown) at the start: both are about being honest about time and money. ## Discussion ### Obstacles and guilt Hidden cancel links, repeated confirmation screens, guilt-inducing copy, and offers that block the exit damage trust and can break the law. They also play on [Loss Aversion](/patterns/Loss-aversion), the tendency to weigh what we might lose more heavily than what we might gain, and users notice when it is used against them. A good flow lets the user leave in as few steps as they would take to join. ### Account closing versus cancelling a plan Closing an account is more final than cancelling a paid plan. The first deserves a stronger confirmation and a data export. The second can often be softened with a pause or a downgrade. ### What the example does Mailchimp’s flow starts with “Before you go…”, offers a conversation with a specialist, and offers to export the account data. It then asks for the password, closes the account, and invites optional feedback. It does not ask why the user is leaving before it offers help, so the offer can’t be tailored to the reason. ### The reason question Shopify’s flow asks the main reason for closing, with a list that covers the real ones (“struggling to get set up”, “too expensive”, “not making enough sales”). That is the information needed to answer with something that fits. Here the question is required, which turns it into a gate. Making it optional keeps the exit as easy as the pattern asks for. ### Alternatives next to the exit Netflix’s “Manage your membership” page puts “Change plan”, “Pause for up to 3 months”, and “Cancel” side by side, each with a one-line description. It states the date the change takes effect and that the user can keep watching until then, and shows what to watch before leaving. The alternatives are offered without hiding the exit. Describing the cost of leaving as it really is, here losing personalized recommendations, is [framing](/patterns/framing) that informs. Inventing losses to scare users is not. ### A grace period Deleting an account is permanent, so a waiting period protects users from their own mistakes. Atlassian’s confirmation after closing a Trello account names the exact date after which deletion is final and puts “Cancel deletion” at the top, as the main button. The clock is a fact about the data, and not a pressure to stay. ### The way back Shopify closes with a statement of how long data is kept and a one-step link to re-open the store. A clean exit that makes returning easy keeps the door open. ### Measuring it Track the save rate by stated reason, the return rate of former customers, and complaints about cancelling. --- # Navigation Tabs - Type: User interface design pattern - Category: Navigation > Tabs - URL: https://ui-patterns.com/patterns/NavigationTabs - Examples: 19 screenshots on the page ## Problem summary Content needs to be separated into sections and accessed using a flat navigation structure that gives a clear indication of current location. ## Usage - Use when there are between 2 – 9 sections of content that need a flat navigation mode. - Use when section names are relatively short - Use when you want the navigation to fill the entire width of a page - Use when you want to provide a list of the highest available sections/subsections of the website - Do not use when wanting to show content-specific data. For instance for showing latest articles - Do not use when there is no need to single-out the currently selected option - Do not use when the list of sections or categories call for a “more…” link. Then consider another navigation pattern. ## Solution - A horizontal bar contains the different sections or categories of your website. - Each section or category is represented by a tab that most commonly resembles a button. This is why the whole button should be clickable, and not just the text that labels the section. - Optionally, a bar below the top bar can contain subsections of the currently selected item in the top bar - The navigation tab is persistent across all pages that the tabs link to. - The same structure (order) of the navigation tabs should be maintained from page to page, so that the user can relate the navigation of the different pages to each other. - The selected tab should be highlighted to indicate current location. - If subsections are used (a second horizontal bar below the top bar) there should be a clear visual connection between the currently selected top tab and the bar below showing subsections. ## Rationale The Navigation tabs pattern is an extension of the desktop metaphor in which physical objects are represented as GUI elements. Navigation tabs are derived from the idea of folders in a file-cabinet and are thus familiar to the end user Navigation tabs provide a clear visual indication of what content can be found on a website and places the current location in context by highlighting it. --- # Module Tabs - Type: User interface design pattern - Category: Navigation > Tabs - URL: https://ui-patterns.com/patterns/ModuleTabs - Examples: 10 screenshots on the page ## Problem summary Content needs to be separated into sections and accessed via a single content area using a flat navigation structure that does not refresh the page when selected. ## Usage - Use when there is limited visual space and content needs to be separated into sections - Use when there are between 2 – 9 sections of content that need a flat navigation mode. - Use when you need to keep user attention by circumventing page refreshing. - Use when section names are relatively short - Use when the content of each tab can be viewed separate from each other, and not in context of each other. - Use when the content for each tab has similar structure - Use when you need to show what tab is currently being viewed - Do not use when the content inside each pane would function just as well in its own separate page. ## Solution - Present the content of one tab inside a box (content area) - Place a horizontal bar on top of the content area with links representing tabs - Refrain from having more than one line of links in the top horizontal tab bar - Use color coding or other visual support to indicate what tab is currently being viewed - Present the content of each tab in the same content area - Only one content area should be visible at a time - Maintain the same structure of the top horizontal tab bar after a new tab has been clicked - Only the content area of the tabs and the horizontal tab bar should be changed when a user clicks a new tab - If possible, the page is not refreshed when a tab is clicked. - A new page is not loaded when a tab is clicked ## Rationale The Navigation tabs pattern is an extension of the desktop metaphor in which physical objects are represented as GUI elements. Navigation tabs are derived from the idea of folders in a file-cabinet and are thus familiar to the end user Module Tabs provide an easy way to show large amounts of similar structured data parted by categories Tabs create a context for content, when a tab is selected the relevant content is loaded inside the content area. --- # Breadcrumbs - Type: User interface design pattern - Category: Navigation > Jumping in hierarchy - URL: https://ui-patterns.com/patterns/Breadcrumbs - Examples: 25 screenshots on the page ## Problem summary The user needs to know their location in the website's hierarchical structure in order to possibly browse back to a higher level in the hierarchy. ## Usage - Use when the structure of the website follows a strict hierarchical structure of similar formatted content. - Use when the structure of the site is partitioned in to sections which can be divided into more subsections and so on. - Use when the user is most likely to have landed on the page from an external source (another site deep linking to the web page in question). For instance from a blog or a search engine. - Use when the page in question is placed fairly deep into the hierarchy of pages and when no other form of visual navigation can show the details of the same deep level. - Use together with some sort of main navigation. - Do not use on the topmost level of the hierarchy (typically the welcome page) - Do not use alone as the main navigation of the website. ## Solution Reveal the user’s hierarchical location and provide links to higher levels. - Show the labels of the sections in the hierarchical path that lead to the current page being viewed. - Each label is a link to a section. - The label of the current page is at the end of the breadcrumb and is not linked. - Each label is separated with a special character. Popular characters are » (`»`) or \>. - The separating characters and the spaces between the links and the labels are not linked. - The labels of each section preferably match the titles of that section. ## Rationale Breadcrumbs serve as an effective visual aid, indicating the location of the user within the website’s hierarchy, making them a great source of contextual information for landing pages. Also, breadcrumbs allow for easy navigation to higher-level pages. - Breadcrumbs inform users of their location in relation to the entire sites hierarchy. - The structure of the website is more easily understood when it is laid out in a breadcrumb than if it is put into a menu. - Breadcrumbs take up minimal space and even though not all users use them, they still hint the structure of the website and the current location of the page in question. - The term ‘breadcrumb’ is deceptive, as it implies the history of how the user got to that page. A more correct term would describe the current location’s place in the hierarchy of the website. --- # Fat Footer - Type: User interface design pattern - Category: Navigation > Jumping in hierarchy - URL: https://ui-patterns.com/patterns/FatFooter - Also known as: Sitemap Footers - Examples: 83 screenshots on the page ## Problem summary Users need a mechanism that will enable them to quickly access specific sections of a site or application bypassing the navigational structure. ## Usage - Use to shortcut an otherwise hierarchical structure of a website. - Use when there are specific pages or functions that are more frequently used than others parts of the website. Use the shortcut box to show these choices in order to shorten the path for the users. - Use when you want shortcuts to pages that are possibly on different hierarchical levels of the page. - Can also be used as navigation when short on space, although it is not advised. ## Solution End a page by providing relevant links to other sections of your site. Add the same footer on all pages of a website – with the same layout in the footer on all pages. Typically, these things are included in fat footer designs: - **About us link:** Link to your “about us” section, which then includes basic information about your company. - **Terms of service:** If you provide a service or a product, placing a link to it in the footer is a standard location, why users anticipate it being there. - **Privacy policy:** As with the terms of service, users expect to always be able to find privacy policies in the footer of a website. - **Site map:** Provide quick links the most important pages of your website. - **Contact us link:** Make sure your users have a way to get in hold of you. If you have a “Contact us” page, users expect to find a link to it in the footer. This is also a critical point in building the trustworthiness of your site as it is displaying your physical address. - **Address and phone number**: Show that you are real. If you have a physical business, offer phone support, or have a reason for people to mail you things, putting that information in the footer is an anticipated and appropriate location. - **Social links:** Link to any social presences you might have on Facebook, Twitter, Pinterest, Instagram, and the likes. ## Rationale Keep visitors on your site for longer: end one experience by starting a new one. Provide easy and natural ways for users to continue their journey. By adding a shortcut to the most frequently used pages and functions, the path can be shortened and confusion can be decreased. The hierarchical structure of a website can at times impede the path to specific page or function of a website. By adding a shortcut to the most frequently used pages and functions, the path can be shortened: the number of clicks can be lessened and the confusion decreased. ## Discussion A fat footer isn’t right for every site or for every company. Consider asking these when creating a footer: - What does my user expect to see here? - What is the next logical step in the user journey? - What questions are my secondary or tertiary users still asking at the bottom of the site? - How can I continue the experience beyond the content on this page?1 ## Sources1 Fat footer round-up at UX Booth.
--- # Modal - Type: User interface design pattern - Category: Navigation > Jumping in hierarchy - URL: https://ui-patterns.com/patterns/modal-windows - Also known as: Modal Window - Examples: 75 screenshots on the page ## Problem summary The user needs to take an action or cancel the overlay until he can continue interacting with the original page ## Usage - Use when you want to interrupt a user’s current task to catch the user’s full attention to something more important. - Do not use to show error, success, or warning messages ## Solution Introduce a mode in which users cannot interact with your application until the mode is closed. Interrupt the user’s attention and halt all other actions until a message is dealt with or dismissed. ### Matching titles Matching button text with the title of the modal increases the feeling of familiarity. As modals introduce a new inturrupting mode, chances are that users won’t connect the action they just performed with the modal popping up. Make sure they know where the modal is coming from. ### Allow escape Allow users to escape the mode by letting them close the modal window when they need to. Popular conventions for close buttons is an ‘X’ icon in the top right corner and/or a ‘Close’ or ‘Cancel’ button at the bottom of the modal window. The ESC key is also often a conventional keyboard shortcut to closing modals – so is clicking outside the modal window. ## Rationale Although effective in focusing attention, introducing multiple modes comes with the risk of introducing mode errors where the user forgets the state of the interface and tries to perform actions appropriate to a different mode. ## Discussion Modals have been considered a UI anti-pattern. The main reason lies in the definition of a modal window: A window that prevents the user from interacting with your application until she closes the window1. Modal windows interrupt users and force them into doing a specific action. Arguably, in most cases, there is no need to force users into specific actions. As a result, modal windows introduce unnecessary pain points for your users. The alternative is modeless interfaces. Interfaces that allow users to change their mind at any point. Interfaces that do not force users into a specific set of actions. Also, modals do not work well on mobile devices as they take up screen space and introduce additional user interface elements. ## Sources1 Modal WIndow at Wikipedia.org
2 Design patterns for replacing modal windows by L. Mathis
--- # Notifications - Type: User interface design pattern - Category: Navigation > Jumping in hierarchy - URL: https://ui-patterns.com/patterns/notifications - Examples: 4 screenshots on the page ## Problem summary The user wants to be informed about important updates and messages ## Usage - Use when you want to draw attention to important updates or messages. - Do notify users about about time-sensitive information directed specifically at them. - Do not notify users about information that is currently on screen (e.g. active chat conversations) - Do not notify users about technical operations that do not require user involvement (such as syncing) - Do not notify users about error messages that can be resolved without user action ## Solution Inform your users about relevant and timely events. Notify users about important updates while they are focused elsewhere. Adjust the rate and relevancy of notifications aptly, as they can be interruptive. Empower users to disable or change notifications in their settings. Create personalized, summarized, and timely notifications that may serve as entry points to more detailed information. Use notifications to draw attention to important updates: messages from friends, new friend requests, relevant nearby offers, and many more. ### Across devices Once a users has consumed a notification, he or she should not see it again. Similarly, users should be able to retrieve already consumed notifications on another device more suitable for consuming the content the user was notified about. Notifications should be synced to all of a user’s devices. ### Minimize interruption Notifications are obtrusive and interruptive in its nature. It is used to direct the user’s attention to important events while being focused elsewhere. Make careful considerations as to when to interrupt users. Do not notify users about information already on screen (e.g. active chat conversations), technical operations not requiring user involvement, and error states that can be resolved without user action. ### Allow escape Make notifications dismissible and let users disable or change the rate of notifications in your products [settings](http://ui-patterns.com/patterns/settings). ### Provide summaries Combine multiple notifications of the same type into a single summary notification showing how many notifications of a particular kind are pending. Consider expanding the notification, providing detailed information of the summarized notifications, once clicked. ### Provide actions Bundle action buttons with notifications, for users to quickly handle the most common tasks for a particular notification, without opening the originating screen. Let actions be clear and unambiguous and only provide them if they do not duplicate the default action. Actions should be meaningful and time-sensitive, suit the content, and allow the user to accomplish a task. ## Sources1 Notifications Design Pattern at the Google Material Design Spec
--- # Shortcut Dropdown - Type: User interface design pattern - Category: Navigation > Jumping in hierarchy - URL: https://ui-patterns.com/patterns/ShortcutDropdown - Examples: 1 screenshots on the page ## Problem summary The user needs to access a specific section or functionality of a website in a quick way regardless of hierarchy. ## Usage - Use to shortcut an otherwise hierarchical structure of a website. - Use when there are specific functionality or pages that are more frequently used than other parts of the website. Use the shortcut box to show these choices in order to shorten the path for the users. - Use when you want shortcuts to pages that are possibly on different hierarchical levels of the page. - Can also be used as navigation when short on space, although it is not advised. ## Solution - Add a combobox (a `