We’re a small web design team currently revising our workflow, and we were wondering how you work with wireframes.

Do you use wireframes and if so, how abstract or specific are they? Do you try to use real content (texts, images,…) or just rectangles and blind text? Why do you choose to do so?

6 Answers 6


I feel like the question is very broad but I'll try to tackle it in the best way possible.


  • Start with low-fi wireframes to iron out the features and interactions.
  • Use a prototype tool like Adobe XD or InVision to make a hi-fi wireframe/mockup/prototype.
  • Iterate here until all the problems are flushed out.
  • Avoid using random data at all costs. Always use actual content (except in step 1)

Detailed answer:

Understand Requirements

Goes without saying but, this is the most important part of any process. Gathering requirements shouldn't be just a way of listing down the requirements. It's very important to understand the requirements. Figure out how much the customer understands the domain, are they competent enough to understand wireframes, who are their end users, what does the end user want ...

There's literally no limit to the amount of information you can gather during the first phase. If you're wondering why this is pertinent to the question, then here's the reason.

It helps you understand how abstract or specific the wireframe needs to be.

Define Goals

Based on the size of the project, define how big each step needs to be. And that defines what should be the first step.

For a small project, just prepare a low-fi mock using Balsamiq, let all the stakeholders agree on the items on the screen and the interaction flows and then go straight for a prototype with XD or a POC with dummy data (try and get some data from the customer)

For a big project, it makes sense to start with hand-drawn wireframes, then a low-fi wireframe (using Basamiq or something), then a hi-fi wireframe/prototype (using Invision or Adobe XD) and in the end, maybe even a working POC.

Iterate Quickly and Efficiently

Whatever method and tool you use for wireframing or mockups, make sure it's easy to update. Keep iterating until you find the right fit and try to avoid dumping too many changes onto a single iteration. And don't forget to log each iteration as a separate version and KEEP ALL THE VERSIONS! Trust me, I learnt the hard way.

  • Can I suggest to write out POC at least once, cuz it took me a little while to get that it's Proof Of Concept. Another thing, why does it only make sense to start with hand-drawn wireframes for big projects and not small ones? And finally, why is using random data a bad thing? I think some points could benefit from a little explanation.
    – Big_Chair
    Dec 20, 2018 at 10:45

In my experience, it depends on:

a) How big, or how complex project is
b) How many people are working on project, or how many people will use wireframes

In our case it is shown that:

  1. Hand-drawn wireframes are good for starting points, organising elements and for kickoff of the project (to communicate to all members what to do)
  2. Converted to digital prototypes, it can serve as single source of truth for project later phases and communication
  3. Converted to high fidelity digital prototypes, and clickable ones it serves for presentations, finetuning and details

Sketch, Craft, and Invision is great stack to work here.

Most detailed process I can think of would be:

handrawn ⟹ handrawn high fidelity ⟹ digital low ⟹ digital high ⟹ clickable ⟹ visual design

  • Very much agree with the process, while the most simple one can probably be reduced to: -- handrawn - digital low - high + clickable - visual design --
    – Big_Chair
    Dec 20, 2018 at 10:54
  • Can be even simpler. One cool trick is also simulating clickable prototypes on paper. You draw templates, ask person to "click" with the finger and serve the new paper. It's valid way to do simple usability tests. If you bring papers and ask random persons to do you 5min test it's called Guerilla UX testing. Can be easily done in cooworking spaces I. E.
    – xul
    Dec 20, 2018 at 11:42

Two considerations:

The main user group for your wireframes is probably the developers. So really, your wireframes should provide whatever they need. In some companies, devs need hi-fi specs because there's no design documentation to provide layouts, sizes, colors, etc. In other cases, where a Visual Design team is providing the hi-fi graphical details, the wireframes can be more boxy. Talk to your devs often about whether the WFs are providing them what they need.

Do you present your wireframes to a client? I find a lo-fi wireframe works better to focus clients on functionality. It's frustrating to have a client complain about the fonts or colors in the wireframes when you're trying to present functionality and navigation.

In short, make your wireframes serve the purpose they need to serve.


I always create wireframes. I don't want to invest time and resources in creating visual design and interactivity without first having a high level of confidence in the fundamental structure of elements and flow in the solution. It's much faster to create a wireframe, test it, modify and iterate until I have that confidence than to iteratively test and modify using a designed and interactive prototype.

When it comes to wireframe fidelity (images vs placeholders, etc.), that changes during the iterative process. Generally, I start very low-fi and add detail until it's time to start adding interactivity and visual design. Clearly communicating to users and stakeholders that they are seeing a rough concept and not the finished product is key to mitigating any confusion, especially with low-fi wireframes.

The most important thing about wireframes is that they have to be based on solid research. I've found that once I really understand who the user is, what it is they're trying to do, how they currently do it, and how that might be improved, the solution funnel really narrows and the wireframing process moves quickly.


So after a few years doing wireframes, I recommend you to try and get rid of them (or greatly reduce them) while you can. Here are some reasons:

  1. Everyone thinks wireframes are your key deliverables. Few understand the necessary work happening behind a wireframe. The logic, mapping content, planning the information, intentions, etc.

  2. Wireframes limits designers. I've found designers don't really need wireframes, what they need is the logic behind each and allowing them the freedom to implement the interface and design.

  3. Clients get caught up with labeling and content. Often wasted a lot of time discussing about things that are placeholders in wireframes.

  4. Wasted effort. Simply put, considering all the drawbacks and how much time you have to execute the project, wireframes are simply not worth the time.

What I suggest:

  1. Focus your efforts in the details, meats and potatoes data and content of the website. Focus your time on mapping content, studying integrations, mapping journeys, task-flows, research and how to best use the data to maximize the experience. We know content is king, so why not start from content? Here is a very good article which touched these points.
  2. Only make wireframes if you need to run usability testings. Many projects, especially in agencies, can't afford the luxury of testing. Also, if you have plenty of time, I would suggest optimizing the designer's workflow and testing mockups rather than wires. Many things can change in the mockup, from color to item placements, which directly invalidates alot of findings in wireframes. Also, having real content allows users to better judge the experience.
  • Wow, this was really new to us — thanks, we'll consider including the Priority Guide described in the linked article into our workflow! Didn't quite realize the pitfalls of wireframes before… Dec 21, 2018 at 12:35

I've briefly read the others answers and I don't believe anyone else has said what I'm going to and I disagree with Nicolas.

In the businesses I've worked in the level of the wireframes depends massively on the confidence you have in your dev team and whether you even have a designer, as such the what you supply could be as simple as a rough wireframe, down to an almost complete design.

I've done both.

In that way it's not a million miles away from Agile.

Why do I disagree with Nicolas, design lead development is a fully acceptable way of working.

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.