I tend to define a mockup as a functional analysis made fancy by wrapping a visual coat around it so everybody can understand the logic and structure featured in the proposal.

For us (UX, IxD, designers, developers, industry professionals...) it's a clear and understandable document shaping the foundation of the flow, so it is important to get the client to understand (and approve) it. This is where I tend to experience some 'problems'. Some clients (certainly not all of them!) interpret mockups as a design proposal and instead of approving functional features they often comment on placement, design and even the dummy text... yes, they do.

Whenever we can we also create a provisional design (in support of the mockup), but in most of the cases the lack of feedback (and time) doesn't allow the creation of a graphic counterpart.

How do you people avoid this problem?

enter image description here

  • I think the answers given are all great and summarize down to this: Showing mockups is always a problem. Best to avoid them.
    – DA01
    Commented Nov 13, 2014 at 18:52

5 Answers 5


I employ a technique I call "MVW" Minimum Viable Wireframes : Put the least amount of effort into the wireframe that conveys the design and purpose to it's intended audience.

If a napkin sketch gets the point across, great.

If it's a whiteboard sketch that you and the developer make together and take a picture of, go with it. (My favorite)

Both of these work for internal exchanges

There are definite needs for more fleshed out mock-ups. In this case I always tone them down. Explaining their conceptual nature never works.

I use balsamic since the sketchy nature helps people intuitively understand their purpose. Plus it's easy to use. You can switch the font and wire skin to be line based and system font. The look more high fidelity.

When I am updating an existing feature, I sometimes work in Photoshop with screen shots. This produces high fidelity mock-ups that regularly burn me! People get bogged down in the design vs. the concept. Or worse, the translate them identically when I only meant to convey an idea.

Ultimately, we are in the business of producing engaging applications, not wireframes and designs. I feel spending too much time on them distracts us from the many other aspects of a UX designer's job that are so important.


This may sound funny but I am not joking...

Make crummy looking mockups.

Find some design software that lets you render your ideas as imitation pencil-drawings, preferably one with multiple-colored pencils available. Use that software to render any UI elements and dummy text in pale grays, so that they are clearly inferior to the Clean Bold Dark Type which you use to describe the functionality and to illustrate screen flow.

In essence, use your design skills on the mockup itself, to focus your customer's attention where you want it. Don't waste a lot of time making your mockups beautiful... but do invest some time in your mockups (and in everything else you produce) in making them focused and purposeful.

  • 1
    Have heard/seen this advice many places. Seconded! On one hand, people can be reluctant to criticize or change a "polished" mockup because it seems too finished. This can limit honest input, focus attention on the wrong things, and restrict design options rather early in the process. Low-fidelity/gray scale wireframes make clear to clients that it's a work in progress, a tool for mapping out functionality or placement, etc. Has the added benefit of removing shiny-object distraction topics like "can you make it [insert color]" or "why is it in Latin?"
    – mc01
    Commented Nov 12, 2014 at 21:20

I agree with Henry, and can suggest one of those apps that make roughish looking wireframes: Balsamiq. It creates a sketch-style mockup which when needed, can be reproduced as a finished wireframe.

I don't use it (I use OmniGraffle) but have considered switching over because of clients sometimes seeing the loose WF as the definitive design.

Here's the link: https://balsamiq.com

Mike Side note: I had to add a response instead of commenting because I don't have enough cred.

  • Thanks for the comments everybody! I edited my original post and added an example mockup to illustrate my/our mockup-style. (Made in OmniGraffle.) All our mockups are provided by explanatory text on the right-hand side and use a variety of grays. Blue is used to mark call-to-action areas and main navigation. I still tend to think that this is pretty minimal. Again, thank you for the feedback, I surely keep it in mind.
    – Ziepe
    Commented Nov 13, 2014 at 8:34

In a nutshell, wireframes are like baby shoes. Don't put too much expense into them because they'll be grown out of before you know it.

  • 1
    ha! Love that analogy!
    – DA01
    Commented Nov 13, 2014 at 18:50

What i do is descibe every element on its own, and include the mockup of that particular part. So the section can be named "homepage elements" then one part would be: introduction carousel... then a screen shot of that element alone is added. Refrain from adding colors, use lorem ipsums, and use wired boxes instead of shaded ones, it gives the feeling of a blueprint.

At the end of the day you will get the wrong feedback. You can do two things: first, guide your clients on the kind of feedback you are looking for, like saying: positions and sizes of elements are not decided yet. Then, channel their feedback, put the ones that don't matter aside for later stages, then clearly state, that their notes will be considered in the following stage. If you completely dump their irrelevent feedback, they won't notice because we all know the second phase would look 180 degrees different.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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