Continuing our theme of Frog Software Design Principles (First Post):
We need absolute clarity on what the users are trying to achieve, and more importantly, WHY. This is standard stuff, to be honest, especially the need to understand WHY people want something (but you’d be amazed how often software developers forget this and jump straight into trying to solve a problem they don’t fully understand).
For clarity, I’m not suggesting that we allow our customers to design our software. It’s very easy to put too much confidence in the requests made by end users, “I just want a button that does this on the software. Yes, just there, on that screen. That’ll do it. Great, thanks.”
There are two very significant issues with this approach:
1. Software, under this model, ultimately becomes a system designed by a “committee of people, with no collective training in software design or any understanding of the underlying principles behind this software.” Any consistency, flexibility or maintaining of the underlying architecture’s integrity are lost. Software becomes affectionately known as “bloatware”, more and more buttons getting layered on top of each other.
2. It presumes that your users fully understand the problem, which typically they don’t, at least not in terms of how to apply technology to it. Software is too often developed to meet a client need only to get the response, “this is great, but it doesn’t cope with ….. which I didn’t think of at the time, but if you just add some more buttons here, here and here I think that’ll sort it. Okay? Thanks.”
This isn’t the customers’ fault. When you go to your local car dealer, you don’t expect him to ask you how you want your car designing – that’s left to the experts, the guys that understand NCAP safety standards, aerodynamics, ride and handling dynamics…
So, we might not be able to get all the information we need from our users, so we’ll just make a few assumptions and hope for the best? No, not ideally. The best course of action is to get fully engaged with the issue itself. We use the concept of “dry runs” regularly at Frog. What we’re doing here is a combination of role play and drawing lots of computer screens on scraps of paper – pressing the paper buttons with our fingers, with someone pretending to be each user, fulfilling each role in the process.
The critical part of this stage is to COMPLETELY IGNORE OUR CURRENT TECHNOLOGY, OR ANY IDEA OF HOW WE MIGHT IMPLEMENT IT. We need to start from a perfect world, otherwise the conversations quickly deteriorate back to what’s easiest for the developers. The end result of this exercise may be extremely uncomfortable for the development team, often resulting in comments like, “but that’ll take ages”, or “but that’s not possible, it won’t work”.
Some of our greatest innovations have come from the constraints we’ve applied to a problem. Without constraints it’s easy to just add a button. With severe constraints on what the end result needs to be, all sorts of exciting things start happening in the development process. Our Secure Gateway product was born of an original vision, “we need our customers to be able to access and use any software their organisation has a licence for, from home, without installing anything, just by clicking a link on a web page.” It turned out that it was possible after all ;)
The most difficult part of this step is resisting the temptation to “solve” the problem, especially for us blokes! We’re not looking for a solution at this point, we’re looking to understand the problem thoroughly, from as many different directions as possible.
9. Throw more problems into the mix