Good way to present wireframes to stakeholder for application concept?

Question

For a lesson-making application, I have designed wireframes with multiple user flows to help illustrate the important features within the application (i.e user creates a lesson , user clicks and drags something, etc). However, I was wondering if there were alternatives that could be more effective in presenting my wireframes. For more context, this stakeholder has a strong opinion, and basically said "Design this".

If I were to go with presenting user flows, would it be better to present individual stories for each flow/design concept, or present the same story for the different flows? Also, when soliciting feedback, would it be better to present everything or ask for feedback after each flow?

Regarding alternatives, would showing a more "final" part of the user flow be effective? (For example, presenting wireframes of an interface with many lessons and quizzes already created).

Thanks and would appreciate any suggestions.

Answer 1

I don't know the scope or the resources you might have for the concept, but when I present an idea to a stakeholder I always put together a quick prototype (in Figma, or more recently in Protopie). This enables you to "show, not tell" and stakeholders get a better understanding of the ideas presented.

Answer 2

Well, when it comes to showcasing the solution, always keep in mind that they are less aware with the flow, connecting links and all. so just sharing the link with all the wireframes static wont work and they wont even be more interested into seeing this. even its wireframe, make it in clickable prototype form, either share the prototype link with all the hotspots where click would work or you can record the video prototype and share it in video format. this way you can share your ideas or thoughts effectively. Hope it helps.

Answer 3

Make sure to start by stating the problems you found.

This helps your stakeholders dive into the context.

And the last tip is to craft a story for each use case (so you can leverage empathy).

Answer 4

First of all, congratulations that you are starting the discussion with wireframes (which to me sounds like low-fidelity, rough-strokes images highlighting important information and showing the pathways the user can follow). That reduces discussions about colors, terminology, frames and whitespace which are inappropriate in the early design stages.

To keep your discussions on this level as long as possible, I'd discuss the list of all relevant flows (or use cases, or scenarios) first. Do these flows cover all the stakeholder's ideas of what the product should do? Which are the most important/frequent ones, and which are corner cases? Which additional questions do you have on the flows to create a sound design (e.g., expected volume of data, or frequency of use, ...)?

Then I would dive into the important/frequent ones, showing the wireframes and emphasize how this flow supports users with this particular goal (or process).

In this way, discussions can start on the list of flows (completeness here is of the essence, I believe), and as long as you have time and their interest, you can discuss the flows one by one in the order of importance (as seen by your stakeholder). As long as you are sitting with the stakeholder, a stack of printed images is enough, I believe. The more remote the setting gets, the more you have to invest into an interactive prototype (e.g., if you can't talk to all of them directly, an interactive prototype with click hotspots is good to explore your flows).