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




One mobile app messaging architecture

The messaging architecture outlines what we always want to convey to the customer in every piece of content.

  1. QuickBooks is right for you.
    How to do it:

    • Use job-focused words.
    • Concentrate on one job at a time.
    • Make cross-job connections only when appropriate.
  2. QuickBooks is mobile-first.
    How to do it:

    • Choose words purposefully.
    • Place a premium on consistency.
    • Maximize device and tech capabilities.
  3. QuickBooks is here to help.
    How to do it:

    • Be proactive and conversational.
    • Prioritize real-world language.
    • Break content into digestible chunks.

Mobile-optimized content

Wondering whether content is mobile-ready? Start by asking these questions. Mobile content should be usable, simplified, branded, and accessible.

  • Usable
    How actionable is your content?
    Is the most important info (especially the call to action) above the “fold”?
    Are you using progressive disclosure?
  • Simplified
    How brief is your content?
    Do users understand it?
    How many times does a user have to scroll?
  • Branded
    Which voice and tone attributes are you using?
    Which voice and tone principles are you using?
    What’s your rationale behind these choices for mobile?
  • Accessible
    Is your content platform-agnostic?
    How are you giving UI direction inside the app?
    What kinds of verbs are you using in CTAs?
    Can your content be easily translated and localized?

Types of mobile UI content (and how to write them)

  • Navigation cues
    Menu items, screen-level titles, tabs

    • Length: 1-3 words, 20 characters maximum
    • Construction: any, so long as it’s consistent
    • Attribute: straightforward
    • Principle: Put them in control

  • Top line
    Sets expectations for the content container, functions kinda like a headline

    • Length: 1-2 lines, 6 words or so
    • Construction: phrase or sentence
    • Attribute: straightforward
    • Principle: Focus on the payoff

  • Subcopy
    Usually accompanies top line, explanatory, helps user understand what they’re looking at or contains an in-line contextual prompt

    • Length: 2 lines maximum
    • Construction: sentence
    • Attributes: encouraging, experienced, clever
    • Principles: It’s about them, not us; focus on the payoff

  • Buttons and other calls to action
    A link, button, or other tappable item on a screen

    • Length: Alone or stacked: 20 characters, 3-4 words
    • Side-by-side: 10 characters, 2-3 words
    • Construction: verb phrase (avoid both 1st and 2nd person)
    • Attribute: straightforward
    • Principle: Speak their language

  • Labels and ghost text
    Instructive copy telling users what a thing is or where to type

    • Length: Field labels: <50% of the length of the field
    • Ghost text: < 75% of the length of the field
    • Other labels: just make it fit in the space, OK?
    • Construction:
      Field labels: noun + modifiers
      Ghost text: use “example” or “Ex:”
    • Attribute: straightforward
    • Principle: Put them in control

  • Notifications
    Actionable alert that needs users’ attention (especially actions they can complete without opening the app), appears on lock screens and notification centers

    • Length: 62 characters maximum
    • Construction: sentence, using emoji if appropriate to punctuate at the end, not to replace words
    • Attributes: encouraging, clever
    • Principles: Make it personal; speak their language

  • In-app messages
    Messages confirming an action, conveying an optional action, or celebrating a user victory, usually interstitial (snackbars, toasts, confirmations, celebrations, alerts, etc.)

    • Snackbar/toast/confirmation length
      No CTA: 93 characters maximum
      With CTA: 66 characters maximum, CTA 8 characters maximum
    • Construction: sentence or phrase, no terminal punctuation
    • Attributes: straightforward, optimistic, clever
    • Principle: Celebrate what really matters

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?