Mobile Application Building

An app is a tool for a person with a problem. Start with the person.

• Interview 5 possible users: what is hard, how do you cope now, what would success look like?
• Write the problem in one sentence and one measurable goal.
• List the 3 things the first version must do and 3 it will not do.
• Check if a simple form or message already solves it.

Activity. Interview five users and write the one-page brief.

Standard to meet. List the problem, goal, must-do and will-not-do items.

Paper first. Draw the screens a user taps through before you write code.

• Make a flow: start, task steps, finish, error.
• Keep one main action per screen; large tap targets.
• Use clear words; test labels with a user.
• Plan for small phones, bright light and slow connections.

Activity. Draw the flow and test the paper version with two users.

Standard to meet. Ask both users to complete the task on paper without help.

Apps store and change data. Decide what you store, in what shape, and who can see it.

• Make a table of items: field, type (text, number, date), required or not.
• Plan how data is saved on the phone and, if needed, on a server.
• Write the rules in plain sentences before code.
• Keep personal data to the minimum needed.

Activity. Write your data table and the rules.

Standard to meet. Give every field a reason, and write a deletion rule.

Build the smallest working version with a free tool or beginner-friendly framework.

• Build one screen at a time and test each.
• Use version saving so you can go back.
• Keep secrets (keys, passwords) out of the code.
• Write a short note for each feature: what it does, how to test it.

Activity. Reach a working prototype that completes the core task.

Standard to meet. Test that the core task works end to end on a real phone.

Testing finds what you cannot see. Test on real phones with real users.

• Write 10 test steps and expected results.
• Test on two phone sizes and one weak connection.
• Watch users without helping; note where they hesitate.
• Rank problems: blocks the task, annoys, cosmetic. Fix in that order.

Activity. Run the 10 test steps and a user test with five people.

Standard to meet. Rank the problems, then fix and retest the top three.

Trust is the product. Protect data and include everyone.

• Privacy note in plain words: what you collect, why, how long, how to delete.
• Use secure connections; never store passwords in plain text.
• Accessibility: readable text size, strong contrast, labels for buttons, works with larger fonts.
• Children: do not collect their data without proper guardian consent.

Activity. Complete a 12-point checklist for your app.

Standard to meet. Give every failure a fix and a retest date.

Release small. Give the app to 10 real users and listen.

• Prepare an install guide and a one-minute video or picture steps.
• Collect feedback with three questions: did it work, what was hard, would you use it again?
• Track crashes and complaints.
• Send a thank-you and a promise of what you will change.

Activity. Release and collect feedback from ten users.

Standard to meet. Reach ten users, and complete the feedback table.

After release, decide whether to grow, change or stop, and how the app could earn.

• Options: free for a service, paid app, subscription, sponsor, or a tool for your own business.
• Estimate costs: time, hosting, support.
• Write three lessons learned.
• Plan version two with dates.

Activity. Present at a review room; give two peers feedback.

Standard to meet. Plan has numbers and dates.

On the slide: L1 Basic · What an app does. Focus module: Find the problem and the user (Understand, 8 h). An app is a tool for a person with a problem. Start with the person. Key points: Interview 5 possible users: what is hard, how do you cope now, what would success look like? Write the problem in one sentence and one measurable goal. List the 3 things the first version must do and 3 it will not do. Check if a simple form or message already solves it.

Notes: Say what problem an app solves and for whom. Notes: use delivery riders who lose time finding addresses. Teach: open with the worked example. Five delivery riders say they lose time hunting for addresses. Goal: cut search time from 6 to 3 minutes. First version: save addresses, one-tap call, map link. Then set the activity: Interview five users and write the one-page brief. Mark against the standard: List the problem, goal, must-do and will-not-do items. Check at this level: Why interview users before designing? Model answer: To solve a real problem for a real person.

On the slide: L2 Awareness · Sketch screens. Focus module: Design screens and flow (Create, 14 h). Paper first. Draw the screens a user taps through before you write code. Key points: Make a flow: start, task steps, finish, error. Keep one main action per screen; large tap targets. Use clear words; test labels with a user. Plan for small phones, bright light and slow connections.

Notes: Draw a three-screen flow. Notes: list, add place and detail; check each button has one job. Teach: open with the worked example. A three-screen flow: List, Add place, Place detail with call and map buttons. Then set the activity: Draw the flow and test the paper version with two users. Mark against the standard: Ask both users to complete the task on paper without help.

On the slide: L3 Foundation · Data and logic. Focus module: Data and logic (Apply, 20 h). Apps store and change data. Decide what you store, in what shape, and who can see it. Key points: Make a table of items: field, type (text, number, date), required or not. Plan how data is saved on the phone and, if needed, on a server. Write the rules in plain sentences before code. Keep personal data to the minimum needed.

Notes: Describe the data an app stores. Notes: name, address, phone, notes and last used; learners write one rule. Teach: open with the worked example. Place table: name (text), address (text), phone (text), notes (text), last used (date). Rule: delete all data when the user taps 'Remove my data'. Then set the activity: Write your data table and the rules. Mark against the standard: Give every field a reason, and write a deletion rule. Check at this level: What does a data table list? Model answer: Fields, their types and whether each is required.

On the slide: L4 Practitioner · Build and test a prototype. Focus module: Build the prototype (Apply, 38 h). Build the smallest working version with a free tool or beginner-friendly framework. Key points: Build one screen at a time and test each. Use version saving so you can go back. Keep secrets (keys, passwords) out of the code. Write a short note for each feature: what it does, how to test it.

Notes: Build the prototype and test it with five users. Notes: 3 of 5 missed the Add button, so move and enlarge it. Teach: open with the worked example. Screen 1 lists places from saved data; screen 2 saves a new place; screen 3 shows detail and opens the phone dialler. Then set the activity: Reach a working prototype that completes the core task. Mark against the standard: Test that the core task works end to end on a real phone. Check at this level: Why keep secrets out of code? Model answer: Anyone who sees the code could misuse them.

On the slide: L5 Specialist · Security and access. Focus module: Security, privacy, accessibility (Evaluate, 16 h). Trust is the product. Protect data and include everyone. Key points: Privacy note in plain words: what you collect, why, how long, how to delete. Use secure connections; never store passwords in plain text. Accessibility: readable text size, strong contrast, labels for buttons, works with larger fonts. Children: do not collect their data without proper guardian consent.

Notes: Run a 12-point security, privacy and accessibility check. Notes: 11 pass and low contrast fails; fix and retest. Teach: open with the worked example. A checklist of 12 points: 11 pass, 1 fails (low contrast on grey text). Fix and retest. Then set the activity: Complete a 12-point checklist for your app. Mark against the standard: Give every failure a fix and a retest date. Check at this level: What belongs in a privacy note? Model answer: What is collected, why, how long, how to delete.

On the slide: L6 Advanced · Lead a release. Focus module: Release to ten users (Apply, 26 h). Release small. Give the app to 10 real users and listen. Key points: Prepare an install guide and a one-minute video or picture steps. Collect feedback with three questions: did it work, what was hard, would you use it again? Track crashes and complaints. Send a thank-you and a promise of what you will change.

Notes: Release to ten users and decide the next version. Notes: 8 of 10 completed the task; rank requests such as night mode. Teach: open with the worked example. 8 of 10 users completed the task. Two asked for night mode. Next version: night mode and offline lists. Then set the activity: Release and collect feedback from ten users. Mark against the standard: Reach ten users, and complete the feedback table. Check at this level: Why release to only ten users first? Model answer: To learn cheaply before scaling.

On the slide: L7 Super expert · Plan the app business. Focus module: Plan version two and the business (Evaluate, 8 h). After release, decide whether to grow, change or stop, and how the app could earn. Key points: Options: free for a service, paid app, subscription, sponsor, or a tool for your own business. Estimate costs: time, hosting, support. Write three lessons learned. Plan version two with dates.

Notes: Plan pricing, hosting and support. Notes: EUR 3 a month from 40 offices is EUR 120, which covers estimated hosting and support of EUR 120 a month; check the working. Teach: open with the worked example. Plan: free for riders, EUR 3 per month for each dispatch office; hosting and support cost about EUR 120 a month, so 40 offices x EUR 3 = EUR 120 cover them. Then set the activity: Present at a review room; give two peers feedback. Mark against the standard: Plan has numbers and dates. Check at this level: What should a version-two plan include? Model answer: Changes, dates and cost estimate.