Mobile app interface design in Ottawa

Apps built for a Government of Canada department start from a different place than a consumer product. Much of the look is settled before the first sketch. The Canada.ca design system defines the colours, the type, the page header and footer, and how buttons, alerts and forms behave. Departments are expected to follow it. The design room lies elsewhere.

That room is still large. The system describes components and patterns, and many of them were written for web pages rather than for a phone. A designer has to translate them. A tab bar, a bottom sheet or a swipe action has no exact twin in the web guidance, so each one needs a short written rationale that ties it back to an approved pattern. Reviewers read those notes. Without them, every unfamiliar control turns into a meeting.

The Web Experience Toolkit matters for the same reason. It is the open source front end framework that many Government of Canada sites are built on, and it carries tested behaviour for menus, tables, form validation and accessibility. When an app also has a web companion, or opens web pages inside a view, those pages usually run on the toolkit. The app should not look like a stranger next to them. Matching spacing, focus styles and error messages across the two saves a person from learning the service twice.

Official language parity is the rule that shapes the most screens. English and French versions must be equal in quality, published at the same time and equally complete. A French screen with a truncated button, an older help text or a missing feature is a defect, and reviewers will treat it as one. Plan for it from the wireframe. Every layout gets drawn in both languages, and the longer string decides the width.

The language toggle deserves its own design attention. On Canada.ca it sits in a fixed place and leads to the equivalent page in the other language. An app should behave the same way. Switching in the middle of a task keeps the person on the same step, with the data already entered. Sending someone back to the home screen after a language change is a common failure. Test it on every flow.

Plain language is the third pillar. The Canada.ca content guidance asks for short sentences, common words, active voice and the most important point first. In an app, that turns into concrete rules for microcopy. Button labels name the action. Error messages say what happened and what to do next. Legal wording goes behind a link, with a plain summary on the screen itself.

Writers and designers need to work side by side here. A screen that looks clean with placeholder text can fall apart once the real, plain wording arrives. Plain sentences often run a little longer than jargon. Leave space for them.

Procurement adds one more habit. Government projects are reviewed, audited and handed between teams. Keep a decision log that links each screen to the design system page it follows, and to the content rule that shaped its wording. The next supplier will be grateful. So will the accessibility reviewer.

Most people hold a phone in one hand and tap with the thumb of that same hand. That plain fact decides more about a layout than any grid. The thumb sweeps an arc from the lower corner of the screen. Inside that arc, taps are quick and accurate. Outside it, the person has to shift the grip, reach over with the other hand or give up.

Screens have grown taller, and the arc has not. The top corners of a large phone are the hardest places to hit. Yet many apps still put the main action there, because a desktop habit says important things belong at the top. On a phone, the top is for reading. The bottom is for doing.

Start the layout from the primary action. Ask what the person comes to this screen to do, then place that control in the lower half, within easy reach of either thumb. A checkout button, a send button, a record button. Secondary actions can sit higher. Destructive ones, such as delete, can sit deliberately outside the natural sweep so they are not hit by accident.

Tab bars at the bottom work for this reason. So do bottom sheets, which slide a set of options up to where the hand already rests. A floating action button near the lower edge follows the same logic. Menus that drop down from a top corner fight it.

Handedness matters less than teams expect. Designing for the centre of the lower half serves left and right handed people alike. Mirroring a whole layout for left handed users is rarely worth the testing cost. A setting that moves one key control can be.

Target size is the other half of reach. A tap target that is too small demands precision the thumb does not have, especially at the far edge of its arc. Both major platforms publish minimum sizes for touch targets, and those numbers are a floor rather than a goal. Spacing between targets matters as much as their size. Two icons packed tightly will be confused.

Some patterns help with the hard zones. Pulling content down so it lands lower, a back swipe from the screen edge, a long press that opens options next to the finger. Each of these needs a visible alternative, because plenty of people never discover them.

Test reach with real hands. Put a clickable prototype on a large phone and a small one, and watch people use it while standing, carrying a bag or holding a coffee. Note every change of grip. Each one is a small cost, and those costs pile up over a session.

Reach also changes with context. A courier may use the app in gloves. A parent may hold a child in the other arm. If the audience includes people like that, reach becomes the main design constraint, and the layout should be drawn around it from the very first sketch.

The app icon is the smallest piece of design in the project and the one people see most often. It appears in the store listing, on the home screen, in search results, in notifications and in the system settings list. Some of those places show it smaller than a fingernail. It has to hold up in every one of them.

A brand logo is rarely a good icon as it stands. Logos are drawn for letterheads and signs, often wide, often with fine lines or a full wordmark. The icon canvas is a small square, and the operating system rounds its corners for you. A wordmark shrinks into grey noise. The usual answer is to take one element of the identity, a symbol, a letter or a shape, and redraw it for the square.

Simplicity is the working rule. One clear shape, a strong silhouette and a short list of colours. Details that look charming at full size vanish at the smallest sizes. Check the design at every required size early, directly on a device, before anyone falls in love with it.

Context is the next test. Place the icon on a home screen beside other popular apps, over light and dark wallpapers. Does it stand out, or does it melt into a row of blue squares? Apps in one category often share colours and motifs. Borrowing them makes an icon look familiar, and invisible.

Platforms add their own demands. One platform asks for a single square image and applies its own mask. The other uses adaptive icons with separate foreground and background layers, which launchers can mask into different shapes and animate slightly. Recent system versions also offer tinted or themed icons, where the owner of the phone picks one colour for the whole home screen. An icon that depends on colour alone loses its meaning there. Supply a monochrome layer that still reads.

Keep text out of the icon. The app name already sits under it. Words inside the square repeat that name at an unreadable size and make translation harder.

Treat the icon as a product asset that can change. Store consoles let teams test icon variants against each other on the listing page, so a shift in colour or shape can be judged by real behaviour rather than opinion. Seasonal versions are possible too, though frequent swaps teach people nothing. Keep the source files layered and documented, so a later update never starts from a flattened image.