How “Lo” Can You Go — Let's Talk Lo-Fi Design

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.
Catering demand High Fiderally Wireframe by Masudur Rahman on Dribbble

Catering demand High Fiderally Wireframe, by Masudur Rahman on Dribbble. Image used only as an illustration, no offense towards the designer.

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”.

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.
All of the phases have milestones attached to them, and all of them have a set of deliverables that are due. The deliverables of the ideation phase include — among other things — a wireframe of each page of the site. You spend days producing these gorgeous assets, delight the client, get sign-off, and move on into phase 2: high fidelity design. Now that you've dove deeper into the nitty-gritty of the project, you start discovering hidden issues. And not just issues, you discover opportunities you can capitalize on that you weren't able to foresee! You go ahead and execute on the hi-fi mockups that now differ from the deliverables from phase 1. You present your work, and the client tells you that this is not what they were expecting. It doesn't conform to a previously agreed upon structure and/or layout. Teams down the line are not expecting this, and are working on deliverables of their own, that conform to the wireframes. It is not based on what they have signed off on. What do you do in this situation? There's two ways to go about it:
  1. 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.
  2. 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.
Which one do you like better? The answer is neither, you shouldn't be in this position in the first place.

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.
lo-fi designs by Ryan Singer
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!
Featured image by Hal Gatewood on Unsplash.

Next up