We all know what constitutes a “deliverable”, right? An artefact we hand off to a team down the line, or to the stakeholders themselves. Did you know that most of your deliverables should not be considered as sacred as most designers consider them to be?
A common deliverable that is expected from a designer would be a mockup of some sort, or a diagram, a site map, a wireframe, etc.
Now, I look at a lot of design portfolios, and I can't help but smirk when I see case studies filled with vectorized, polished wireframes or customer journey maps, because I can't help but notice how utterly fake they are, and how they have clearly been designed for the purpose of the case study showcase itself.
Why do I think so, you may ask?
Well, because I don't think there are many projects with budgets that allow for such a high fidelity execution on deliverables that are actually very ephemeral in nature.
Sure, there are valid reasons to up the quality of non-final deliverables, for example when you want to maximize your chances of buy-in from stakeholders higher up, but that's a whole different case altogether. I am afraid that young designers are starting to believe that they need this level of fidelity in what should actually be their lo-fi design phase, that it's just ridiculous. Next thing you know, clients will come to expect this as well. At no extra charge, of course because it's “the industry standard”.
Feel free to go as lo as you can go with these things. It's always better to produce three riffs on the same idea, than to get married to one and spend the same amount of time making it look good.
Use tools that primarily save you time, even if they don't seem like they belong in a designers arsenal. Spreadsheets? Sure. Notepad? Definitely. Sketchbook. Hell yes!
Go get 'em!
Catering demand High Fiderally Wireframe, by Masudur Rahman on Dribbble. Image used only as an illustration, no offense towards the designer.
Let's Get it Straight
Wireframes, journey maps, site maps, diagrams, those are all thinking tools. They are not deliverables, and you should not treat them as such, unless you have a really valid reason to spend your client's budget on them. These things are not final versions of anything. They are visual aids to our thinking process, and this is why they shouldn't be considered to be deliverables. We've never, ever in the history of Superawesome delivered a set of wireframes to a client, and built the final version of whatever it is that we were building to be 1-1 with the wireframe. We've never created a content map for a new website, that wasn't changed in some way during the design process. The phase during which these things are produced is simply too early in the design process, for a designer to be coming to final decisions on anything. This is why every asset you produce in the lo-fi phase of the design process should be considered an iteration at best. It should simply be an artefact cataloguing your thinking at a certain point in time. Nothing else. At Superawesome, we don't even call, nor consider them a “deliverable”. We don't even show them to stakeholders unless they are relevant to making a business decision.So, What's the Problem?
Going hi-fi on an asset that's meant to change is a waste of time. No point in arguing it. Let's take the following scenario as an example. You have onboarded a new client with a new project, and the goal is to design a website. You've divided the project into phases like so:- Phase 1: ideation
- Phase 2: UI design
- Phase 3: front-end development
- etc.
- You go ahead and try to explain how “design is just kind of like that”, and pray to god they have understanding for the hefty chunk of budget you've spent on making a pretty deliverable that is now worthless.
- You go back and redo the work according to the deliverables from phase 1, work around the issues, and pass on the opportunity you found out about in the process.
The Takeaway
Designers should treat products of the lo-fi design phase as temporary, and err on the side of caution if there's a push to invest a lot of time and effort in them. They are tools to think, and they are meant to be created, thrown away, and created again as needed. Lo-Fi design artefacts are an excellent differentiator when you are trying to figure out which kind of a designer you're dealing with. If it's too polished the designer is most likely leaning to the visual side of things, so they are playing to their strengths. However if it's messy, rough, goes deep and covers a lot of scenarios, and it comes on a piece of paper, you are most likely dealing with someone with broader experience in designing things other people are meant to use. As an example, here's how one of the best product designers Ryan Singer of Basecamp ”designs” in the lo-fi phase.
Featured image by Hal Gatewood on Unsplash.
