Presentation for ui design

Presentation purpose and scope

Rather than showing screens one after another, explain a user goal, the flow toward that goal, and the reasoning behind the design decisions together. Help your audience answer these questions: Who is the user? What do they want to do? What steps do they take? Which design decision supports those steps? What is complete, what is a draft, and what should be reviewed for usability?

If your goal is to get feedback, identify the flow you want reviewed and the questions you have. If you are presenting an application, distinguish working parts from planned ones. Expectations may vary by course or project instructions; do not present another course’s format as a general requirement. For example, the cited CS4760 assignment asks presenters to introduce the system and its users, show the interface using a completed application and/or high-fidelity prototype, explain potential usability issues, and describe interface elements that are complete or planned for completion the following week. These requirements apply to that assignment (assignment instructions).

What to prepare before the presentation

First, define your target user, the main task you will present, and the feedback you want to receive by the end of the presentation. Choose the views needed to explain the task rather than including every screen. Label the status of each one accurately: implemented screen, prototype, draft, or work not yet done. If a visual does not show the actual product, make that clear.

Review the slides in the format you will use for the presentation. If the text is hard to read, shortening the explanation and enlarging the screen is a practical choice. Show prototype interactions if doing so contributes to the presentation; if a link or interaction does not work during the presentation, you can use screenshots and transitions to explain the flow. These are presentation-preparation suggestions; they do not require any particular software, device, or platform feature.

Slide order that tells the story of the flow

The following order can take your audience from the user’s goal to the design rationale and feedback:

• Purpose and user: Briefly explain what the product does, who it is designed for, and the task being addressed.
• Task and starting point: Show where the user starts, what information they have, and what outcome they want to reach.
• User flow: Make the steps and decision points easy to follow in a diagram or numbered screens.
• Design decisions: Explain which need an important component is intended to address. If user behavior has not been validated through research, describe it as an assumption, not a finding.
• Completion and open items: Describe the state in which the task is completed successfully, any error or empty-state designs, if applicable, and planned work.
• Feedback: Ask which decision or step in the flow you want reviewed.

If a slide includes multiple screens, show the transitions between them with numbers or arrows. Instead of adding lengthy explanations to every visual, place a brief rationale and a specific validation question next to the screen.

Hypothetical example: appointment-scheduling interface

This scenario is fictional; it makes no claims about a real product, user research, or test results. A user wants to find an available appointment in a clinic app and submit a request. The presentation’s central question could be: “Can the user choose an available time and submit an appointment request?” If no research has been conducted, describe the idea that the user will want to compare specialists and times as a design assumption.

• Slide 1 — Task: Explain that the user wants to choose an available time with a specialist and identify which flow the presentation will cover.
• Slide 2 — Choosing a specialist: Show how specialist options are presented. Rationale: The aim is to make information that may be useful for comparison visible. Question: Can the user distinguish between the options?
• Slide 3 — Choosing a time: Show how a time is selected and how the selection carries forward to the next step. Summarizing the selected time may help the user review their choice; frame this as an expectation to test, not a confirmed result.
• Slide 4 — Reviewing information: Explain the summary shown before the request is submitted. Question: Can the user find the information they want to change?
• Slide 5 — Outcome and remaining work: Show the state in which the request is submitted and any unfinished parts. Question: Can the user tell whether the request has been submitted?

The rationales in this example are also design suggestions; use actual screens from your own product in your presentation, and do not present unvalidated assumptions as user findings.

Explaining design decisions

Explain important decisions using this chain: user need → interface decision → expected effect → validation question. For example: “Showing the selected time in the summary is intended to let the user check their choice before submitting. During the task, we will observe whether the user understands the time correctly.” This lets you explain a design choice without presenting an effect that has not yet been measured as proven.

If you show before-and-after designs, explain why the change was made and what feedback it was based on. The relevant CS4760 instructions ask for screenshots of completed views and paper designs for views that are not yet complete but are planned. This is a requirement of that assignment; check separately which presentation format your own project expects (presentation instructions).

During the presentation and feedback

If you need to see speaker notes in the presentation tool you use, try this in your own file before the presentation. For example, the Google Slides help page explains how to access speaker notes in presenter view and the conditions for presenting with multiple monitors. An additional monitor is a requirement for this particular multi-screen method; it is not required for a general interface presentation. Check the appropriate view for your tool and the presentation menu available to you (Google Slides presentation help).

When asking for feedback, invite comments on a specific step or decision rather than asking a broad question such as “What do you think?” Take notes on the comments you receive and consider suggestions without immediately committing to implement them. The CS4760 assignment specifically says to record feedback and ideas from the audience and that presenters should not be defensive about comments; this, too, is guidance for that course.

Final review and frequently asked questions

• Is the user, task, and purpose of the presentation clear?
• Can the audience see the beginning of the flow, its decision points, and the completion state?
• Are the rationale for important decisions and the validation questions stated?
• Are assumptions distinguished from research findings?
• Are prototypes, implemented screens, and planned work labeled accurately?
• Are the visuals readable, and is the requested feedback specific?

Should I show every screen?

No. Choose enough screens to explain the main user task and the relevant decisions. Include other views only if the presentation’s purpose and time allow.

How should I present rationales if no user testing has been done?

Describe rationales as design assumptions, not confirmed results, and ask how each assumption could be checked.

Related practical guides

You can explore the relevant step in this work in more detail with the Logo design presentation: explaining design decisions guide. You can explore the relevant step in this work in more detail with the Preparing an interior design project presentation guide.