Graphic Designers
.svg)
Motion Designers
3d Designers
For use in websites and apps
For use as tags and highlight
For use in websites and apps
For use in printing only
We stick to the Ledger voice, applying it directly to product design. Our focus is on the conversation we have with users, conveying meaning with as few words as possible while still adding some brand flair.
(1) Have intricate details about the users you’re writing for:
We want to understand who is exposed to the interaction and messaging. What’s important to them? What are they thinking? What are they feeling?
(2) Have a goal in mind:
Know what the business objective and what the user goal is. The aim is to harmonise the two. This leads to writing purposeful copy.
(3) Write for mobile:
We have a mobile-first approach, which is then emulated for desktop.
(4) Keep it clear and crisp:
Ask yourself: What am I trying to accomplish with my writing? Once you’ve answered that, you can start addressing the writing itself.
- Break up your paragraphs into individual sentences.
- Make each sentence as short and clear as possible.
- Start each sentence the same way — like with a verb.
- Keep other options in mind too. Sometimes it might be better to get your point across with a video or animation.
- You can start with a short answer first and expand on it elsewhere.
- Look at in-flow content on a screen in context of the entire interaction—what the user wants to do, what the user may be feeling, what they did just before they got to this moment in the UI, and what they’ll do next.
- Anticipate potential issues and user challenges. Address them using in-flow messaging, tips, and other explanatory text.
- Reserve FAQs or self-help articles for situations where the user needs more information.
- Use links that take the user away from the UI sparingly. If the user needs more info to complete a task, use other UI components like a bottom drawer that keep the user in the flow.
- Depending on the feature or product, work with certain user assumptions, like their level of crypto expertise. Base the assumption on data points.
(5) Keep users focussed:
Give users what they need, when they need it. The content and the UI should not be fighting for the user’s attention.
(6) Lead with the user’s goal or user benefit:
Always be mindful of what the user wants to accomplish and lead with that goal. Use a “To achieve this, do this action” format.
(7) Pay attention to the order of information on a screen:
Put the most important information first. Format your text to make it easy to read. If you’re trying to convey more than one idea, consider breaking up the text onto multiple screens.
(8) Be action-oriented:
Active voice and clear labels help people navigate better. When labeling buttons and links, it’s almost always best to use a verb. Prioritize clarity. For links, avoid using “Click here” in favor of more descriptive words or phrases, such as “Learn more about UX Writing.” This is especially important for people using screen readers to access your app.
(9) Provide clear next steps for empty states:
An empty state is a good opportunity to make people feel welcome and educate them about the app. Guide people on actions they can take, and give them a button or link to do so.
(10) Write clear error messages. Display the error message as close to the problem as possible, avoid blame, and be clear about what someone can do to fix it. For example, “That password is too short” isn’t as helpful as “Choose a password with at least 8 characters.” Interjections like “oops!” or “uh-oh” are belittling and not aligned with Ledger’s voice. If you find that language alone can’t address an error that’s likely to affect many people, rethink the interaction.
(11) Choose the right delivery method: When there’s something you want to communicate, consider the urgency and importance of the message. Choose the correct delivery method whether that be by email, push notification, in-app notification, in-app messaging, or a combination.
(12) Keep “settings” labels clear and simple. Help people easily find the settings they need by labeling them as practically as possible. If the setting label isn’t enough, add an explanation. Describe what it does when turned on, and people can infer the opposite.
Goal: Establishing an easy, recognizable starting place to write consistently high-quality text.
Purpose: Provide immediate clarity of context and action to be taken.
Titles are more often than not the first and only thing that the user reads, which means the title needs to offer immediate context.
Purpose: Help users move forward in the experience knowing what to expect, establish the brand, and reduce liability.
Try to avoid using description texts if possible. Users tend to ignore it. If the description text is necessary, it has to be as easy as possible to read.
(1) People usually rapidly scan lines up to about 50 characters wide (3 to 6 words).
(2) People’s eyes will linger on a few of those words when the paragraph has 3 lines or fewer.
(3) If the text is longer, it must be separated into scannable chunks.
(4) Avoid asterisks. Using asterisks indicates that the main text isn’t fully honest, and can’t be trusted. If there’s some sort of disclaimer/limitation that needs to be made known to the user, include that in a description.
Purpose: Allow the person to advance towards or commit to an action.
Buttons are how people make their purpose known. It’s a person ‘speaks’ to the experience. The button must therefore be used to enable that conversation. Almost every other piece of text (titles, descriptions, empty states, labels, confirmation, error, etc.) is the experience speaking to the person.
Buttons should be:
(1) Recognizable,
(2) Specific
(3) Brief (one or two words long). Three is OK. On rare occasions, you can use 4 words to flex, like if you have one headline and multiple CTAs on a screen and need to add clarity.
(4) Conversational
(5) Verb-first (contextually). Nouns as buttons let the person choose where to go in most cases.
(6) When paired with action-based titles, buttons are more effective when they match the words in the title. Eg. Title: Create your Ledger account, CTA: ‘Create my account’.
(7) “What do I get” rather than “How do I get it”. Focus on the value/benefit that user will get, rather than on the action they have to take. Eg. ‘Sign up now’ vs ‘Create my free account’.
(8) Use click-triggers (short messages written **next** to the button that significantly increases conversion just like the main microcopy **on** the button), as much as possible. If necessary, write two to three click-triggers, but don’t overdo it.
(9) Don’t punctuate or format it.
Links
If your CTA is a link, there’s a little more room.
(1) Use descriptive text for links. Set contextual expectations about what’s behind the link.
(2) When possible, use verb + noun construction.
(3) Write the link to be large enough for people to select—at least 8 characters.
(4) Don’t write link text longer than 6 to 8 words (about 55 characters).
(5) Don’t put multiple links at the same place on the same page.
(6) Avoid in-line links for accessibility. If you must use them, make sure they're underlined
(7) Headlines should not be links.
(8) Avoid writing *Click here* for links or buttons. Instead, provide clear context for where the CTA will take the customer, For example, “Check pricing”.
(9) “Learn more” as link copy doesn't work well with customers. More casual phrases work better, like ”Find out more” or ”Get more info”. To make a link more accessible, include some additional context, like ”Review your options” or ”Get pricing details”.
Purpose: To set expectations and build excitement while indicating that the empty state is intentional.
When users open a page or feature that they haven’t used before, you have an opportunity to show them the feature’s potential and motivate them to start using it. Instead of saying that there is nothing here, write about what is supposed to be here or what they can do here, what this feature does, and how it can help them.
If relevant, add instructions. Tell users exactly how to start using the feature (if possible, its best to add a visual), or provide a link. Descriptions, buttons, and titles are great tools for empty states.
An empty state can happen in these situations:
(1) First-time use: Someone hasn’t tried out a feature or product yet, either because they’re new or still exploring.
(2) No info or data: Info was deleted, or a search in a database doesn’t return any matches.
(3) Task completion: There are no new updates to share. This could happen when someone has completed a task, like categorizing all their transactions.
When drafting an empty state:
(1) Be clear:
Empty states should explain in plain language what’s happened and what, if anything, someone can do to move forward. In first-time-use scenarios, try to be specific about what info will appear after the first use so the benefits and functionality of the product or feature are clear.
(2) Be helpful:
When you can, use a positive tone in empty-state messages. Encouraging content might be all it takes to motivate someone to keep trying. Avoid shaming or blaming if someone reaches a dead end or hasn’t tried something out yet.
(3) Keep it brief:
Get to the point quickly and cut out irrelevant details and extraneous words so people can get on with their day. Empower people to act quickly by providing just enough info to explain what’s happening and how to move forward.
(4) Inspire action:
Empty-state content should encourage people to act, whether that means trying out a new feature or doing something differently with an existing one. In the end, we want to help people achieve what they came here to do.
(5) Know when to delight:
Use your best judgment in deciding when to delight. For example, with frequently recurring empty states, it might make sense to lean on clarity over delight. Repeated exposure to the same message may result in “delightful” content becoming irritating over time. However, when someone has achieved a goal and the message is primarily celebratory, it might make sense to lean on delight.
What to include in an empty state:
Headline: Make sure your headline is clear, brief, and includes the most important info. This way, the user can get the gist of the entire message, even if they don’t read anything else. If you can do this in one line, even better.
More info: If you need more room to explain in addition to the headline or CTA, write a brief body message. Elaborate on the headline and tell someone how to move forward. If the headline tells the user everything they need to know, there’s no need for a body message.
- Expand on—but don’t repeat—the headline message.
- Describe the benefits of the product or feature.
Call to action (CTA): Tell the user what they can do next or suggest another task they could be catching up on. There can be up to two CTAs: primary and secondary. CTAs are usually buttons, but they can also be links—use your best judgment when deciding which fits better in your experience.
Purpose: Help people get where they want to go and, if necessary, indicate that there’s a problem getting there the way they intended.
Error messages need to fulfill three goals:
(1) Explain simply and clearly that there is a problem and what that
problem is.
(2) Provide a solution so that users can return and complete the process
immediately.
(3) Turn the delay into an experience that is as pleasant as possible.
Keep it simple
Error messages usually consist of two or sometimes three things.
- Error or alert definition
- Tell users what happened. Be honest and let users know what the system did, what they did, or what they’re about to do.
- If you have any information about the error, let users know. Be specific. Don’t just say “Something’s not right”.
More information (optional)
If we have information that doesn’t fit in the error or alert definition or call to action, we can include an additional sentence. We want to keep error messages brief, so more information is optional, and it’s great if we don’t have to include it.
Call to action
Tell users what to do next to solve the problem. If the user can’t fix the problem, let them know what next step they should take (such as trying again later or contacting help).
Avoid the try-again loop
Errors and calls to action shouldn’t trap users in a try-again loop. If the user doesn’t fix the error the first time, it’s annoying for them to see the exact same error the second and third time around.
For example, there are cases where we say something like, “Make sure you’re uploading the right file and then try again.” And then, after their second failed attempt, we give them a more helpful follow-up message like: “That’s still not working. Let’s go ahead and type your info.”
Do not blame the user
In situations where the error is as a result of the user’s action or omission to act, do not make it personal. Make the error message situational. For example, If the user’s account doesn't have enough funds in them, instead of indicating that message in those many words “You don’t have enough funds for this transaction”.
Lead with empathy. Match tone to severity
Depending on where in the user journey the error pops up, the frustration leading up to it can be massive. We must weigh the extent of frustration the error is likely causing and acknowledge that frustration as candidly as possible. Empathy can be established by taking responsibility, not making the user feel any worse than they already are, and reassuring them that they can come back from it. If possible, use the heading to lead with the solution and use the description to elaborate on what the problem is.
Being brief is not necessarily the norm
When it comes to things not going to plan, the users are invested enough to read to get out of the error state. Depending on what the error is, they probably want as much information on the issue and also the accompanying reassurances to know that all will be fine and that there’s a way out. A good example of this would be error states pertaining to processing transactions. The user definitely wants to understand when something goes awry with their money, why that’s happened, what can they do to make sure it never happens, and that their assets remain unaffected and safe.
Don’t ever write “oops” or “whoops” or “uh oh”
We don’t do that. This is not aligned with our voice and it has a way of belittling the user’s pain.
Is it a page-level error or a field-level error?
Sometimes, page-level error messages aren’t necessary. Use field-level errors so people know which info to change before they can move forward.
Avoid error codes
Don’t include error codes in your message. They’re jargon and fail to provide any meaningful information.
Confirmation dialogue boxes are employed to ask users to verify whether they want to:
(1) Proceed with a requested action or
(2) Cancel a requested action.
The messages are there to verify that users truly intended to perform that action, and are (fully) aware of its consequences. It must restate the user’s request and explain what the computer is about to do, with specific information that allows users to understand the effects of their action. Without identifying details, it’s useless to ask users to confirm a request.
A good rule of thumb to bear in mind when deciding to use a Confirmation is if the action in question is something that can be easily reversed, inconsequential, and is taken quite frequently.
Reversibility
When users are about to take an irreversible action, like permanently deleting an item. But if the action is reversible, we can only use an undo toast.
Severity
When users take an action that will result in critical consequences or a loss with long-term repercussions, we should certainly ask if this is truly what they intended to do.
Complexity
When users are about to take an action that will result in complex consequences, for example, affecting the configuration of other devices. If the consequences easy to understand, short or even non-existent, we can consider a short toast message.
Frequency
Frequent actions will quickly become annoying if users are asked to reconfirm every step. On products or features they use daily, there is also a low probability that users will accidentally take an unintended action.
The anatomy of a confirmation dialogue usually includes the following three elements:
Component 1: The headline:
(1) The headline should ask or inform the user about one main action we’d like to reconfirm. It should be clear and unambiguous.
(2) Don’t use generic headlines like ‘Warning’ or ‘Are you sure’.
(3) Avoid useless introductions like “Do you want to…”, “This action will…”, and again, “Are you sure”. Start with what’s important.
Component 2: The body copy (optional)
(1) The more critical and less reversible the action, the more attention you should give to the explanation in the body copy.
(2) Where the user may not be aware of the full length of consequences, it’s pertinent that it be explained or at least mentioned in the body copy.
(3) Otherwise, using the body copy is not mandatory if you don’t have anything new to explain other than what is already mentioned in the headline.
(4) Assume that users only read the headline and what’s on the buttons. When there are significant consequences for an action and you’re concerned users might skip the explanation, include it in the headline.
While writing the body copy wherever necessary,
(5) Do not ask Are you sure you want to do this? Instead, explain what this is, in user-centric terms and make it likely that the user would recognize a mistake.
(6) If you believe the user is unnecessarily taking a destructive action, inform them in the body copy of the alternative better suited for their needs.
Example:
(7) Consider using progressive disclosure to allow users to learn more about their command's consequences before committing, while keeping the text in the confirmation dialog brief enough.
Example:
Component 3: Buttons
(1) The buttons should clearly show two distinctly different options that users can’t mix up.
(2) Instead of Yes/No answers, provide response options that summarize what will happen for each possible response. For example, in the case of file deletion, use buttons labeled “Delete file” and “Keep file”.
(3) To help users easily connect the headline and the buttons, make sure to use the same verb in both.
(4) Avoid giving confirmation dialogs a default “Yes” answer. The entire purpose of confirmations is to make sure that users double-check their actions and don’t proceed unless they’re really sure that they want to perform the dangerous action. Example:
Purpose: inform or remind a person to engage with the experience.
Notifications interrupt people to get them to pay attention to a part of the experience that they aren’t paying attention to. They are reminders or information that should always have value and be urgent, or at least time-appropriate for the person receiving them.
We use several types of notifications to communicate with our customers :
In-product notifications
These messages appear in the customer’s product, next to the related action. They provide guidance and information.
Push notifications
Push notifications are sent from an app to the customer’s device. They tell the customer to open the app for a specific reason. Push notifications are only on-screen for a few seconds and can be easy to miss.
The voice and tone of notifications should be based on what the user needs.
(1) More emotional tone for milestones and celebrations
(2) More functional tone for alerts and urgent to-do's
If a customer gets a notification about their transaction status, we should be clear and concise. If they get a notification about price alerts, we can be whimsical about it.
There are 3 levels of urgency that affect voice and tone—low, medium, and high.
Low urgency
These messages give the customer information based on an action they took in the product. They can be about an app-specific improvement, like a new feature.
Medium urgency
These help the customer in a clear way. For example, they might encourage customers, help them celebrate, identify opportunities, or get through a workflow. The benefit is front and center.
High urgency
We send high-attention, time-sensitive messages to customers to resolve or complete an action. We take them to the exact point of the product to get the job done.
Consider timing
- Notifications interrupt people, so only send them when you have a good reason. If you send one at a bad time, the person might miss it or, even worse, they'll turn off notifications or delete the app.
- We don't always know when, but we should avoid sending notifications at night or too early in the morning, based on the person's time zone. The only time this isn't true is when there's an urgent update.
- No matter what type of notification you’re sending, remember that less is more—don’t bombard our customers with notifications.
Optimize for readability
Devices and operating systems have different character count requirements for titles and descriptions. Instead of focusing on the max character count, think about [limits by device](https://clevertap.com/blog/what-are-push-notification-character-limits/) and [optimizing for readability](https://baymard.com/blog/line-length-readability).
Keep it short and to the point
While your headline can be more playful to capture someone’s interest, the rest of your notification content should get straight to the point. Focus on a key piece of information, then tell the user what action you’d like them to take next on their journey with your brand.
Provide a clear action
The call to action should set the expectation of what happens next, whether it's leading the user to get something done, learn something valuable, or fix something quickly.
Make it count
We don't want to announce every little thing. We want to give customers the right information at the right time, so they don't tune us out.
Before writing a notification, ask yourself:
- Is this the best channel for this message?
- What's the customer benefit of this message?
- Who's the target audience of this message?
- What action are we asking them to take?
- Will this disrupt their workflow?
Share good news when it happens
Let them know when things are complete or that they reached a goal.
Share bad news directly
When possible, clearly state what happened and what we’re doing to fix it or what the customer can do to make it right.
An in-product notification is served when the user is already engaged with the product. Remember, if these notifications aren't useful, customers will ignore them.
Context is just as important as content
Notify customers in a context related to the notification. Keep content focused on helping them discover new features they can benefit from at the moment.
Personalize to delight
Use opportunities to speak directly to the user’s needs and help them get their job done. Use what we know about them to create moments of delight and comfort.
Push notifications are messages that an app sends to a customer's device. They can engage people even when they're not using the product. People need to have notifications turned on to receive them.
Keep in mind there are some guidelines specific to iOS and Android notifications.
Limit frequency
As a rule, use fewer notifications. People get lots of notifications from the apps they use. Adding more notifications will make people annoyed and they'll turn them off.
(1) Before sending a push notification, ask yourself:
(2) Does this need to be a push notification? Is it better suited to another type?
(3) When was the last time they received a notification from us?
(4) How many other notifications are they receiving from us?
(5) How often should they receive this type of notification?
(6) How can we bundle notifications?
Use emoji with care
Use emoji in push notifications to add feeling, but not too many. Remember culture, accessibility, and tone when you choose them.
Avoid sensitive information
Be careful with push notifications. They can be seen by anyone, so don't include private information that could hurt our users if someone saw it
Purpose: Text fields let users enter information to answer the questions that the websites or app is asking for.
Fields use UX text as labels, hints, and prefilled text for entering text, email addresses, numbers, dates, and other information.
Labels:
Field labels are names given to the fields themselves, like First name, Date of Birth, etc. Clear label microcopy is one of the primary ways to make user interfaces more accessible and understandable.
Labels tell the user the purpose of the field, and labels should stay visible even after completing the field. Without a label, it’s pretty hard to piece together what’s being asked of you.
Label do’s and don’ts:
(1) Labels should use succinct, short and descriptive (a word or two,) so users can quickly scan the form.
(2) Be clear and jargon-free.
(3) Ask questions sparingly. Questions increase cognitive load but are helpful in certain situations like step flows.
(4) Show fields if you have fewer than 6 inputs.
(5) Don’t use labels in the fields themselves if they disappear when a customer selects or starts typing in the field.
(6) Don’t use all caps. They’re hard to read.
Purpose: Also called ghost text, is text inside a field that provides additional guidance, clarity, or examples.
Placeholder text should never exist in isolation. Field labels should be descriptive enough to guide users. Only use placeholder text when a bit of additional guidance is useful.
Placeholder text do’s and don’ts:
(1) Use placeholder text in some, but not all, form fields. Not every field in a form needs placeholder text.
(2) Add formatting to the label or under the field, where it’s persistent.
(3) Don’t use placeholder text as a replacement of a field label or to echo the field label.
(4) Don’t use placeholder text to show formatting. It disappears when a customer starts typing in the field.
(5) It’s unadvisable to put hints or instructions as placeholders, because your users might need to refer to them while typing, and they’ll need to delete what they’ve already entered to see the advice.
(6) If you have instructions about a specific field, such as the rules for a password, restrictions on specific values, or a limitation on the number of characters, write these beneath the label, or in a tooltip - as long as users can come back and see the instructions at any time, even while typing.
(7) Use placeholders sparingly. When users first see a form, it needs to look as simple as possible and provide the feeling that there’s not much work, or that it’s easy to fill out. Blocks of text immediately negate this feeling, because users need to read all those words, work in itself; and also a lot of text hints at a lot of work. Therefore in forms and other areas where users need to complete tasks, the rule is always, **as few words as possible**.
(8) Placeholder text that disappears when the cursor is placed in a form field is irritating for users navigating with the keyboard.
Bear in mind that Placeholder text is generally bad for accessibility. The default light-grey color of placeholder text has poor color contrast against most backgrounds. Not all screen readers read placeholder text aloud.
These labels are placed within the form field as placeholders until the field becomes active and the user moves the input focus into the field. At that point, the placeholder label moves to the top of the field. As a result, the floating label (also known as an adaptive placeholder) is always visible, either in the center of the form field, or above the text that the user entered.
There are two main advantages to this approach:
(1) It can save space on mobile devices.
(2) The visible label serves as a memory aid while people are in the typing stage.
But,
(3) Fields with stuff in them are usually less noticeable.
(4) Users may mistake a placeholder for data that was automatically filled in.
Floating labels do offer a better user experience than the label as a placeholder. But if you have the screen space, placing the label and hint outside the field is still the best way to go.
As a rule of thumb, only ever ask for information that is absolutely required. An exception to this are forms where users need flexibility, for example, “Address line 1” “Address line 2”.
If most information is required, indicate at the start of the form:
(1) Complete all fields.
(2) All fields are required.
When some fields are optional, indicate at the start of the form:
(1) All fields are required unless marked optional.
(2) At the field level, use a text label:
- Middle name (optional)
- Company name (optional)
When there are multiple steps or screens to complete, use Skip, Not now, or Maybe later to indicate optional fields.
If more information is optional, call attention to what’s required. At the start of an experience, describe how required fields are marked:
(1) * indicates required information
(2) *Required information
Use an asterisk after the field label to indicate the required info:
(1) Social Security number*
(2) Display name*
According to the Nielsen Norman Group, customers recognize the asterisk as meaning “required,” regardless of whether they use assistive technology.
