How to use this guide?
“Give me guidance, but let me drive.”
These guidelines are simply that – guidelines. We don’t want to tell you how to design, but this is a good starting point to get you going on native mobile designs.
As we continue to design cross-device end-to-end experiences and features for products and services, we must remember not to neglect the different platforms, which include native mobile apps and desktop client apps.
This document focuses on native mobile app patterns. We do offer components in this document, but we don’t provide refined visual components that you can select and grab for your designs.
This is the start of an evolving document that captures common native mobile patterns that we can use across our ecosystem of mobile products. Each pattern also includes best practices, do’s and don’ts, negotiations, and exceptions.
Use this document for reference at any point in your design process. If you are new to mobile design or new to designing within our mobile app ecosystem, take a look and get a feel for all of our apps first, which are all available for
- iOS and Android
- Online Payroll
- QuickBooks Online
- QuickBooks Self-Employed
Think device first
Push your thinking beyond “mobile first.” Start thinking about leveraging device capabilities first. The native mobile device has a lot to offer: touch, voice, pressure, accelerometer, notifications, etc. You are designing around the device, the platform, the user experience. Patterns help ground us as a system and unify an experience across an ecosystem of products, but patterns should by no means be the first or last stop in the design process.
Respect the platform
We documented patterns and components based on native operating systems: iOS and Android. When designing for native platforms, you should consistently refer to the native OS design guidelines first for maximum quality. Consider this specific document as a supplement or an addendum that guides you to incorporate the QuickBooks ecosystem.
- Apple human interface guidelines
- Material Design Guidelines
Focus on the customer benefit
Always design for the customer benefit first. No use case is the same, and many use cases have exceptions. Do not design something simply because you can reuse a pattern or component for another feature. Always question yourself: How will this benefit the customer?
Phones vs. tablets
The QuickBooks ecosystem of mobile apps is currently supported on both iOS and Android for phone and tablets. We define and distinguish phones and tablets based on usage and screen sizes.
What is a phone?
Mobile interfaces less than 7 inches width should be treated as a phone. Syntax and layout should be aligned across these devices as much as possible, but we also want to leverage native platform guidelines and capabilities first and foremost.
A fundamental design principle for mobile phones: Include only necessary information. Do not overload the user with more than they need to know or take action on. The phone is a convenient way to consume information on the go. Small business owners use a phone to complete quick actions while they are not in the office, capture data, view stuff, then perhaps close it out and come back to take a look later.
What is a tablet?
Mobile interfaces greater than 7 inches width should be treated as a tablet. Syntax and layout should be aligned across these devices as much as possible, and by no means should they need to align exactly the same as the less than 7-inch interfaces.
A fundamental design principle for tablets: Tablet designs should look and feel like desktop web, but they should function like the phone. Many users view the tablet as a hybrid device. We’ve encountered many small business owners that don’t own a computer, but they own a tablet, and those users treat the tablet as a reliable device they can do work on.
Native, embedded web, mobile web
This document focuses on native mobile patterns. There seems to be much confusion around what is embedded web and what is native design (which is actually great because if you can’t tell the difference, then our users hopefully won’t either!). In our mobile apps, we have a hybrid of native screens and embedded web screens. Embedded web means the content embedded in the native shell is not built with native components in a native environment. It instead uses web technology.
When you open the app and everything on the screen is built or drawn natively in a native environment with native system controls, this is just called native.
When you open the app and there is a title bar with embedded web content underneath it, we call this concept embedded web.
When you do not open the app and you are viewing the website in a mobile browser, we call this mobile web.
Guidelines in PDF
Our primer and documentation
Layouts and workflows
Diagrams showing the complexity of our native apps
All the fonts
Fonts used in our native apps
GUI components kit
Our own Teehan+Lax UI kit for QuickBooks
Layouts and workflow
This is a high-level information architecture for not just QuickBooks Mobile, but also for our ecosystem apps GoPayment and Payroll. We show this IA in wireframes because we don’t want folks to focus too much on content and color; they can change. This IA also helps us visualize the complexity of QuickBooks and how much smaller the stand-alone apps are.
The general rule for native mobile design is to use system fonts as much as possible. However, we need to incorporate our brand and voice and tone to create QuickBooks Ownable Moments. Here are some guidelines on how to approach fonts on native mobile.
The header, also known as title bar, is a special kind of toolbar for branding, navigation, search, and actions.
The title in the app bar reﬂects the current page. It can be an app title, page title, or a page ﬁlter. The menu or hamburger icon is a control to open a navigation drawer.
The navigational menu, or left nav, allows the user to navigate to different parts of the app. The left nav is the primary method for navigation in the app.
Not every left nav is the same. Icons are shown in the nav for tablets, but not on phone. Moving forward, the future state nav will replace every nav you see today. There will be one consistent nav for all devices.
A card is a component acting as a rectangular container for a certain amount of information: visual elements, instruction text, diagrams, and action triggers. There are two types of cards based on appearance and usage: action card and info card.
Create pattern appears as a floating action button, which represents the primary action in an application. Shaped like a circled icon ﬂoating above the UI, it changes color upon focus and lifts upon selection. When pressed, it may contain more related actions. Only one ﬂoating action button is recommended per screen to represent the most common action. It animates onto the screen as an expanding piece of material, by default.
General rule of thumb for native mobile design: Use action sheets whenever there are multiple actions associated with a single call to action (that is not a system blocker).
Apple iOS guidelines calls these action sheets. Use action sheets whenever there are multiple actions associated with a single call to action. Google Android calls these bottom sheets. Use bottom sheets whenever there are multiple actions associated with a single call to action.
We use native system dialogs for critical alerts, permissions related alerts, system blocker alerts, etc. The key word is “alert.” Note that for actions that aren’t related to these things, we try to use action sheets.
Historically, we have always defaulted to the system loading indicator because there wasn’t a common branded loading indicator that was deﬁned. Now, we want to replace all of these with the newly deﬁned loading indicator.
Different loading indicators are used for Payroll and GoPayment and Self-Employed. We want to ﬁx this issue and use the new loading indicator (spinners) to replace all of these rogue ones.
Zero state screens provides the first impression with users who are new to our products. It usually consists of an illustration and description paragraphs. Each label on the left nav can trigger a zero state screen of its own.
These are the key messages, in order of importance, that all native mobile content ladders up to:
1. QuickBooks has your back.
- We genuinely care about you and your success.
- We proactively guide you and take work off your plate.
- We’re your partner and advocate, not a box of tools.
2. QuickBooks is right for you.
- We know who you are and tailor things for you.
- You can customize QuickBooks so it works for you.
- You can jump straight to the jobs that matter to you.
3. QuickBooks goes where you go.
- You can do the most important jobs on mobile.
- We use the full capabilities of your device to save you work.
- You can switch between mobile and web without a hitch.
- Follow the QuickBooks style and voice and tone guidelines
- Write for portrait orientation
- Prioritize consistent language
- Put important info and CTAs above the fold
- Don’t make a user scroll more than once to read the whole screen
- Give info in small chunks with the option to find out more (progressive disclosure)
- Limit platform-specific words like “touch” and “tap” (use “select” instead)
- Design for both Android and iOS, allowing for slightly different experiences as needed
How mobile content is different
- There’s less space on the screen
- Text looks longer (and more overwhelming) on mobile
- It wraps more
- It takes up a bigger percentage of the screen
- Users expect mobile apps to be simple
- Mobile users are often multi-tasking (driving, ordering coffee) in distracting environments (in the elevator, on the street)
The champion on mobile
How do we show up as the champion when there’s less space and focus?
We empathetically adapt to meet the user where they are.
On mobile, this means:
- We keep text to a minimum and prioritize the most important info
- We get out of the way so users can get stuff done
- We make their choices quick and easy so they can get on with their day
Simple-seeming interactions can be full of hidden choices:
- “What should I do next?”
- “Will this work for me?”
- “Should I keep trying or give up?”
- “Can I ignore this?”
- “What should I put in this box?”
- “What should I choose from this menu?”
- “What should I do about this error?”
As the champion, our job is to help users:
- Make the right choice
- Make a choice fast
- Feel confident in their choice
Here’s how we do that.
Tell them what they need to pay attention to (and why)
- “This could save you over $1000 in taxes.”
- “Update your billing info so you don’t lose service.”
And what they can safely ignore
- “This only matters if you make over $31,500 a year.”
- “Skip this if you work from home less than 25 hours a week.”
Tell them when the stakes are high
- “Ask your accountant before changing this.”
- “You can only send this once, so double-check it first.”
And when they can wing it
- “Not sure? Stick with X for now. You can always change it later.”
- “Don’t worry about getting it perfect—your best guess is fine.”
Tell them what’s common for people like them
- “People who drive for work usually choose X.”
- “The standard amount is $X. Stick with that unless you know yours is different.”
And what’s rare or unlikely
- “This is uncommon, but it could save you money if you qualify.”
- “Got a marriage allowance? (Uncommon)”
And when possible, take tricky decisions away.
- Set a default that works for most people. Give them the option to change it.
- Use what we already know about them (or people like them) to make smart assumptions.
- Do as much work as we can behind the scenes. Let them know only as needed.
Writing for a small space
Use active voice and simple tenses.
- “We updated the app” instead of “The app has been updated”
- “You’re in a free trial” instead of “You have been placed in a free trial”
- “You’re done!” instead of “You are done!”
- Use pronouns (“we,” “they,” “it,” and so on)
- “Forgot your password? We’ll help you reset it.” instead of “Forgot your password? We’ll help you reset your sign-in credentials.”
- “We’re here for you” instead of “The QuickBooks team is here for you”
Start sentences with verbs.
- “Do it all in one place” instead of “You can do it all in one place”
- “See you soon!” instead of “We hope to see you soon.”
Use abbreviated sentences.
- “Changes saved” instead of “Your changes have been saved”
- “Save your changes?” instead of “Do you want to save your changes?
- “Got a sec?” instead of “Have you got a second?”
Remove filler words and phrases.
- is designed to
is designed to make accounting simple , but really, it’s also extremely useful if you need to and lets you manage your whole business in one place.”
Swap long words and phrases for short ones.
- utilize > use
- initialize > start
- initial > first
- finalize > finish
- implement > do
- assistance > help
- remainder > rest
- just a little bit > a bit
- referred to as > called
- due to the fact that > because, since
- at certain times, there are times when > sometimes
- generally speaking, in most cases, it is usually the case that > usually
There are times when Sometimes, things go a just a little bit differently from the way we don’t go as planned. The good new is, our support team is standing by to here to give you assistance help.
Space-saving dos, don’ts, and OKs
Abbreviations and acronyms
- Do use instantly-recognizable acronyms:
“IRS,” “CRA,” “HMRC,” “SDK” (for developers only)
- Don’t use unfamiliar abbreviations and acronyms
“trx” (say “transactions”), “FI” (as in “financial institution”—say “bank”), QBO, QBSE, TT, accounting abbreviations like “A/R” and “A/P” (except when talking to accountants)
- OK to use common abbreviations in small spaces
“Wed,” “mo.,” “sec,” “yr,” “hr”
- Don’t use them in full sentences:
“Give us your info & we’ll estimate it for you.”
- Don’t use them with items that aren’t commonly paired together:
“reports & mileage,” “shirt & towel.”
- OK to use them in tight spaces (like labels) if the items are commonly paired together:
“profit & loss,” “meals & entertainment.”
Note: Only English has ampersands, so they expand when translated.
- Don’t use them in full sentences:
“Add your income/expense transactions” (say “Add your income and expenses”).
- OK to use them in tight spaces (like labels):
“Spouse/domestic partner,” “Car/truck,” “Hrs/month”
Don’t leave out crucial info because it doesn’t fit.
- Do: Change the design to make space
- Do: Find a way to say it in fewer characters
- Do: Add a link to more info (progressive disclosure)
Don’t be robotic, terse, or bossy
- Action required: bank connection issue”
- “Server error. Refresh the page.”
- “Action failed.”
Types of mobile content
(and how to write them)
What it is: a short, prominent message that communicates the most important info on the page, modal, or container
- The user may not read secondary content, so make sure the headline contains the most important info
- If the user needs to do something, tell them in the headline (otherwise they might miss it)
- When possible, include a benefit
- Try to keep the headline to 1 line
What it is: secondary text that adds more info or guidance
- Use subheads or helper text to:
- Show our personality
- Explain the benefit
- Give expert advice
- Proactively answer questions before the user has to ask
- Don’t repeat the contents of the headline or primary text.
If the primary text is “Add a home office,” don’t say “Give us info about your home office” in the helper text.
- Try to keep subheads and helper text to 1-2 lines
- Include a link to additional info if helpful
What it is: short text that describes the purpose of the page and grounds the user in where they are
“Add note,” “Select province,” “Edit trip,” “Trip details”
- Use verbs when the user is taking action and nouns when they’re viewing info (if the page has different states, use your judgment
- Use consistent top headers across similar pages. For example:
- “Edit trip,” “Edit transaction,” “Edit invoice” (changing something that already exists)
- “Add note,” “Add income,” “Add address” (adding something new)
- “Trip details,” “Transaction details” (viewing details)
- To stay consistent, don’t use articles (“a,” “the,” and so on) or possessives (“your”) because there isn’t always space
Call to action
What it is: text on a link or button
Examples: “Add,” “Save,” “Edit”
- Use consistent CTAs for similar actions. For example:
- Use “Save” when the user is saving something they created or edited
- Use “Add” when they’re adding something new
- Use “Apply” when they’re applying a filter or date range
- To avoid repetition, use 1-word CTAs (“Add,” “Save”) when the rest of the page makes it clear what’s happening. Example:
If the top header is “Add note,” the CTA should be “Add”
- Use consistent CTAs for similar actions. For example:
To stay consistent, don’t use articles (“a,” “the,” and so on) or possessives (“your”) because there isn’t always space
Field label/ghost text
What it is: text above and inside a field that tells the user what to enter
- Use labels to describe in 1-2 words what info goes in the field
- In labels, don’t use possessives (“my,” “your”) unless it prevents confusion. Example: Say “Your email” if the user might think we mean their customer’s email.
- For optional fields, put “Optional” in the ghost text (not in the label)
- When an example would be helpful, put it in the ghost text (“Ex.: Heidi’s Hardware”)
- Otherwise, make the ghost text a short question (“Who paid you?”) or simple instruction (“Enter your note”)
What it is: a short, contextual message that tells the user about an action they need to take, gives important info, confirms an action, or celebrates a success
- 93 characters max, including the CTA
- In alerts, be clear and informative (which doesn’t mean dry) to make sure the user understands what’s happening and what to do
- Confirmations are a chance to delight (when it’s right) and celebrate the user’s success (not ours)
What it is: a message that appears on the user’s device, outside the app
- 62 characters max
- Use notifications to:
- Inform users of critical issues that affect them or their account
- Give proactive insights and tips
- Let them do tasks (like sorting transactions) without logging in
- Add delight to their day (when it’s right)
- Use emoji to add visual interest and emotion, but don’t use them to replace words
- When possible, let users do actions directly in the notification
- Prioritize messages so users don’t get notifications too often
Ways of formatting mobile UI content
- Bullets and lists
A way to format subcopy and data
Length: 2-4 items per subcopy list, any number for data
Construction: any so long as it’s parallel (use numbered items only when they’re steps)
- Bullets and lists
- Assistant layer
Containers that include other types of mobile content, used for in-context help, FTU, “extra credit,” search, CUI, etc.
Length: 1 question/task/idea per utterance or screen
Attributes: encouraging, experienced, optimistic
Principles: Focus on the payoff; make it personal
Refer to Intuit best practices for conversational user interfaces
Mobile content checklist
- Write for portrait orientation.
- Use active voice, present tense, and sentence-style capitalization.
- Prioritize consistent language.
- Don’t make a user scroll more than once to read the whole screen.
- Use secondary screens for secondary info.
- Stay on voice and tone.
- Don’t write less; write more simply. Don’t just shorten web content.
- Skip platform-specific words like “touch,” “tap,” and so on.
- Use accessible language (ex: “go to” instead of “see”).
- Make sure users always have a way forward.
- Remember that Android uses a back button on the device itself.