Mobile-First for a Low-Bandwidth Benefits Portal
A state benefits-eligibility portal lets residents check whether they qualify for food and heating assistance, then start an application. Analytics show 78% of sessions are on mobile, a large share on Android phones costing under $150 on 3G connections, with viewport widths from 360px to 1440px. The current design was built desktop-first: a four-column form, hover-only dropdown menus, and 12px body text. The portal must work in English and Spanish, and the state's accessibility policy requires 44×44px touch targets and WCAG 2.1 AA. The team is rebuilding in Adobe XD with responsive resize, and has one designer, one researcher, two engineers, and a 10-week deadline. Three stakeholders want three different navigation patterns: a bottom tab bar, a hamburger menu, and everything visible on the page.
1. What is your breakpoint strategy, and what do you design first? Explain how you would use Adobe XD's responsive tools.
Read the worked answer
Design at the constraint, not at the desk. The median user is on a 360px-wide, low-cost Android device over 3G, so 360px is the primary artboard; 1440px is a derivative. A desktop-first design shrunk down produces tap targets that are too small, text that is too small, and four-column layouts that collapse into unreadable stacks.
Suggested breakpoints: 360 (primary), 768 (tablet and large phone landscape), 1024, 1280–1440 (desktop). Rather than designing four unrelated screens, design the mobile layout and let responsive resize plus stacking carry content up: a vertical card stack becomes a two-column grid at 768 and a three-column grid at 1024, with max-width constraints so text does not run to 1400px.
In XD: use responsive resize with pinned elements and padding for headers and cards; set the mobile artboard's content to stack and re-flow rather than stretch; create a small set of components with size variants so the same button exists at each breakpoint instead of being redrawn. Text minimum 16px body on mobile - 12px fails both readability and the AA bar in practice. Check every interactive element against the 44×44px minimum, which is a real density constraint on a 360px screen: it limits how many controls can sit in a row, which argues for a single-column layout.
Finally, test on a real low-end device with throttled 3G. Emulators on a fast laptop hide the two things that matter: latency and tap precision.
2. Three stakeholders want a bottom tab bar, a hamburger menu, and everything visible. How do you decide?
Read the worked answer
Refuse to settle it by seniority, and reframe it as a findability question with evidence. Navigation choice depends on three things: how many top-level destinations there are, how often each is used, and how much screen space is available.
- Hamburger menu: conserves space but hides the information architecture behind a tap. For a low-digital-literacy audience it is a documented discoverability problem - people do not know the menu exists, and menu labels are abstract. Weak default here.
- Bottom tab bar: thumb-reachable, visible, and good for four or five destinations. It breaks down beyond five, and should not be used for actions ("Apply") - tabs switch locations, buttons do things.
- Everything visible: strongest for discoverability and the right instinct for a short list of tasks, but on a 360px screen a long list pushes content below the fold, and 44px targets make an already long page longer.
A defensible resolution: list the top tasks first - probably check eligibility, apply or continue a case, check status, get help. If that is four or five, a visible list or a small tab set is viable and beats the hamburger. Then test it: two variants, five participants each, with a task-based findability test ("find out whether you qualify for heating assistance"). A tree test can validate the labels cheaply before any screen is drawn. Ten participants resolve an argument that three meetings will not.
3. How would you design the application form for small screens, and how should validation work?
Read the worked answer
Structure. Break the form by topic into steps - household, income, housing costs, review - rather than one long scroll. Steps give people a sense of progress on a small screen and break a daunting task into finishable units. Show progress ("Step 2 of 5"), name each step, and allow backward navigation without losing data. Provide save-and-resume prominently: people on 3G, on shared or borrowed devices, will be interrupted, and losing an application is a reason never to return.
Fields. Labels above inputs, never placeholder-only, because placeholders vanish on focus and are inaccessible. Large inputs, correct keyboards (numeric for income), autofill support, and no timeouts. Keep the number of fields visible at once small.
Validation. Validate inline on blur, not on every keystroke; keep errors next to the field; and provide an error summary at the top of the step with links to each problem. Write errors in plain language that says what to do, not just what is wrong. Never signal an error by colour alone - use an icon and text as well, since colour-only errors fail WCAG and are invisible to some users.
Language and privacy. Spanish must be a real translation, not machine output, and longer Spanish strings will break tight layouts - test them. On shared devices, consider what is shown on resume and whether a confirmation email is safer than an on-screen summary.
Test with residents, including people with low digital confidence, not with staff. The portal's hardest test case is someone applying once, nervously, on a borrowed phone.