Presenting a UX Proposal to an Engineering Team, and Defending an AI-Built Prototype

You are an engineer on a team made up of engineers plus one UI designer. In a project deep dive, the interviewer sets up a scenario: if you were asked to put forward a user-experience proposal for a feature, in what form would you present it? The interviewer came back to this question twice more in different words, then probed a past project of yours. For that probe, assume your background includes a project in which you used AI design tools to generate interface screens. ### Clarifying Questions - Who will review the proposal: the engineers who will build it, the designer, a product owner, or someone who decides whether the work is funded? Each needs something different from the artifact. - Is the proposal a new user flow or a change to an existing one, and is there user feedback or usage data to start from? - What should the review produce: agreement on a direction, detailed feedback, or a specification engineering can build from? - What does the UI designer own on this team: the visual language only, or the interaction design as well? - How much time is there before the proposal must be reviewed? ### Part 1 — Presenting a UX proposal How would you present a user-experience proposal to this team, and why that form rather than another? Walk through how you would build the artifact and how you would run the review. ```hint Let them experience the flow Ask what an audience of engineers and a designer can judge from a set of still screens, and what they can only judge by moving through the flow themselves. ``` ```hint Match the effort to the question Think about which open questions a cheap artifact can settle and which ones need something that actually runs. ``` #### What This Part Should Cover - The choice of artifact and its fidelity, justified by what the audience must evaluate - The order in which the artifact is built, and why - How the review is run: what is shown, which decisions are explained, and how feedback is gathered and acted on - How the engineer's contribution fits alongside the designer's ### Part 2 — Working prototype or visual concept? The interviewer probes your AI-assisted project: "The interface you generated with AI design tools: was it a genuinely usable prototype, or only a visual design?" Answer the question, and explain how the result was produced. ```hint Draw the line Be ready to say which pieces a tool produced, which decisions and changes were yours, and what someone could actually do with the result. ``` #### What This Part Should Cover - A direct, honest answer to the question that was asked - The steps from design direction to the finished artifact, keeping the tool's output and your own work apart - Evidence that the result runs and can be reviewed, not just looked at ### What a Strong Answer Covers - Settles the audience and the decision the proposal must drive before choosing its form - Justifies the fidelity of each artifact by the questions it must answer, and names what a cheaper artifact would miss - Presents a user journey and the key design decisions with their alternatives, not a gallery of screens - Keeps the same conclusion when the question is asked again in other words, adding a new angle each time instead of repeating the same sentences - Separates clearly what an AI tool generated from what the candidate judged, changed and is accountable for - Shows how feedback from the designer and the team changes the proposal ### Follow-up Questions - The designer disagrees with the flow your prototype proposes. How do you settle it without the prototype turning into a contest over who owns the design? - When does a clickable prototype stop being enough, so that you build a functional prototype instead? What does the functional one cost you? - How would you check the proposal with real users before engineering commits to building it? - How do you keep AI-generated screens from looking generic and inconsistent with the rest of the product?