QCE Digital Solutions Unit 1 — User Experiences and Interfaces Hangman

The 76 key terms

1user experience (UX)

How easy, efficient and pleasant a system feels to use from start to finish, not just how it looks. Good UX avoids frustration points, while UI is only the look.

2user journey

The series of steps a person takes to complete a task, from start to finish. It shows how they feel at each step (their user experience, UX) and where pain points slow them down.

3Good UX

Good UX makes users more productive, satisfied and likely to keep using a system, while poor UX causes errors, frustration and abandonment.

4user interface

The part of a digital system that you see and use. You give input by touching, clicking or typing, and the screen shows you output.

5affordance

When the look of a control signals how it can be used, such as a raised button that looks pressable or a slider handle that looks draggable. Clear visual cues make actions obvious.

6usability

How easily, quickly and accurately users can learn and use software to achieve their goals, including ease of learning, efficiency of use, and error prevention and recovery.

7useability principles

The five checks for judging an interface: accessibility, effectiveness, safety, utility and learnability. They can conflict, so designers balance them.

8accessibility feature

A design choice that lets people with different abilities use a system, such as alt text for images, captions for video, keyboard-only controls or colour-blind safe colours.

9effectiveness

A useability principle: users can complete their tasks accurately and completely, with correct results, few steps and few errors.

10safety

A useability principle: the interface prevents harmful mistakes, such as with confirmation, clear warnings and data protection, and lets users recover from errors, such as with undo.

11utility

An interface has utility when it gives users the features and information they need for their tasks, with nothing important missing and no unneeded extras getting in the way.

12learnability

How quickly and easily new users can work out how to use an interface with little help, using familiar conventions, clear labels and onboarding hints.

13evaluate

To test a solution the way its user would, then compare what it does with the requirements to find what works well and what is missing.

14pitfall

A design problem that makes an interface hard to use, such as clutter, hidden or tiny controls, unclear labels or error messages, inconsistency, or no feedback.

15task walk-through

Doing a task step by step in an existing interface, recording each pitfall and each useful feature against a useability principle, using screenshots with notes and ideas worth reusing.

16Expert review

A testing technique where a knowledgeable specialist examines a solution against established guidelines to find usability and design issues

17known user

A specific person or group, like a classmate, a teacher or a Year 3 class, who will use your solution and who you can ask directly. They are the user, not you the creator.

18user characteristics

Facts about users, like age, abilities, experience, language and where they use a device, that affect how they use an interface and what it needs to do.

19different users, different needs

One digital system can suit one user well and fail another, because users differ in age, ability and experience. Features like read-aloud and large text help.

20age appropriate

Content, reading level and design that suit the age of the audience, using vocabulary they understand and the right amount of detail for them.

21observing

Watching a user do a task to see where they get stuck, without helping or interrupting. You write down what you see instead of just asking them what they think.

22interview

A conversation where you ask one user questions and listen to their answers to learn about their problem.

23good interview question

A question that is open, neutral and about the user's real task, so it draws out detail instead of a yes or no. Ask 'How do you...?' then follow up with 'Why?' Don't lead them to an answer.

24user need

Something a user must be able to do or have to finish a task or fix their problem. A need is not just a want. We write it as: The user needs to...

25characteristic to requirement

Linking each user characteristic to a specific interface requirement, e.g. low vision needs large text and young users need simple wording, so the design suits them.

26Functional requirement

A specific action, task, or feature that a solution must be able to perform

27non-functional requirement

A rule about how well a solution must work, such as how fast, easy to use or reliable it is. It is not about what the solution does, which is a functional requirement.

28technical environment

The SRS section describing the users (their skills and needs) and the hardware, operating system, software and network the solution will run in.

29prioritising requirements

Ranking requirements as must-have, should-have or nice-to-have so the most important needs are built first, and trade-offs are made when time or budget is limited.

30thumbnail sketches

Small, quick drawings of different design ideas. Make several, compare them, then choose the best one to build.

31screen sketch

A simple drawing of a screen. It has an outline, then a box or shape for each button, text box or label, drawn where it will go. You draw one sketch for each screen.

32annotation

A short note on a design that says what an element does or what happens when it is used, like a label on a button or an arrow showing which screen opens next.

33wireframe

A simple black-and-white outline of a screen showing where controls and content go, using placeholder boxes and no colour or final graphics.

34schematic diagram

A diagram that uses labelled symbols and arrows to show an interface's main parts and how they connect, without showing screen detail.

35Sitemap

A diagram showing the structure of a website or app, displaying pages and how they connect to one another

36storyboard

A row of numbered screen sketches with arrows showing the order a user moves through them, so you can plan how someone gets from the first screen to the last.

37Mock-up

A static visual representation of a solution's interface, showing layout and design before development begins

38interactive prototype

A clickable model of a design where buttons link screens together, so users can try a task before any code is written. It is used for testing, not the final product.

39present a design

To show your sketch, explain how each part helps the user, and ask others for feedback. Listen to what they say so you can improve your design.

40design criteria

Checkable standards, such as easy to read, easy to navigate or meets the requirements, that an interface is designed to meet and then judged against.

41criteria table

A table that lists each design option against the same criteria, rates each one, and helps you pick the best design and give reasons for your choice.

42button

An interface element the user clicks or taps to make something happen. It needs a clear label, should do one action, and must be big enough to press easily.

43text box and label

A text box lets the user type in an answer. A label is words on the screen that tell the user what to type (prompt text) or show the result (output text).

44menu, slider, checkbox

Interface elements that let the user pick from set options instead of typing: a menu lists choices, a slider picks a value on a range, a checkbox turns an option on or off.

45layout

Where items are placed on a screen. Good layout groups related items together, lines them up and leaves space between them, so the screen is easy to scan.

46consistency

Consistency means similar things look and work the same way on every screen, like buttons with the same style and a menu in the same place, so users always know what to do.

47alignment

A UI design principle that lines up elements along common edges or centres, such as a left edge or grid, so the layout looks tidy and is easy to scan.

48balance

The even spread of visual weight across a screen so no side feels too heavy. It can be symmetrical (mirrored) or asymmetrical (different elements that still feel equal in weight).

49contrast

The difference in colour, size or brightness that makes key elements and text stand out from their background so they are easy to read and notice.

50space

The empty area around and between interface elements, used to group related items, separate unrelated ones and keep a layout uncluttered and easy to read.

51text formatting

Using font, size, weight and colour consistently so text is easy to read and shows importance, such as larger bold headings above smaller body text.

53Alt text

A short written description added to an image so screen readers can read it aloud to people who cannot see it. Right-click the image, choose Alt text, and describe its purpose.

54captions and transcript

Captions show spoken words as on-screen text. A transcript is the full text of audio or video. Both help deaf, hard-of-hearing and no-sound viewers. Always check auto-captions.

55feedback

A response from the interface that tells the user what happened, like a confirmation message, or an error message that says what went wrong and how to fix it.

56user flow

The path of screens a user follows to finish a task, like logging in or buying a ticket. Navigation controls such as back and home buttons help them move along it in as few steps as possible.

57Annotated design review

Checking a mock-up against each UI principle in turn (alignment, balance, contrast, space, text), annotating the improvements needed, then revising the design.

58GUI

A graphical user interface: windows and controls like buttons and text boxes the user clicks or types in. The program waits for events, such as a click, and responds to each one.

59root = tk.Tk()

Creates the main tkinter window after import tkinter as tk. Call root.mainloop() at the end to show the window and wait for events like clicks.

60tk.Label(root, text='...')

Creates a tkinter label that shows text in the window. Use .config(text=...) to change what it shows, such as displaying a result. Options like font and fg set style.

61entry = tk.Entry(root)

Creates a text box in the window. Call entry.get() to read what the user typed. It is always a string, so convert it with int() or float() to use it as a number.

62tk.Button(root, text='Go', command=show)

Makes a button that runs the function show when clicked. Write the function name with no brackets, or it runs straight away instead of on click.

63control.grid(row=0, column=1)

Places a control in a table-like layout at the given row and column. pack() instead stacks controls in order. Never mix grid and pack in one window.

64messagebox.showinfo()

Pops up a message window to tell the user a result. Its partner messagebox.showerror() pops up an error, such as when a handler finds invalid input. Both need a title and a message.

65evaluation criterion

A measurable standard used to judge a solution, linked to a requirement and written so it can be answered with evidence, such as a target, a yes/no check or a rating.

66Useability rating

Judging an interface against accessibility, effectiveness, safety, utility and learnability as met, partly met or not met, with testing evidence for each rating.

67evaluate a design

To check a design against criteria, like easy to read, easy to use and meets the requirements, using a checklist, user feedback and evidence to show if each one is met.

68User testing

A testing technique where real users try a solution and give feedback, helping identify usability issues before release

69test scenario

A realistic task a beta tester performs with the solution, written as a task description, steps to follow and a clear expected outcome to check the result against.

70observe without helping

Watch testers complete a scenario without helping them, and note where they hesitate, make errors or succeed, so you can see real usability problems.

71user feedback survey

Set questions you ask users after they try your solution. You record their ratings and comments, then sum up the answers to compare with your criteria.

72Beta test results

A record of each beta test scenario, what happened, the tester's comments and any issue found, so the developer can decide what to fix.

74improvement

A change that helps when a system does not meet a user's need. Find the gap, suggest one new feature, and give your feedback in a kind, respectful way.

75recommend modifications

Group similar beta test issues, rank them by impact, then suggest a specific change for each one that links back to a requirement of the solution.

76Improvement recommendation

A statement that names the problem, the useability principle it breaks, the specific change to make and the user benefit, linked with because and backed by evidence.

77modify a design

Change one thing in your design, like size, position or wording, because of feedback. Then check it again. Change one thing at a time and save each version.

78evaluation report

A document that states how well each criterion was met, gives evidence for each conclusion, and recommends improvements to the solution.