I've been working on a web app, and have gotten the wireframes pretty far along, based on initial in-house research & discussion. The biz guys are eager to set up some demos of the wireframes to potential clients, and I'm eager to use those as an opportunity for more research. Any general advice about what questions to ask, things to avoid, approach, etc.?


  • 2
    I guess this should be CW, since there's not really a "right" answer.
    – sprugman
    Commented Aug 24, 2010 at 16:11
  • Agreed. @ChrisF, can you please rephrase the question so that it focuses on approach? That should be general enough to select an answer and make all current comments relevant.
    – MXMLLN
    Commented Jul 13, 2016 at 14:27

5 Answers 5


Nickster's First Law of Prototyping: There is an inverse relationship between the seniority of the stakeholder and their ability to visualise/conceptualise interactions from a low fidelity prototype...i.e. the more senior they are, the more fidelity is required.

Whether they cannot or will not is kind of moot, but accept it as a fact of life. They become distracted or diverted by detail (e.g. example copy) and the tunnel vision that ensues does not encompass what you are trying to convey (in general but not always).

Read Marty Kagan's "An Open Letter To The Design Community" as it covers this ground very well. Mandatory reading for all imho.

Personally I now use wireframes for my own design iterations and Axure for anything that needs presenting to stakeholders.


Two hurdles you'll probably face if they're not used to seeing wireframes:

  • None of the kerb appeal of design concepts so they might be underwhelmed. Take the opportunity to engage them in having input around the functionality.
  • They might have difficulty considering static/flat wireframes in context of the entire app. We get round this by providing a user flow next to the wireframes, and highlighing the part of the process the wireframe represents.

If you're using interactive wireframes, remember that you're likely to come across a technical glitch or something that isn't linked up properly etc. It's important that you get them to see past this quickly - you don't want them focusing on useless code that's completely irrelevant come build time.

In a wider context try to get them to separate the needs of the business (their natural viewpoint) from the needs of the user. Maybe try building yourself a couple of quick personas beforehand so that you can provide some 'pseudo evidence' when a client suggestion obviously won't work for the end users.



I have demo'd hundreds of wireframes to everyone from external clients to internal executives and the best advice I can give is to first create a story centered around your primary persona and a goal or goals they want to achieve. Then script out the events and workflows required to tell the story that showcases your design and how it enhances the life of your persona.

Actually the best playback for a wire that I ever did was having the actual client walk through the wire in a scripted scenario and showcase how it saved her 1000's of hours of manual labor which ended with one comment "I want this now, when can I have it?"


If you can push back, the best approach is not to demo wireframes for the end client. Keeping it low fidelity, I'd recommend building even a crude interactive prototype. All the boxes and lines in the world won't help non-savvy business users grasp your design nearly as well as if, when text is inputted or elements are clicked/hovered over/whatever an example of what is supposed to happen ... happens.

You can easily do low-fi prototypes in Axure or even something like Balsamiq and include interactions that will demonstrate the flow and state of your proposed design solution.

  • 1
    +1 to interactive prototyping. But -1 to never showing wireframes. If the end client (eg. product owner) knows what's up, then wireframes are a great way to talk about the product. If they're not, then they're not the right person to be the product owner! ;-)
    – Rahul
    Commented Apr 7, 2011 at 0:40
  • Well, in truth I didn't say 'never' - your choice of words. I actually said it's probably the best approach not to. You can't control who the client/product owner is and 'very' often, wireframes are too abstract to be meaningful when a client is already wanting to see how it will behave. Commented Apr 7, 2011 at 5:42
  • 1
    Good call, you're right that you didn't say never. Let me be more specific: -1 to not showing wireframes, unless the client is so useless that doing so would be a bad idea. I would lean towards preferring to show wireframes. The more communication, the better, and there is always a phase in which wireframes are involved, so if you can get feedback earlier, then I say go for it. Also, sometimes you can control who the client/product owner is by educating them or by simply choosing not to work with them if they aren't a good match.
    – Rahul
    Commented Apr 7, 2011 at 9:58
  • 1
    If it is a client you will see again, the more involved you can make them will a) educate them and b) keep them invested in the process, even giving them more collaborative ownership instead of treating each presentation like your a student turning in homework.
    – Mark Sloan
    Commented Mar 31, 2014 at 22:54

IMHO, wireframes are really an internal design document. They help flesh things out and pull out all the business requirements, but are really meant for the internal UX team more than the client.

  • They can also be a valuable tool for communicating with the client about what direction to move in. As long as you're clear and up front about the nature of the wireframes' fidelity, things should be okay. Unfortunately it seems like UI/UX designers might be good at their jobs but aren't always great at managing expectations ;-)
    – Rahul
    Commented Apr 7, 2011 at 0:36
  • Good point about managing expectations, Rahul. With wireframes, as well as with other artefacts, it should be very clear to the client what they are seeing and how this fits in the total process.
    – Marielle
    Commented Apr 7, 2011 at 14:16
  • As I indicated above, I'd tend to agree with DA01 in that wireframes are most useful as the translation stage, taking what should be a written requirements document and maybe an application flow or site IA and translating that into how those elements become the user interfaces for the app/site. In an agile environment, as I also suggested, rapid prototyping during the wireframe stage can help speed things up and put meat on the bones for the client. As DA01 points out, these are most often useful for the design team to go from lo-fi to hi-fi. Commented Apr 7, 2011 at 22:55
  • @rahul I agree, though at the same time, it's really hard to manage those types of expectations, as the client truly expects to talk about visual design more than anything else. Definitely a challenge.
    – DA01
    Commented Feb 19, 2013 at 20:30
  • @jameswanless yes, yes, yes! The more I work in corporate settings, the more Agile seems to be the better way to handle nearly every IT project.
    – DA01
    Commented Feb 19, 2013 at 20:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.