Mobile Applications

An app is worth building only when one group of people has one repeated problem that a simple tool cannot solve. This module teaches you to find that problem by listening, not by guessing. You finish with a single written need statement that guides every later choice.

• Interview five people from your chosen group for 15 minutes each, and ask about the last time the problem happened rather than about ideas for an app.
• Write the need as one sentence in the form: user, need, reason, for example a parent needs to log feeds because two adults share the task.
• Count how many of the five people had the problem in the last week, since fewer than three out of five means the need is weak.
• Check whether a shared note, a spreadsheet or a message group already solves it, and only continue if the app adds something clearly better.
• A common mistake is to ask people if they would use an app, because people say yes to be polite; ask what they do today instead.

Activity. Interview five people from your target group, record each answer in a table, and write one need statement of no more than 25 words.

Standard to meet. Complete a table of five dated interviews, write a need statement that names a user, a need and a reason, and show that at least three of five people share the problem.

Changing a paper sketch costs minutes, while changing finished code costs days. In this module you draw the screens and the path through them before you build anything. You then test the paper with real people to find confusion early.

• Sketch five to eight screens on paper, one per card, and draw only boxes, labels and buttons so that nobody argues about colours.
• Draw one arrow path for the main task and count the taps, aiming for three taps or fewer from opening the app to finishing the task.
• Ask three people to use the paper by pointing at buttons, and swap the cards by hand when they tap, without explaining anything.
• Write down every place a tester hesitates for more than three seconds, because each hesitation marks a fault in the design.
• A common mistake is to add extra screens such as settings and profiles before the main task works, so cut every screen that the main task does not need.

Activity. Draw five to eight paper screens and the main task path, test them with three people, and write a list of every hesitation you saw.

Standard to meet. Complete the main task in three taps or fewer, have three people test it, and list each hesitation with the screen where it happened.

The first version should do one job and run on a real phone. Building small keeps you from getting lost and gives you something to test early. You will work in short versions and note what changed each time.

• Choose a free app builder or a simple code framework that you can finish with, and avoid learning a second tool halfway through.
• Build only the main task from your flow, for example save an entry and show a list of entries, and write every other idea on a later list.
• Run the app on a real phone after every small change, because an emulator on a computer hides problems with touch and screen size.
• Give each working state a version number such as 0.1, 0.2 and 0.3, and write one line saying what changed and what broke.
• A common mistake is to build for weeks without testing, so set a rule that the app must run on the phone at least once every three working hours.

Activity. Build and run the main task on a phone, and keep a version note with a date, a version number and one line of change for each build.

Standard to meet. Run the main task from start to finish on a real phone, and write at least three version notes that show what changed.

Any app that stores information about people carries a duty to protect it. The safest data is data you never collect. In this module you decide what to store, write it in plain words and plan how a user can have it deleted.

• List every piece of data the app stores and cross out each item that the main task does not need, such as full name, birth date or location.
• Write a one-page note in plain words saying what is stored, why, where it is kept, who can see it and how a user asks for deletion.
• Never store passwords as plain text and prefer a sign-in method that a trusted service handles, because a leak of readable passwords harms users on other sites too.
• Ask for permission on the phone only at the moment the feature needs it, and make the app still work if the user says no.
• Check with your local authority which data-protection rules apply, and have an adviser read your note before you share the app with outside testers.

Activity. Write a one-page privacy note that lists each data field, the reason for it, where it is stored and how a user can delete it.

Standard to meet. Write a note that lists every field with a reason, names a deletion route, and contains no data that the main task does not need.

People use apps in bright sun, with tired eyes, with one hand, or with a screen reader. Accessible design makes the app easier for all of them. You will check your screens against a short list and fix what fails.

• Use text at least 16 points in size and test that every screen is readable without zooming in.
• Keep a colour contrast ratio of at least 4.5 to 1 between normal text and its background, and check it with a free contrast checker.
• Make every tap target at least 44 by 44 points, about 7 millimetres, so a thumb can hit it without touching its neighbour.
• Never show an error or status with colour alone, and add words or a symbol, because about 1 in 12 men cannot tell some colours apart.
• Give every button and image a text label that a screen reader can speak, and test the main task once with the screen reader turned on.

Activity. Check every screen against a six-item list covering text size, contrast, tap size, colour use, labels and screen reader, and fix each failed item.

Standard to meet. Test all screens against the six checks so that each passes or has a dated fix, and complete the main task once with a screen reader.

Watching people use your app shows faults that you can no longer see yourself. The skill is to give a task, stay quiet and write down what happens. You then fix the faults that affect the most people.

• Recruit five testers who match your user group, because five testers usually reveal most of the biggest faults.
• Give each tester one task in a sentence, such as log a feed and find today's list, and do not explain how or point at anything.
• Write down the screen, the time and the words of the tester each time they stop, tap the wrong thing or ask a question.
• Count how many testers hit each fault and sort the list so that faults hitting three or more testers are fixed first.
• Fix the top three faults, then test again with the same task to prove the fix worked, rather than assuming it did.

Activity. Test the app with five users on one task, produce a fault log with counts, fix the top three faults and re-test them.

Standard to meet. List each fault in the fault log with a count out of five, fix the three most common faults, and re-test to show fewer testers hitting them.

A small release to a trusted group tells you whether people really use the app. Numbers such as daily users and task completions are more honest than opinions. You will collect a few of them for 14 days.

• Share the app with a small trusted group of 10 to 15 people and tell them it is a trial, so they expect rough edges.
• Decide before release which three numbers you will count, for example daily active users, share of people who return after a week, and share of attempts that finish the main task.
• Count from a simple log or a spreadsheet each day, and write the date, the number of users and the number of completed tasks.
• Ask each user one open question each week, such as what almost made you stop, and record the answer in their own words.
• A common mistake is to count downloads or installs only, which says nothing about use, so always count returns and completions.

Activity. Run a 14-day release to a small group, keep a daily count of the three chosen numbers, and write one page of what the numbers show.

Standard to meet. Record all 14 days, calculate the three numbers correctly, and write a page that names one thing the numbers prove and one they do not.

After a trial you must decide whether to improve, pause or stop. A fair decision uses numbers and compares impact with effort. You will rank the faults and write a short plan with dates.

• List every fault and request from the trial, and give each an impact score from 1 to 3 times the number of users it affected.
• Estimate the effort for each item in days, and divide impact by effort to get a value per day of work.
• Choose the top two or three items that fit the time you really have, and leave the rest on a later list instead of promising everything.
• Write three lessons in plain words, one about the user need, one about the build and one about the testing.
• Set a review date and one number that will tell you whether the next version worked.

Activity. Rank at least five faults by impact divided by effort, then write a next-version plan with dates, one target number and three lessons.

Standard to meet. Show the sums in the ranking, write a plan with dates and a target number, and point each of the three lessons to evidence from the trial.