Most people who build onboarding content build it at a desk. On a large monitor, an eight-sentence situation fits in one glance and a popup in the middle of the screen feels fine. New hires, though, often open that content somewhere short and interrupted: a commuter train, the five minutes before a meeting, a lunch queue.
These are the design rules we settled on while making First Run playable end to end on a phone. First Run is a web app that opens directly in the browser, so everything here is limited to what the web can do, with no installed app involved.
Cut It Into Five-Minute Pieces
A phone session is short. So the starting point for design is not the total amount of content but the unit that can be finished in one sitting.
In First Run, a single quest takes about two to four minutes: read the situation, choose, read the feedback. Five spare minutes are enough to finish one quest and close the tab. Progress is saved automatically in the browser, so there is no save button to remember, and the next time you open the game, it picks up exactly where you left off. Because progress lives in the browser, it is worth telling players up front that they need to come back on the same device and browser.
Two principles follow from that structure.
- One decision finishes within one session. If someone reads a situation, closes the tab, and sees only the options the next day, the reasoning behind the choice is gone.
- The next action is obvious on return. Even if they cannot remember what they were doing, the current objective in the HUD and the navigator arrow tell them where to go next.
Put Controls Where the Thumb Is
Holding a phone in one hand, the thumb comfortably reaches the lower part of the screen. The more often a control is used, the lower it belongs.
Controls at the Bottom
In portrait, First Run places the D-pad and the A, B, and MENU buttons below the map in their own area. The buttons never cover the map, and the thumb does not have to stretch. Holding the D-pad keeps you walking, and you can also tap or swipe the map directly to move.
Bottom Sheets Instead of Centered Popups
A popup in the middle of the screen is natural on a desktop. On a phone, it pushes the close button into the top-right corner, which is hard to reach one-handed. Every dialogue, quest, feedback, and review screen in First Run is a bottom sheet that slides up from below. Titles and buttons stay pinned to the top and bottom of the sheet, and only the content scrolls.
Touch Targets and Safe Areas
What matters is not how big a button looks but how big an area responds to a tap. Give touch targets at least 44 to 48px, and when an icon is small, extend its hit area with invisible padding. On devices with a notch or a home bar, keep buttons inside the safe area so that swiping up from the home bar never presses one by accident. Every overlay in First Run respects those safe areas.
Select First, Then Confirm
A mouse click lands where you aim it. On a phone, a finger brushing an option while scrolling is common. If a stray tap submits an answer to a judgment question, the player walks away feeling cheated instead of learning why the answer was wrong.
On touch screens, tapping an option in First Run only selects it. The answer is submitted with the Lock in this answer button below. That is one extra tap, but for a decision that cannot be undone, that much friction is appropriate. Actions that can be undone, like advancing dialogue or walking, still happen in one step.
The rule is simple. Irreversible decisions take two steps; reversible actions take one.
Use the Full Screen Height
Modern phones are tall. Drop in a map designed for a near-square frame and you get empty bands above and below, while the visible slice of the campus stays small.
On tall screens, First Run stretches the map vertically and shows up to 11 tiles across and 15 tiles down. The more of the campus fits on one screen, the less often anyone has to open the full map. Quest markers (! and ✓) and NPC name tags are drawn on the map, so even on a small screen you can tell who has something for you without walking over. When you need the overall layout, the map button in the top-right corner of the play area shows the entire campus.
Write for a Small Screen
Mobile onboarding more often fails on text than on controls. A situation written for a desktop takes two or three scrolls on a phone, and by the end the reader has forgotten how it started.
- Keep situation cards to five sentences or fewer. Timing, actor, event, and one constraint are enough.
- Put exactly one decision point in each quest. With two, it is easy to lose track of what is being asked on a small screen.
- Keep options to one or two lines. Long options force the reader to scroll up and down to compare all four.
- End feedback with two or three sentences of reasoning and one key learning point.
- Move long background material out of the quest, into a chapter card or a separate document.
Portrait First, Landscape as a Fallback
The natural way to hold a phone is upright. First Run is designed around portrait and treats landscape as a fallback. In portrait, the controls get their own space below the map; on short landscape screens, they float over the map to keep the play area as large as possible. Rotating is allowed, but no action exists only in landscape.
What Still Belongs on a Desktop
Not every part of onboarding needs to move to a phone. Some tasks lose more than they gain when forced onto a small screen.
- Code-heavy review tasks. Reading dozens of lines and finding the place to change them needs a wide screen and a keyboard. Keep quests to a few lines of code and do real code review practice at a desk.
- Long reports and deliverables. Practicing a weekly report or an impact analysis does not suit a phone.
- Work that compares several documents. Anything that needs windows side by side belongs on a desktop.
- Conversations about the result report. When a manager and a new hire look at it together, a larger screen works better.
Practice judgment on the phone and deliverables on the desktop, and neither side is stretched.
Mobile Onboarding Checklist
- Can one unit be finished within five minutes?
- Is progress saved automatically and restored on return?
- Is the next action obvious when someone comes back?
- Are frequently used controls in the lower part of the screen?
- Do you use bottom sheets instead of centered popups?
- Are touch targets at least 44 to 48px?
- Do buttons stay inside the safe area, clear of the notch and home bar?
- Do irreversible decisions use select, then confirm?
- Is each situation card five sentences or fewer, with one decision point?
- Does every action work in portrait?
- Have you decided which tasks stay on the desktop?
The goal of mobile onboarding is not to squeeze desktop content onto a small screen. It is to make sure five spare minutes are enough to finish one decision and close the tab. Once that unit is set, most other design choices follow from protecting it.
Try workplace scenarios as onboarding quests
Open First Run in your phone browser and finish one quest in five minutes. Play the Onboarding