Salesforce Mobile and User Experience Intern

Sign up for a free Developer Edition org and build a data model with at least three objects, twenty fields across them, and thirty records, configured the way a desktop-focused admin would without mobile consideration.

Install the free Salesforce mobile app on your own phone and log in to your org.

Now do real work on it.

Define three tasks a field user would perform, such as finding a customer and logging a visit, creating a record while standing somewhere, or checking today's list.

Perform each on the phone and time it.

Document the failures precisely.

For each task, record every point you had to scroll excessively, pinch to read, tap something too small, wait, or give up and reach for a laptop.

Count the taps each task required, since tap count is the clearest measure of mobile friction.

Compare with desktop.

Perform the same tasks on a computer, time them, and record the difference.

Write what specifically causes the gap.

Assess the layouts as delivered.

Look at what appears at the top of a record on the phone and whether it is what a field user needs first, which it usually is not because desktop layouts put identifiers before useful information.

Then prioritise.

From every problem you found, rank the five worst by how much they hurt a real user, and write why you ordered them that way.

Finally, predict the fixes you expect to help most, which you will check later.

Submit the baseline org configuration, the three task definitions, the timed mobile walkthrough with friction log and tap counts, the desktop comparison, the layout assessment, the ranked problems, and your predictions.

Fix the problems you found, measuring rather than assuming improvement.

Start with compact layouts, which determine what a user sees first on mobile.

For each object, choose the four fields a field user needs immediately, configure the compact layout, and justify each field by the decision it supports.

Reorder the page layouts for mobile reality.

Move the fields a mobile user needs to the top, collapse or remove what only matters on desktop, and group related fields so scanning is possible.

Record what you demoted and why.

Use dynamic forms or dynamic layout rules if available to show fields only when relevant, so a user is not scrolling past empty fields that do not apply.

Capture the before and after.

Build a Lightning record page configured for the mobile form factor, choosing which components appear and in what order, and recording how the mobile view differs from desktop.

Add quick actions for the two or three things a field user does most, so a common update takes one tap rather than opening and editing a record.

Now measure again.

Repeat your three timed tasks on the phone, recording time and tap count, and compare against your baseline.

State the improvement per task honestly, including anything that got worse.

Check your predictions.

Compare what actually helped against what you expected to help, and write what that teaches about mobile design.

Finally, note the problem you could not fix through configuration.

Submit the compact layouts with field justifications, the reordered layouts, dynamic form evidence, the Lightning page configuration, the quick actions, the after measurements against baseline, the prediction review, and the unfixable note.

Field users are often on weak connections, and an app assuming good signal fails exactly when it is needed.

Configure the mobile navigation.

Set up the navigation menu so the items a field user needs are present and ordered by frequency of use, and remove what only matters on desktop.

Justify the order.

Build the list views a mobile user needs, filtered to show their own relevant records rather than everything, with the three or four columns that are useful on a narrow screen.

Test each on the phone.

Set up global actions so a user can create the records they most often create from anywhere in the app, and test each.

Now test connectivity honestly.

Use the phone with the connection deliberately degraded, by switching off wifi in a weak signal area or using airplane mode, and establish what works, what fails, and what fails badly by appearing to work and then losing data.

Record each case.

Research the offline capability available, write what is genuinely supported, and test one offline-capable action end to end including what happens when the connection returns.

Then handle the failure case.

Write what a field user should do when the app will not load, and whether your configuration gives them any fallback.

Test on a second device if you can access one, such as a different phone or screen size, and record what differed.

Finally, write the honest statement of what this org can and cannot support for a user in the field.

Submit the navigation configuration with ordering reasoning, the mobile list views, global actions, the connectivity test log, the offline research and test, the failure guidance, the second device findings, and the honest capability statement.

Your own fluency with your own org hides most usability problems, so this task brings in other people.

Plan the test.

Define three realistic tasks, write the instructions you will give, decide what you will measure covering completion, time, taps, and errors, and write the rule that you will not help, because helping destroys the data you came for.

Run it with at least three people unfamiliar with Salesforce, using your phone and your org.

For each person and task, record whether they completed it, how long it took, where they hesitated, what they tapped that was wrong, and what they said while confused.

The wrong taps are the most useful finding.

Analyse across participants.

Identify the problems more than one person hit, which are design faults rather than individual confusion, and separate them from one-off difficulties.

Fix the shared problems.

Make at least four changes driven by what you observed rather than what you assumed, and record the reasoning for each.

Retest with one new person to confirm the fixes worked and nothing new broke.

Now write the guidelines.

Produce a one page set of mobile design rules for this org, derived from what you observed rather than from general advice, covering how many fields belong on a mobile layout, what belongs in a compact layout, when a quick action is justified, and what to test before releasing a layout change.

Then write the adoption note: what would cause field users to abandon this app, and what the business should do in the first month.

Finally, state the assumption of your own that testing proved wrong.

Submit the test plan, per-participant observations, the cross-participant analysis, the four fixes with reasoning, the retest, the design guidelines, the adoption note, and the disproved assumption.