Application Design I - Task 3: Lo-Fi App Design Prototype

December 12, 2025

Application Design I - Task 3: Lo-Fi App Design Prototype

26/11/2025 - 03/12/2025 / Week 10 - Week 11

Aquela Zefanya Soares / 0374377

Application Design I / Bachelor of Design (Honours) in Creative Media / Taylor's University

LECTURES
INSTRUCTION
TASK
REFLECTIONS

LECTURES

Week 10

Hook, choices & navigation

Wayfinding

what you’re doing with the app / how you find your way
example: IKEA has a similar layout in every country, so people are familiar with the place, in IKEA the wayfinding is spread throughout the floor
label things properly
consistency is important
for users who know what they want, you allow them to skip through it (usability)

Digital Navigation

web navigation: global (high level, always there), local (one level or more below), contextual (changes depending on context and choices), faceted (filters and sorting), supplemental (extra help, just in case)
YouTube: has global and local navigation, basically anything that is below the global surface means it’s local, and it also has contextual information because the videos depend on users’ preferences
app navigation: global (the navigation bar), local (the quick menu), contextual (the promotions and products depending on users’ preferences), faceted, supplemental
search: special navigation (a site on its own), last resort (can't find what we look for), shortcut (already know what we look for), map (want to see all choices)

Navigation Best Practices

know where we are
where we can go
what will happen there
what we need to know first

Decision Making

alternatives, uncertainty, high-risk consequences, interpersonal issues, complexity
process: gather relevant information, identify and examine alternatives, choose among the alternatives, take action, review your decision and its impact
anchoring → guides the user to choices
the paradox of choice → too many features are not necessarily good, prioritize the need first
choice overload
simplify: introduce complexity by level
decision fatigue: humans have a finite amount of mental energy throughout the day, when mental depletion sets in, it’s hard to consider long-term impacts of decisions, decision fatigue sets in when we are tired and can’t process risks and rewards correctly → it’s important to make the decision easy

Hooks

habits stick
the hook model:

trigger: reminds users about your product, can be internal (emotion, feeling, memory) or external (reminder, email, ad)
action: initiated when the trigger is met with motivation and ability
reward: the action brings impact on the user, their environment, or their communities, it can be external (social standing or approval within a community) or internal (personal mastery of an ability or betterment of the self)
investment: the reward is cumulative or compounds towards a goal, time and effort invested feel worthwhile, and they create a positive outlook towards the product, reinforcing the loop

UX hooks
gamification
when to hook people? first time, returns, positive touchpoints

Week 11

Usability testing

definition: a structured observation of people trying to achieve a task with a specific product or service, it is made to identify usability issues

Why test?

user expectation: what they actually want
knowledge gaps: things you thought they knew
problems: when users do the unexpected
feedback: things to improve or change
ideas: things you didn’t think about

When and what to test?

as early as possible: when you have something testable, put it in the hands of users
as often as possible: get into the habit of testing or involving others in your process
everything unsure: every doubt can be cleared by having enough users

Limits of testing

not everything can be tested: some aspects, like long-term impacts, streaks, or habits, can’t be tested in development
tests depend a lot on the tester: the effectiveness of a test depends a lot on the tester, both their planning and observation skills
tests take time

Testing steps: plan → recruiting → testing → assess → report

Why planning?

team direction: being clear on how the test is conducted and why helps to get the team up to speed on the current issues
consistency: a systematic approach helps get clean data between participants
less problems: thinking through the approach and logistics ahead reduces friction and issues during testing
easy report: having the test laid down in advance helps explain the results to third parties

A test plan

goals: what we want to test and why
logistics: where the test would happen, how much we need, what type of test it would be, and how long it will take
participants: what kind of people would be best to test with?
metrics: what we will measure during the test
tasks: specify the flow of the tasks you want to achieve

Goals: declarative statements with specific objectives and constraints (guide the users, give instructions, reduce some steps, be specific)

Logistics 1

in-lab testing: put users in a space and observe them (keep everything in control)
remote testing: online testing, video and input can be recorded and often used at scale and without the designer (later need to have the screen and emotion in front of the video)
guerilla testing: spontaneous approach, pick unprepared people in the street

Logistics 2

moderated: guiding the user through the test, explaining each step’s context, and observing micro-interactions
unmoderated: give them instructions and let users navigate on their own
live: capture more info and get more read on the users
recorded: you’re not there, ask other people to record and you observe from the recording

Participants

target users: identify who the target users of your product or service are
where and how to find them
how to recruit them

Tasks

realistic: find tasks that are common and that they would likely encounter, give some context
action based: users must show you how they would do something
avoid guiding: do not lead them to text on the screen, give instructions that do not give the answer directly
prioritize: understand which task is critical to be tested within a short time

How to recruit

close to personas: aim for participants that are close to your personas’ behavior and usage
3-5 participants: find the usability issues (80%)
compensation: think of rewards that are proportional to the task at hand
better than nothing: any testing is better than none, make sure to test your work, even with colleagues or relatives if needed

A usability test example

brief the tester
get their info (if needed)
give task(s)
observe and take notes
ask follow up questions
thank and wrap

Before starting

give context: explain why you need their help, what the project is about, and how their input will matter
ask for permission: always make sure they’re aware their answers or the video will be recorded
make them comfortable: make sure they understand the product is being tested
let them think out loud

In test

let them struggle: don’t jump in to help, observe when users can’t find something, and note their frustration
don’t answer directly: users might ask for help, try to redirect instead of giving away answers
follow up: ask them about the frustrating parts, what happened there, and what they were trying to do

Write it down

listen and take notes: find a quick way to take down notes on the spot, and elaborate on them after the test
ask questions: after going through, ask users what went well and what went wrong, write it down
be thankful: thank the testers for their time and input, give rewards or compensation if possible

Step back

it’s not personal: check in with your emotions, make sure not to jump in to defend your design, side with the users to look at the issue
don’t defend your design: after going through, ask users what went well and what went wrong, write it down
don’t design on the spot: no matter where the discussion goes, don’t redesign or make changes on the spot

Assessment

data:

quantitative: data that can be measured, numbers
qualitative: feelings, observations, opinions, emotions
example: quantitative tracking and qualitative observations, can be used with video timestamps, screen recordings help too, keep observations simple, include notes about user feelings or attitude as well

Reporting

who is the report for? clients, stakeholders, product team, designers
example: quantitative data on success rate, qualitative data and video extracts, analysis is explaining what happened and why we feel that’s the issue, recommendation is the action to take to solve the issue

Focus

how the design didn’t allow the user to succeed
also on what works well
finding patterns in user behavior
give proof to stakeholders
give precise recommendations

Demo & critique

introduce your request:
I am showing (stage of work)
about (project context)
because (current challenge?)
I would need from you (type of feedback)
to...
within...

3 levels of feedback: describe what you see → interpret what the design must be for → analyze how effective the design is

Feedback sandwich: positive overview → details you like → things to improve → encouraging closure

A good critique: says what is both positive and negative about the work, is precise and focused, is about the design, not the designer, is made with care and a will to help, is actionable, and is not about you

Week 12

Jakob Nielsen's 10 usability features / heuristics:

visibility of system status: a system should consistently inform users about its current state through timely and appropriate feedback. This ensures that users can always see the system’s status, understand its current state, and receive immediate feedback on their actions → predictability and control. More information translates to better decision-making.

ex: confirmation messages, error messages, navigation cues, progress bars.

match between system & real world: designing interfaces that align with users’ real-world experience. visual metaphors (use icons that represent and must have the same style and thickness), familiar language (like “transaction processing” vs “make a payment”).
user control and freedom: allowing users to feel in control of the interface and providing them with the flexibility to undo or redo actions. Allow users to go back a step (most users expect a back link), allow users to easily cancel an action, a close link that allows users to dismiss a new view, and support undo.
consistency and standards: maintaining uniformity and predictability throughout the user interface. Emphasizes the importance of using consistent design elements, patterns, and behaviors across all parts of the system.

3 types: visual consistency (using consistent colors, typography, icons, and layout across the interface), functional consistency, and feedback consistency.

error prevention: designing systems to prevent users from making mistakes by alerting them.
recognition rather than recall: have options presented to users to make interfaces more user-friendly and reduce cognitive load.
flexibility and efficiency of use: designing interfaces for both beginner and experienced users, allowing them to accomplish tasks that suit their expertise and preferences through customization, shortcuts, and adaptability (adjust to user proficiency levels).
aesthetic and minimalist design: focuses on simplicity, clarity, and visual appeal while minimizing unnecessary elements.

key principles: simplicity (using only essential elements and features), visual hierarchy (organizing content and elements in a way that guides users’ attention), whitespace (using whitespace to create breathing room between elements, enhancing readability and visual clarity), consistent typography and colors (using a harmonious palette and consistent typography to create a cohesive visual identity).

help users recognize, diagnose, and recover from errors: guiding users through the error-handling process in a user friendly manner.

key aspects: clear error messages, visual cues, guided recovery paths.

help and documentation: anticipate the questions that people might ask.

Visual design principles: balance, contrast, emphasis, unity, proximity, repetition, alignment, hierarchy, simplicity, negative space

What is a design system?

design system: design language, design kit, component library, developer sandbox, documentation site

Why do we need a design system?

teamwork, consistency

What goes in a design system?

building blocks (palette, templates, elements, modules, components)
guidelines (SOPs, strategy, design rules, documentation, copy samples)

What makes it to the system?

things that worked (all elements, documents, and others that are currently in use by the company and its partners go into the system)
building blocks (components and guidelines, rules to create things that align with the rest of the system)
guidelines (instructions on how to use the elements from the system outside)
system help (documentation, rules & regulations on using the system itself)

System best practices:

group similar items (put together items that achieve a similar function, and another grouping by usage)
naming conventions & instructions (create consistent rules to name the elements, based on their function, use, or anything relevant)
show applications & examples (provide examples on how to use the elements in a practical setting)
contact (provide the contact of the person in charge or the person who created the element for reference)