F162 Step-by-Step Guide

Open a document and write the following clearly labelled sections. Number every requirement; you will reference these numbers throughout every later task.

• Client requirements: who commissioned this and what they need the system to do
• User requirements: who will use it and what they need from it
• Functional requirements: a numbered list (R1, R2…) of what the system must do
• Interface requirements: how the UI must look and behave (accessible, responsive, consistent icons)
• Non-functional requirements: performance, accessibility, compatibility constraints

For each functional and non-functional requirement, write a short explanation of how it directly shapes a specific design decision. Aim for one to two sentences per requirement minimum.

Cover every requirement from Step 1. This transforms a requirements list into a requirements analysis, which is the distinction between P and M here.

Produce a mind map, mood board, or spider diagram (hand-drawn or digital) showing at least two distinct design directions. Both ideas must be visually and conceptually different from each other.

• Label each idea clearly
• Include visual references and colour palette swatches for each direction
• Include rough layout sketches showing how screens might be structured
• Annotate what makes each idea appropriate for the scenario

Select one idea from Step 3 and develop it into a low-fidelity wireframe or annotated sketch. Show the main screens, navigation structure, and key UI elements.

• Annotate every major layout decision: explain why you made it
• Show the overall navigation structure (which screens link to which)
• Label key UI elements and describe what they do
• A clear annotated paper sketch is fully acceptable

Draw use case diagrams covering every user–system interaction in your OCR scenario. Non-standard symbols automatically lose this criterion: follow these rules exactly.

• Actors: stick figures, labelled with the user role (e.g. "Student", "Admin")
• Use cases: ovals, labelled with verb + noun (e.g. "Submit form", "View dashboard")
• System boundary: a rectangle enclosing all use cases (but not actors)
• Association lines: simple solid lines from actor to use case
• Add «include» or «extend» relationships where appropriate
• Every interaction described in the OCR scenario must appear in at least one use case

Draw a navigation map or wireflow showing how a user moves between every screen in your solution.

• Show all routes including error paths and back-navigation
• Label each transition arrow with the action that triggers it (e.g. "clicks Login button")
• Include every screen: no dead ends or orphaned screens
• Wireflows (low-fi wireframes with transition arrows) are more useful than bare flowcharts

For each key process in your scenario (e.g. user registration, form submission), create a flowchart showing every step, decision point, and outcome.

• Use standard flowchart shapes: rectangles for steps, diamonds for decisions, rounded rectangles for start/end
• Show both user actions and system responses
• Include both the happy path and error/failure paths
• Label every arrow leaving a decision diamond with the condition (Yes / No, or a specific value)

For each main task a user completes (e.g. "book an appointment"), create a step-by-step diagram showing only the user's perspective.

• Show what the user sees at each stage
• Show what they click, type, or select
• Show what feedback or confirmation they receive after each action
• These diagrams should read like a walkthrough, one action per step

Using Figma, Adobe XD, or equivalent, build a full high-fidelity interactive prototype.

• All main screens designed to high-fidelity standard, not wireframe quality
• Clickable navigation that matches your diagrams from Steps 6–8
• Export as a shareable link or screen recording for submission

For D2: error handling must be built into the prototype.

• Every form must have an invalid/error state with an informative, self-resolving message
• Confirmation dialogues for destructive actions (e.g. "Are you sure you want to delete?")
• Empty states where lists or search results could be empty
• Loading states where appropriate

Write 150–250 words explaining how your prototype suits the specific users in your OCR scenario.

• Reference the user characteristics defined in the scenario (age range, technical ability, accessibility needs)
• Explain which specific design decisions address each user characteristic
• Link back to your numbered requirements from Step 1 throughout
• Do not write generically: anchor every sentence to a named user characteristic or requirement number

Create a checklist or table using at least two audit methods. Suggested methods: Nielsen's 10 Heuristics, WCAG 2.1 accessibility audit, colour contrast checker.

• For each check: state what you checked, the result (pass / fail / partial), and any issues found
• Reference specific screens or interactions for each result
• Be honest: including fails and partials demonstrates rigour, not weakness

For M5: justify your choice of checks.

• Write a paragraph for each method explaining what it tests
• Explain why it is appropriate for your specific solution and users
• Example: "I used WCAG because my user group includes people with visual impairments, as stated in requirement R4."

Write 200–300 words. Reference at least all four of these principles, linking each to a specific screen or element in your prototype:

• Visual hierarchy: how size, weight, and positioning guide the eye through each screen
• Breadcrumbs / wayfinding cues: how users always know where they are within the system
• Consistent navigation placement: navigation appears in the same location across all screens
• Feedback on current location: active states, highlighted menu items, page titles

Avoid vague statements. Name the screen, describe the specific element, and explain the principle it demonstrates.

Cover at least four rules. For each rule: name it, explain what it means, and give a specific example of where it appears in your prototype.

• Strive for consistency
• Cater to universal usability
• Offer informative feedback
• Design dialogues to yield closure
• Prevent errors
• Permit easy reversal of actions
• Support internal locus of control
• Reduce short-term memory load

Write 300–400 words. You must cover all three named principles. For each, evaluate both strengths and weaknesses of your prototype:

• Cognitive load: does your design minimise what the user must think about or remember at once? Where might screens overload the user with too much information?
• Hick's Law: does your design reduce the number of choices shown at once? Are there screens where too many options appear simultaneously, slowing decision-making?
• Law of Proximity: are related elements grouped together visually? Are there cases where proximity is inconsistent or misleading?

Optionally, reference the Von Restorff effect (isolated elements are more memorable) or the serial position effect (first and last items in a list are best recalled) for additional depth.

Write 300–400 words. For each of the four standards below, state whether your prototype meets it and identify specifically where it falls short:

• Common UI layouts, icons, and labels: familiar conventions such as hamburger menu, magnifying glass for search, home icon, floppy disk for save. Does your UI follow these conventions or deviate from them?
• Cross-platform standards: does your design behave consistently across different device types and screen sizes?
• Standard interface widgets: do you use standard form controls, buttons, and dropdowns rather than confusing custom components?
• Standard protocols: platform-specific interaction conventions such as swipe gestures, back-button behaviour, long-press menus, pull-to-refresh.

Create a slide deck designed for the client in the OCR scenario, not your teacher. Pitch it at a non-technical audience.

• Professional visual design appropriate to the client's sector
• Structure: problem overview, your solution, key design decisions, prototype walkthrough, next steps
• Aim for 8–12 slides
• Include screenshots or screen recordings of your prototype
• Avoid jargon: explain technical decisions in plain terms the client would understand

Present to your teacher acting as the client. Accepted formats:

• Live in-person presentation
• Live remote presentation (must be recorded)
• Pre-recorded video with audio commentary

Your delivery must communicate not just what your solution is, but why each design decision was made. Walk through key screens and explain your reasoning out loud.

During your showcase, deliberately use at least three of the following techniques:

• Appropriate technical and non-technical language (adapted to your audience)
• Visual aids (slides, diagrams, live prototype demo)
• Structured delivery (clear introduction, main body, conclusion)
• Handling questions or objections
• Professional tone and pace throughout

Write 200–300 words covering:

• At least two strengths: what your prototype does well, linked to specific requirements from Step 1
• At least two weaknesses: where your prototype falls short of requirements or user needs

Be specific. Reference actual screens or interactions by name. Link every point to a requirement number (e.g. "The search function on the dashboard screen fully meets R5…"). Vague statements without requirement references will not satisfy this criterion.

For each weakness identified in Step 19, write a detailed discussion of how you would improve it. For each improvement include:

• A description of the specific change you would make
• An explanation of how that change better meets the relevant requirement
• Any trade-offs the improvement introduces (e.g. a change that improves accessibility but increases development complexity)

Write 400–500 words. This is the most commonly missed Distinction criterion. You must evaluate the tools and methods you used throughout Tasks 1–3, not the prototype itself. Cover each of these areas:

• Requirements specification: was it thorough? Did it capture everything needed? What would you do differently next time?
• Use case diagrams: were they useful? Did they reveal interactions you had not initially considered?
• Low-fidelity wireframes: did they save time in the long run, or did they lead to significant rework in the prototype?
• Navigation and process diagrams: did they accurately predict how the prototype would work in practice?
• Prototyping software: what were its strengths and limitations for this specific project?
• Audit / metrics checks: how effective were they at finding real usability issues? Would a different method have found more?