App Development
How an app is designed before it is built: user interface, wireframes, the development cycle, and testing with real people.
Designing before building
The temptation is to start building immediately. Almost every failed project starts that way.
The development cycle
- Analysis. Who is this for, what problem does it solve, what must it do?
- Design. Plan the screens, the flow between them and the data it needs.
- Implementation. Build it.
- Testing. Check it works, including when things go wrong.
- Evaluation. Does it actually solve the original problem?
- Maintenance. Fix problems and add features.
This cycle repeats. Real apps go round it many times, which is why apps update constantly.
Requirements
Write down what the app must do, as specific testable statements:
- The user can add a task with a title and a due date
- The user can mark a task as complete
- Completed tasks move to a separate list
- Data is saved so it is still there when the app reopens
"Make it good" is not a requirement. "The user can add a task in two taps" is.
Wireframes
A wireframe is a rough sketch of a screen showing where things go, without colours or fonts. It is deliberately ugly, so that discussion stays on layout and flow rather than on whether the blue is right.
A navigation diagram shows how screens connect: which buttons lead where.
Step 1 of 6 Analysis: who is it for, what must it do
User interface design
An interface succeeds when the user does not have to think about it.
Principles
- Consistency. The same action looks and behaves the same everywhere. The back button is always in the same place.
- Feedback. Every action produces a visible response, so the user knows it worked.
- Clarity. Buttons say what they do. "Save changes" beats "OK".
- Forgiveness. Mistakes can be undone. Destructive actions ask for confirmation.
- Simplicity. Fewer options is usually better. Every extra button is another decision for the user.
Accessibility
- Large enough tap targets for people with limited dexterity
- Strong colour contrast, and never colour alone to convey meaning
- Text that works with the phone's larger font settings
- Labels on every control so a screen reader can describe it
- Works with the device turned either way
Knowing your audience
An app for young children needs large simple controls, few words and instant feedback. An app for professionals can assume expertise and prioritise speed and density of information. Designing one as if it were the other fails both.
Give it to someone who has never seen it, say nothing, and watch. Wherever they hesitate is a design problem, not a user problem.
- Consistency: the same action looks and behaves the same everywhere.
- Accessibility: large tap targets and strong colour contrast.
- Clarity: buttons say what they do, so Next question beats OK.
- Simplicity: fewer options, one thing at a time.
- Feedback: every action gets a visible response.
- Forgiveness: mistakes can be undone.
Testing and evaluation
What to test
- Functionality. Does every feature do what the requirement said?
- Usability. Can a real person complete the task without help?
- Compatibility. Does it work on different screen sizes and devices?
- Robustness. What happens with no internet, an empty list, or silly input?
Test data
- Normal, a typical value that should be accepted
- Boundary, right at the edge of what is allowed
- Erroneous, the wrong type entirely, which should be rejected politely
A test plan
| Test | Data | Type | Expected result | Actual result |
|---|---|---|---|---|
| 1 | Task title "Maths" | Normal | Task added | Task added |
| 2 | Empty title | Erroneous | Message asking for a title | App crashed |
| 3 | 200 character title | Boundary | Accepted or truncated cleanly | Text overflowed the box |
Tests 2 and 3 are the useful ones. A test plan that only contains things you know will work is a waste of time.
Evaluating
Go back to your original requirements and check them one at a time. Then be honest:
- Which requirements are fully met, partly met or not met?
- What did users struggle with?
- What would you do differently?
- What would you add next?
You built it, so you know where everything is. Watch someone else use it and count the number of times they hesitate.
- Test data for an age from 13 to 19, on a number line.
- Normal data is typical and should be accepted.
- Boundary data sits on and just outside each edge, because that is where mistakes hide.
- A test plan records expected against actual. A failed test shows what to fix.
Key terms you must be able to define
- Requirement
- A specific, testable statement of something the app must do.
- Wireframe
- A rough sketch of a screen layout without colours or styling.
- Navigation diagram
- A diagram showing how the screens of an app connect to each other.
- User interface
- The part of the app the user sees and interacts with.
- Usability
- How easily a real user can achieve what they came to do.
- Accessibility
- Designing so the app can be used by everyone, including people with disabilities.
- Iterative development
- Repeatedly designing, building, testing and improving.
- Test plan
- A table of planned tests with test data, its type, and the expected result.
- Evaluation
- Judging honestly whether the finished product meets its original requirements.
Flashcards
Say the definition out loud before you flip the card. Retrieving it from memory is what builds recall, reading it again is not.
Reach the top grade on this topic
The top level here is about evidence and honesty.
Write testable requirements. A requirement you cannot tick off is not a requirement. "The user can add a task in two taps" can be tested. "It is easy to use" cannot.
Test the failure cases. A test plan full of things that work proves nothing. The value is in the tests that break it.
Evaluate honestly. An evaluation that says everything went perfectly scores badly, because it shows you have not looked hard. Saying "three of my five testers could not find the delete button, so I would move it into the task itself" shows real understanding.
Justify design choices against the audience. Large buttons because the users are young children, not because you like large buttons.
- Write five specific testable requirements for an app
- Draw wireframes for three screens and a navigation diagram linking them
- Produce a test plan including boundary and erroneous data with expected results
- Write an honest evaluation against your original requirements
Mistakes that cost marks here
- Starting to build before writing down what the app has to do.
- Writing requirements that cannot be tested.
- Only testing things that work.
- Evaluating by saying everything went well.
- Designing the interface for yourself rather than for the actual audience.
The average app is deleted within three days of being installed. Almost always the reason is not a bug, it is that the user could not work out what to do in the first thirty seconds.
Knowledge check
Exam-style questions
Five written questions in the style of the real paper. Write a full answer, then let the marker check it against the mark scheme.
- LA rough sketch of a screen layout without styling
- LIt allows the layout and flow to be planned and discussed early
- LChanges are far quicker and cheaper to make on a sketch than in finished code
A wireframe is a rough sketch of a screen showing where each element will go, drawn deliberately without colours, fonts or images. It is produced before building so that the layout and the flow between screens can be planned and discussed while everything is still easy to change. Redrawing a sketch takes a minute, whereas rebuilding a finished screen can take hours, so problems with the design are far cheaper to find at this stage. Keeping wireframes plain also helps discussion stay on whether the screen works, rather than on whether the colours are right.
- LFirst requirement about adding homework with details
- LSecond requirement about viewing or sorting tasks
- LThird requirement about marking complete or saving data
First, the user can add a homework task by entering a subject, a description and a due date. Second, the app displays all outstanding homework sorted by due date, with the nearest deadline first. Third, the user can mark a task as complete, after which it is removed from the main list, and all data is saved so that it is still present when the app is closed and reopened. Each of these is specific enough that you can test it and say clearly whether it has been achieved.
- LConsistency, so the same action works the same way throughout
- LWhich means the user only has to learn the app once
- LFeedback, so every action produces a visible response
- LSo the user knows their action worked and does not repeat it
The first principle is consistency. The same action should look and behave the same way everywhere in the app, so a back button always appears in the same position and a save button always looks the same. This means the user only has to learn the interface once rather than working out each screen from scratch, and they can predict what will happen before they tap. The second principle is feedback. Every action the user takes should produce a visible response, whether that is a button changing appearance when pressed, a confirmation message after saving, or a loading indicator during a delay. Without feedback the user cannot tell whether their tap registered, so they tap again, which often causes duplicate entries or leaves them stuck and frustrated.
- LTest with normal data such as a typical task title
- LTest with boundary data at the limits of what is allowed
- LTest with erroneous data such as an empty entry or wrong type
- LState an expected result for each test
- LTest usability by watching a real user complete a task
- LTest robustness, such as behaviour with an empty list or no internet
I would begin with functional testing against each requirement, using three kinds of test data. Normal data would be a typical task such as the title Maths homework with a due date next week, and the expected result is that it is added and appears in the list. Boundary data would test the edges of what is allowed, for example a title of exactly the maximum length and one character longer, where the expected result is that the first is accepted cleanly and the second is either rejected with a message or truncated without breaking the layout. Erroneous data would be an empty title or letters typed into the date field, where the expected result is a clear message asking the user to correct it rather than the app crashing. Every test needs its expected result recorded in advance, because without that there is nothing to compare the actual behaviour against. Beyond functionality, I would test robustness by trying the app with an empty task list, with a very large number of tasks and with no internet connection, since these are situations that break real apps. Finally I would test usability by giving the app to someone who has never seen it, asking them to add and complete a task, and watching without helping. Every point where they hesitate is a design fault, and this is something the developer can never find on their own because they already know where everything is.
- LYoung children need large, simple controls
- LBecause they have less developed reading and fine motor skills
- LProfessionals can be given denser information and more options
- LBecause they are experienced and value speed and efficiency
An app for young children needs large tap targets, very few controls on each screen and instant obvious feedback, because young children have less developed fine motor control and may struggle to hit small buttons accurately. They may also read slowly or not at all, so meaning has to be carried by pictures, colour and sound rather than by text, and there should be very little that can go wrong because they will not read an error message. An app for adult professionals is the opposite. Those users will use it every day, so they value speed and efficiency far more than simplicity, and they can be given dense information, many options at once, keyboard shortcuts and advanced settings that would overwhelm a child. Designing either one as if it were the other fails both audiences: children get lost in an interface built for experts, and professionals get frustrated by an interface that takes five taps to do something that should take one.