Build your software in ‘hard mode’ or ‘easy mode’?

I choose ‘easy mode’… every time. This is how.

First, I must explain the concept of ‘hard mode’ and ‘easy mode’. It comes from the former spy and author Shane Parrish. He explains that ‘hard mode’ is when we take on something without the correct preparation. Conversely, ‘easy mode’ is undertaking a task or action with adequate preparation.

A quick example. Some years ago, I signed up for a marathon. Although I’ve played sports all my life, I am not a long-distance runner. To make it even more challenging, I signed up for the marathon late, giving myself only two months to go from 0 miles to marathon. Not enough time to be fully prepared. As a result, I ran it in ‘hard mode’. It was the toughest thing I have done in my life and the last 10 miles were pure agony.

With that in mind, let’s have a look at software development.

Hard mode:

1.      Design the solution in isolation, with no feedback from users or the engineering team.

2.      Your designs consist of simple wireframes, with contradicting styles and a confusing flows between the screens.

3.      Hand the designs over to the engineers and tell them to get on with it.

Easy mode:

1.      Engage with your engineers as early as possible in the design process, their feedback is invaluable and they will provide insight into technical feasibility.

2.      Build high-fidelity prototypes with well-defined and consistent styles, with a good flows between the screens.

3.      Test your prototype with real users to ensure that your solution is usable, giving you the opportunity to make all the mistakes before you start to build it.

Building software in ‘easy mode’ has never been easier, as there are so many great tools nowadays that allow you to design high-fidelity prototypes, that also come with usability testing. Combine this with high levels of engagement with your engineers and users, and your marathon will become a sprint.