Slower Thinking When It’s Needed
I made a huge assumption in a previous article that many people are willing and able to work in a largely collaborative environment, avoiding cascades of work and mass handover of documents. In this scenario, being equipped to ‘decide fast and move on’ is a surefire way to make headway on a project.
Sometimes, though, deciding fast and moving on isn’t going to work. The benefits of making an informed, rapid call on something might be far outweighed by process-in-place and diametrically-opposed ideas on what good work looks like. It might be that moving at pace isn’t possible, viable, or even wanted.
A recent project reminded me that, although moving quickly to ‘create a design’ for something which is going to be built in a subsequent Agile sprint is part and parcel of most designers’ daily remit, the need to become involved in the minutiae of the details early is very important when your process is one-directional.
When you’re working in a way which almost requires a cascade of input -> output -> repeat to maintain a cadence of ‘stuff’ appearing at the end of a chain, understanding use cases at the edge of our user needs bell curve is vital. Presenting how we handle things like user and system errors for any number of scenarios can be crucial to ensuring that a team can both keep moving and understand the expectation for the end result of their work.
In essence, it requires slower thought. It needs us to take stock of a much bigger picture and ‘go deep’ early.
Although I bring ‘decide fast and move on’ with me in my project toolkit to help galvanise teams into action, it isn’t going to be a good fit for everyone. The levels of collaboration needed to make it work may not be there either through business culture or team willingness; this is challenging, but it’s something we must work with. Flex the tools you have to the context you’re in and aim for effective work over an ideal process.