Why we write on walls

Ghyston By Ghyston 28-09-2017 3 minute read

Why we write on walls

We all write on the walls here. Most design and software development companies do. We also stick up designs, blueprints, structures, plans, and justifications. And we invite feedback from the whole team. This is how we pin down a great set of requirements during discovery, and continue iterating to provide a great software service.

Here are 6 reasons for writing on walls:

1. Hold the design process to ransom

Great user experience is often invisible. A lot of effort goes into making the user not notice it, and making onlookers think ‘Well I could have done that’. Great for users now, not great for evangelising design, which ultimately, is not great for users in the future. Demystifying the process helps everyone see that many directions have been tried and tested. Onlookers can see some progress and be involved in deciding what happens next, whilst the business can demonstrate results.

UX Designers should also want this – they should want to detach themselves as instigators of ideas, from the design. Ideas can then be discussed on equal terms. They should also want to put a limit on exploration and allow for iteration. Working on our own website, we iterated ideas so much we genuinely forgot who originated each one.

2. Send a message

Inviting feedback on design says, “This is our current view of the world. If you have a different view, we’d love to hear it”. This should be all part of a collaborative design culture. If it isn’t – do this today. Take over a wall and write something on it.

It must come part way through the design process – but not part way through a thought process (i.e. do not stick up half of a wireframe). Invite feedback at a particular point, and make it clear how you got there. This can be done at any point except right at the start, or right at the end.

An evolving feedback wall will send the message that design is never done, feedback is always welcome, and there’s plenty of wall space for new ideas.

3. Match method with ethos

We collaborate, a lot – so we use many communication channels on and off line, and fill meeting rooms with workshop tools. We are a transparent company – so we have regular forums with the whole company, discussing anything and everything. We are all designers*.

*Okay, technically we are mostly developers. But as many companies are slowly realising, anyone who touches anything that affects the outcome – is designing it! Design doesn’t start with a list of must-haves and doesn’t end with a PNG export. Design challenges pre-conceived notions and aims to find the simplest solutions possible. In this way – we are all designers.

4. Out of a digital, into a physical world

When we take things out of their usual environment, we see them in a better light. We see the flaws and imperfections. Adding a social context intensifies this. It is often why we see errors just after we press ‘send’. Get your plans out in the open for everyone to see as soon as possible, talk about it, and it will force you to see the flaws in your thinking.

5. Think aloud protocol

Extroverts speak so they can think. Introverts think so they can speak. Either way when you make your thoughts public, you let everyone – including you – into your mind. You see the design process all at once. The act of creating forces you to think. The act of talking it through forces clarity. The act of reviewing forces you to evaluate your own reaction. Discourse uncovers bad ideas quickly.

6. Save time

“Better to spend five minutes on the drafting table, than five weeks on a building site” – or something like that. Clearly this is true, but there is more to this. Whether you go looking for it or not, you’ll always get roughly the same amount of feedback. It is your choice whether this happens early and openly, or late and painfully. The same rules apply for stakeholder feedback as they do for end user feedback. The process of getting buy-in, responding to changes of heart, changes in circumstance, curveballs, and generally accepting change as inevitable, will need to happen at some point before a successful outcome. Starting these feedback loops ‘on the drafting table’ saves time long term.

Share this article

Subscribe to our monthly newsletter about hot topics in the industry