User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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?
I feel like the question is very broad but I'll try to tackle it in the best way possible.
Detailed answer:
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.
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.
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.
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:
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
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:
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.
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.
Clients get caught up with labeling and content. Often wasted a lot of time discussing about things that are placeholders in wireframes.
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:
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.
