Native mobile patterns are here!

We’ve been working hard to pull together patterns and components from our ecosystem of native apps so that you can hit the ground running, or run even faster, with mobile design. This documentation addresses many frequently asked questions around mobile patterns.

We also documented high-level information architecture and workflows for our apps, which we think will be helpful for everyone to visualize the structure and how mobile screens are pieced together.

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
  • GoPayment
  • Online Payroll
  • QuickBooks Online
  • QuickBooks Self-Employed

Overall principles

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.

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.

Embedded web

When you open the app and there is a title bar with embedded web content underneath it, we call this concept embedded web.

Mobile 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

Guidelines in PDF




Layouts and workflows

Diagrams showing the complexity of our native apps

Layouts, IA, and Workflows




All the fonts

Fonts used in our native apps

Brand Fonts, native fonts, all the fonts




GUI components kit

Our own Teehan+Lax UI kit for QuickBooks

GUI Components kit




Messaging architecture

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.

Basic guidelines

  • 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”

Use contractions.

  • “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.

  • very
  • actually
  • really
  • just
  • even
  • totally
  • extremely
  • is designed to

“QuickBooks 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”

Ampersands (&)

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

Slashes (/)

  • 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

Subhead/helper text

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

Top header

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”

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)


  • 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.
  • Was this Helpful?