IDEA9105 Interface Design
The Complete Study & Assessment Guide · S2 2026IDEA9105 Overview
- University of Sydney
- Semester Two offering
- Postgraduate interface design
- Attendance and submission hurdles
- 4 concept chapters
Interface Design treats an interface as a designed relationship among a person, a task, information and a technical system. Historical paradigms show that command lines, menus, direct manipulation, graphical interfaces and touch interaction encode different assumptions about learning, visibility and control.
- Research before features Ground interface choices in observed tasks and contexts.
- Structure becomes visible Use hierarchy, labels and grids to expose information relationships.
- Fidelity has a purpose Choose the cheapest artefact capable of answering the next question.
- Track completion rules The Assessment overview requires 100% of the four assignments, meaning all four, and 90% attendance to pass; it also states the 5% daily late deduction and possible Absent Fail consequence for a missing submission.
How IDEA9105 is assessed
| Component | Weight | Format |
|---|---|---|
| Assessment 1: User Research | 15% | Group user-research task |
| Assessment 2: Wireframes | 25% | Individual wireframe task |
| Assessment 3: Final Design Demonstration | 20% | Group design demonstration |
| Assessment 4: Interactive Prototype | 40% | Individual interactive prototype |
The Assessment overview publishes four weighted tasks totalling 100%. It also states that 100% of the four assignments, meaning all four, must be submitted and that minimum attendance is 90%; missing either condition prevents a pass. The same Assessment overview applies a 5% late deduction from the maximum mark for each calendar day and warns that failure to make any assessment submission may result in an Absent Fail mark of zero.
Interface Design assessment structure
Use the published weights as a planning map; the current learning site controls instructions, submission settings and any stated pass condition.
What IDEA9105 covers
Interface history supplies design alternatives; user research, information architecture, grids and prototype fidelity then turn evidence into testable artefacts.
Interface Lineages and Interaction Paradigms
Read controls, representations and feedback as one interaction contract02User Research, Personas and Early Sketching
Ask about tasks, contexts and barriers before proposing an interface03Information Architecture and Grid Decisions
Organise, label and connect material around user tasks04Wireframes and Prototype Iteration
Delay colour and surface detail while fixing structureThe studio sequence then moves from research questions, observation and online ethnography to personas, usability, information architecture, grids, sketches, wireframes and interactive prototypes. Each artefact has an evidentiary job.
A persona should synthesise observed patterns rather than decorate a presentation; a grid should clarify hierarchy rather than merely align rectangles; a wireframe should make task flow discussable before visual polish makes change expensive. The guide therefore asks what uncertainty each design move reduces and which user action could falsify the team's assumption. Four weighted assessments carry the mark.
Submission of all four tasks and minimum attendance of 90% are separately published pass conditions and should be tracked from the beginning. For Semester 2, 2026, Interface Design at The University of Sydney publishes this assessment map: Assessment 1: User Research (15%); Assessment 2: Wireframes (25%); Assessment 3: Final Design Demonstration (20%); Assessment 4: Interactive Prototype (40%).
The Assessment overview publishes four weighted tasks totalling 100%. It also states that 100% of the four assignments, meaning all four, must be submitted and that minimum attendance is 90%; missing either condition prevents a pass.
The same Assessment overview applies a 5% late deduction from the maximum mark for each calendar day and warns that failure to make any assessment submission may result in an Absent Fail mark of zero. Interface history supplies design alternatives; user research, information architecture, grids and prototype fidelity then turn evidence into testable artefacts.
An interface makes parts of a system perceptible and offers actions through controls, language and spatial arrangement. The user forms an expectation, acts, observes system feedback and updates that expectation. Breakdowns occur when the visible representation does not match the underlying state or when available action is hidden. Describe the task in verbs and mark where the user must infer hidden state.
Then decide whether visibility, mapping, constraint or feedback is the appropriate repair. Research begins with a decision the team cannot responsibly make from assumptions alone. Questions about goals, workarounds, context and breakdowns invite evidence. Questions that ask whether users like a planned feature often convert a solution into the premise and collect polite confirmation.
Write the pending design choice beside each research question. If no possible answer would change the choice, the question is ceremonial rather than useful. Information architecture defines categories, hierarchy, labels, navigation and relationships. A successful structure aligns with the user's task model while remaining maintainable as content grows.
Internal departmental ownership is weak evidence if users do not understand those boundaries. Name the organising principle at every level and test ambiguous items against it. A label should help a user predict content before clicking, not merely sound concise to the team. A wireframe represents hierarchy, content priority, controls and navigation at a chosen level of fidelity.
It should contain enough realistic content to expose spatial and labelling problems. Placeholder blocks can hide the very complexity the design must support. Write one research question on the prototype cover. During review, defer comments that the chosen fidelity cannot answer and collect them for the appropriate later artefact.
Worked application: Prototype iteration converts failure into evidence
- 1Name the user, context, task and observable completion state.
- 2Map the current interaction and locate the evidence-backed friction.
- 2Change one interface decision and specify its normal and edge states.
- 1Define a usability and accessibility observation for the next iteration.
Key terms
- Action
- Action — An interface makes parts of a system perceptible and offers actions through controls, language and spatial arrangement. The user forms an expectation, acts, observes system feedback and updates that expectation. Breakdowns occur when the visible representation does not match the underlying state or when available action is hidden.
- Representation
- Representation — A beautiful screen can fail if feedback arrives late, labels mislead or recovery is costly. Evaluate the complete loop: goal, available action, execution, system response, interpretation and next move.
- Feedback
- Feedback — Describe the task in verbs and mark where the user must infer hidden state. Then decide whether visibility, mapping, constraint or feedback is the appropriate repair.
- Command Language
- Command Language — Command interfaces let experienced users compose operations precisely and automate sequences, but they demand recall, syntax knowledge and error interpretation. Their efficiency depends on stable grammar, discoverable help and feedback that reveals what the system understood.
- Recall
- Recall — Completion, history, examples and reversible execution can reduce recall cost without removing expressive control. The design question is not whether graphical or command interaction is universally better, but which tasks, users and failure costs fit each form.
- Automation
- Automation — Observe task frequency, compositional complexity and error consequence. Prototype recovery from an invalid command, not only the successful path, because error language is part of the interface.
- Direct Manipulation
- Direct Manipulation — Direct manipulation represents objects and actions in a visible workspace. Incremental operations and immediate feedback shorten the distance between intention and result. The benefit depends on good mapping: movement, handles and constraints should correspond to the user's conceptual model.
- Mapping
- Mapping — Not every system state can be placed on screen at once. Dense controls can overwhelm novices, while gestures without cues recreate hidden syntax. Designers choose which objects remain visible and which actions need progressive disclosure.
- Reversibility
- Reversibility — Test whether users can predict the result before release and undo it afterward. A surprising animation may entertain while weakening control if it conceals the new state.
- Touch Target
- Touch Target — Touch removes the separate pointer and makes the user's body part of input. Fingers occlude targets, vary in precision and operate within reach zones. Mobile contexts also involve movement, brief sessions, orientation changes and competing environmental demands.
- Occlusion
- Occlusion — A swipe can be efficient after discovery but invisible beforehand. Critical actions should not depend on an undiscoverable gesture alone. Target size, spacing, feedback and accidental activation must be considered together.
IDEA9105 FAQ
Which attendance and submission conditions determine completion of the unit?
The Assessment overview states a minimum attendance requirement of 90% and requires submission of 100% of the four assignments, meaning all four. Missing either condition prevents a pass regardless of the weighted total. The same Assessment overview applies a 5% late deduction for each calendar day and warns that a missing assessment submission may result in an Absent Fail mark of zero.
Check that page and the current Canvas record before the final submission window.
How does a user goal become an observable interface requirement?
A data analyst repeats a transformation daily. A command can be faster and auditable, while a searchable palette helps occasional users discover the same operation. Both can invoke one underlying action with different entry points. Observe task frequency, compositional complexity and error consequence. Prototype recovery from an invalid command, not only the successful path, because error language is part of the interface.
An edge case is analytically valuable when it exposes a missing state, ambiguous label or irreversible action.
What can a low-fidelity wireframe test more efficiently than a polished screen?
A timeline editor lets a user drag a clip and see adjacent clips shift. The same operation expressed through numerical fields may be more precise but harder to explore. Offering both routes supports different moments in the task. Test whether users can predict the result before release and undo it afterward. A surprising animation may entertain while weakening control if it conceals the new state.
The next iteration should name one changed element and the user behaviour expected to change with it.
Why should interaction states be designed beyond the ideal path?
A destructive item action is available only through a left swipe. Experienced users move quickly, while new users cannot find it and motor-impaired users struggle to perform it. A visible menu provides an equivalent path. Prototype on the target device and in realistic posture. Watch the hand obscure content, record reach and error recovery, and avoid using a desktop cursor simulation as the only evidence.
Record the decision produced by each observation so the research trail remains visible when the prototype changes.
How can usability evidence lead to a specific design decision?
A health-app team asks whether reminders would help and receives broad agreement. Observing routines reveals that users already silence notifications during shift work. The design problem is timing and control, not reminder absence. Write the pending design choice beside each research question. If no possible answer would change the choice, the question is ceremonial rather than useful.
An edge case is analytically valuable when it exposes a missing state, ambiguous label or irreversible action.
What belongs in an accessible focus and feedback sequence?
A forum appears to reject a feature because critical posts dominate the top of a thread. Sorting by time reveals early supportive discussion buried after an algorithmic popularity shift. Platform ordering changes the apparent consensus. Record how material was encountered, what the platform made visible and which participants remain unseen.
Paraphrase responsibly and avoid collecting identifiable detail beyond the research purpose. The next iteration should name one changed element and the user behaviour expected to change with it.
Why is information architecture more than arranging navigation labels?
Research shows one group manages care collaboratively while another acts alone under time pressure. Those patterns justify different sharing and confirmation needs; favourite colours and fictional job titles do not. Attach each major persona claim to an observation cluster. During critique, ask what new evidence would split, merge or retire the persona rather than treating it as a permanent user truth.
Record the decision produced by each observation so the research trail remains visible when the prototype changes.
How should a prototype expose the consequence of an irreversible action?
A team draws several polished versions of one appointment screen. A rough alternative that begins with reason for visit exposes a different triage logic and generates a more useful comparison. Time-box individual sketches before group discussion so one loud proposal does not anchor everyone. Annotate the user action and expected system response on each frame.
An edge case is analytically valuable when it exposes a missing state, ambiguous label or irreversible action.
How to prepare for the assessments
Maintain a decision log beside the design file. For every major interface choice, record the user evidence, the task or information problem, the alternatives considered, the prototype used to test them and the observation that would trigger revision. Begin research notes with behaviour and context, not an interpretation. Cluster observations before naming a persona or need.
During information architecture work, test whether labels make sense outside the team's vocabulary and whether a user can predict what lies behind a choice. Sketch several structurally different routes before increasing fidelity. When critique begins, name the design question so feedback does not collapse into taste.
Run a short task with a clear success signal, record hesitation and recovery as well as completion, and revise the smallest relevant layer. Keep the attendance record and a submission checklist beside the project plan because the unit publishes both as pass conditions. The finished portfolio should preserve the reasoning trail from evidence to structure to interaction, not only the polished screen.
IDEA9106 Design Programming · DESN1001 Design Process · INFO5990 Professional Practice
