On Twitter, Thomas asked “When and why exactly do you do wireframes?”.

I replied that this really depends on what kind of work you are doing. You will get a different answer from a web designer than from an app designer.

I’ve been enjoying the working file podcast recently. If you are a designer it’s definitely worth a listen.

In Episode 3, the hosts have a discussion about what it means to be a famous designer.

At one point someone notes that we designers are really good at claiming to be the first to do a certain job while that job has actually existed for ages.

This is so true. People start calling themselves “digital product designer” as if this is a new job that never existed before “apps”. This job was just called functional analyst before.

I have this book called Designing Interactions that talks about people are doing the exact same stuff as my job in 1992.

But back to the question at hand: when and why exactly do you wireframe? A lot of people answered that they never wireframed at all or they would just jump straight to either visual design or HTML and CSS.

This strikes me as something you can only do when you do some kind of “template” style marketing websites. Or if you have the exact content that a website should have delivered to you. Or if your focus is entirely on the visual side of things.

Are you doing the problem solving or are you doing the visuals? Are you doing the content or are you trying to make sense of what someone else decided before you? All of this is design, but it’s a different kind of design.

In Episode 2 of the Working File podcast, it’s put in a very succinct way: you can be hired as an artist or as a problem solver.

At Mono we help design extensive software that contains tons of functionality like Schoolonline and Ticketmatic.

We are hired as problem solvers.

The visual parts of the interface are important and we strive to make beautiful, delightful interfaces, but there is a big emphasis on solving the actual problem.

A lot of the software we make is pretty extensive. If you would map out all of the unique screens in the kinds of applications we make you would probably find that there are between 50 and 250 unique screens.

This brings a new problem to the table which I like to call “designing at scale”.

How do you create and communicate a design that spans hundreds of screens?

Over the years we’ve tried different solutions to designing at scale.

For web apps we rely (a lot) on HTML prototypes.

For native apps we like image-based prototypes – made with tools like Invision – but syncing everything up can be a real pain. Recently I’ve started using Flinto which seems pretty cool.

I’ve also had success with well-documented Keynote files that I like to turn into websites with the help of Keynote Extractor.

And sometimes nothing beats a lot of direct communication with the application developers.

The right solution depends on the software you are making, but for me one thing is certain: you have to be careful about your deliverable weight.

What do I mean by deliverable weight?

Imagine that you are creating the best design in the world, you are pouring many many hours into it, and you try to nail every detail. You proceed to document the design in the best way possible by creating a large presentation that is about every nitty gritty detail to show how much you thought about every edge case.

It’s 200 pages long and it contains just about everything you want to know.

You deliver the presentation to loud applause in the board room. Everyone is happy and you pat yourself on the back for another succesful project.

Six months later you check in with the developers to see what they implemented, and what they did was nowhere close to what you envisioned.

Where did it go wrong?

Did you fail as a designer?

Well, what happened is that you threw a bible over the wall and expected someone to read it.

Just today* we won a new software design project, where the goal is to transition existing software to the web. The “old” software contains over 50 different modules/functionalities.

I’m guessing this will be the biggest Sketch file to date… if we go the route of designing every screen. I don’t think that’s going to be the solution.

A lot of software design is systems thinking, where you try to find out which patterns repeat themselves and find the best solution for that pattern.

When you nail the pattern, you suddenly have a solution for a lot of different parts of the software.

*I wrote this post a few months ago.