I recently worked in a contract where, during the interview, I was told that they do not create wireframe documents. Their preferred approach was that the UXer (“Architect”, in this case) worked directly with the UI Designer to create a solution that was both user-friendly and beautiful – employing a totally streamlined process.
I hadn’t come across this before, so I want to discuss the different levels of wireframing and documentation produced in user experience design, and try to understand what the “best” approach is.
Quite often when I interview for new contracts, or start new projects, I’m asked if I’m comfortable in an Agile environment. The truth is, I have only worked on one project in the last three years that didn’t claim to use Agile (whether or not they actually did is another story for another time). It’s this one project that I use as an example of why, yes, I am very happy to be Agile…
I started a project with a very well known global company, who shall remain unnamed. On day one I was told, “they tried Agile once and it didn’t deliver what they wanted, so they want to be entirely Waterfall”. Well, fine. When I started out in UX, I was designing in isolation. And I’d still have access to the tech team to ask questions about how it could be built, so it’s not like I’d end up designing something impossible. It was just that once I’d designed it, I’d hand it over and have nothing more to do with the thing. Translation: the documentation would need to explain every tiny detail.
The six month project had gone on for nine, by the time I left. Another UXer then took over for me, and I hear it carried on for another few months (that’s just the research and UX design). For over a year. By the time I had moved on, the fully over-functional wireframe Axure prototype created over 300 pages of specification document on export.
So why was this so awful? After all, I was being paid my day rate to work on it. It was nightmarish for a couple of reasons: first, the research (which was conducted in more than one country and involved me driving to Grimsby) was largely ignored by the company who’d commissioned it. The man heading up the development side genuinely said, at the research review, “I don’t care what they want. They’ll get what they’re given and be grateful for it”. But more than that, this massive prototype became their fully-functional web app. Every change, of every detail, was needed. All of the interactions needed to be as close to perfect as possible. Because of various testing versions, and because the prototype got so large, it could take up to an hour to make a simple change, with someone cattily then pointing out where you’d missed one.
It was soul-crushing.
So you probably think I would love working in a place where wireframes are nigh on forbidden. Well, not really. There are a few problems with not using wireframes at all:
- Describing how something will look/work to someone is not easy;
- You really want to validate a design with development before time is spent on visuals;
- As a UXer, you need to work out for yourself if something will work, and all of the “what if” scenarios – and sometimes the only way to do that is to see it in front of you.
While you can achieve the above with a whiteboard (if you can find some space on it and some working pens), the people are not always immediately available to show it to. Plus, you don’t have much to refer back to unless you take pictures and upload them somewhere. And if you do that – isn’t it just a sketched out wireframe? Plus, the testers started to request that I wrote out pages of acceptance criteria to explain how everything worked – and you can imagine where that was going.
In the end, I came to the conclusion that I imagine you expected all along. The right amount of wireframing is… just enough. Work closely with your developers and understand the constraints of the system – understand what can be done easily, and what can be done with a bit of elbow grease. Provide a basic starting point for your UI Designer to use while they come up with the visual concept, and then use whatever’s best to communicate the edge case scenarios – whether that’s a wireframe, a drawing, or just a couple of lines of text.
The best kind of wireframe, though, is one that you’ve developed working closely with your team, so everyone is working towards the same goal.