







Two weeks ago I had a chat with Ollie Hemstock from Northumbria University about Slow Design. We discussed the benefits and downfalls of slow and fast design and eventually wondered what makes fast good and what makes slow good. So I took up the challenge of defining good fast and good slow, and while I was at it, I also defined bad fast and bad slow. Making myself a little online mind-map I speedily popped down virtual post-its and quickly discovered that what makes a speed good is also sometimes the reason why it is bad.
Fast does not give you enough time think, which makes things less complicated but also reduces information and abandons nuance. Slow makes loads of room for nuance but can block change in fear mistakes. One is therefore not better than the other. But what happens when we combine the two.
Good Fast + Bad Slow
Good Fast is blocked by Bad Slow killing innovation. Good Fast means testing and failing fast but Bad Slow would put a stop any testing.
Bad Fast + Good Slow
While Good Fast is blocked by Bad Slow, Bad Fast and Good Slow stand in complete opposition. They simply cannot happen at the same time. Bad Fast is bad because there is little thinking, while with Good Slow there is loads of thinking. These two cancel each other out.
Bad Fast + Bad Slow
In this combination someone quickly solves a problem but then does not go back to reflect on it. For example someone does some botch DIY which works at first but really needs a long term solution, however bureaucracy and rules are blocking that long term solution from happening.
Good Fast + Good Slow
Instead of being blocked by Bad Slow, Good Fast releases information that is then integrated into Good Slow’s thinking process. Here there is an agreement between the two speeds that failure is good for the future but that you need to be able to put the breaks on at any moment. It is the ultimate feedback loop. Like a well run household, because sometimes you need a quick book under a table leg and other times you need to slowly work out where you actually what to put a shelf.
I have realised a rather large problem with my project and that is that it is very difficult for me to test out my ideas. I am essentially building an archive-like system and the true test of an archive is to see how well it stands up to time. Within the time frame of my CDA I will not be able to truly see how well my archive system works both from a user point of view and the maintenance workers.
I wonder if there is any literature on this that could help me workout how to test long term products in the short term…