Why crazy? Because the requirement gathering phase, that we aim at replacing with our “Capture-Concept-Prototype” approach (in 6 weeks), generally takes several months.
When presenting it during a kick-off meeting at a client, I even got this [rhetorical] question at the end of my presentation: “How could we suddenly realize in 6 weeks what we barely manage to achieve in over a year?” Now this is the kind of comments that really drive me! I answered that person that I’d like him to judge me on the results and gave him a rendezvous 6 weeks later…
Why 6 weeks for our approach? Because we need to go through the 3 following phases, and based on our experience, each needs at least 2 weeks in order to deliver the expected quality:
- Understand the context, figure out who are the target users and interview them to depict the current situation or their expectations for a possible future situation
- Identify concepts that can address the opportunities revealed during the first phase, and translate them into wireframes that can be tested with end-users
- Transform the wireframes into a prototype that allows to visualize the solution and get it tested with end-user representatives
Why not sticking to the usual 2-3 months? Mainly because I strongly believe that speed brings 2 key benefits: focus and motivation.
So did the Alpinist Ueli Steck, aka the “Swiss Machine“, who was the first to climb Annapurna solo via its notoriously challenging South Face (doing it in only 28 hours compared to 2 months for the previous successful expedition), and set speed records on the North Face trilogy in the Alps.
Although our projects are not comparable with free climbing as we don’t risk our life at every ascension, I believe that we have something in common in the sense that we put our personal reputation at risk at every new assignment. And without the focus that we must keep to reach our deadline, our actions could be distracted by the temptation to do a better design, to bring more features to our product, to think about a better concept, what might lead to a suboptimal solution. In other words, speed forces us to focus only on essentials.
Moreover, having such tight deadline require all team members to be fully dedicated to this project, what allows an intensive, but necessary velocity. However, I very often get challenged on the duration by both clients and colleagues that would like to get more time, mainly arguing that we need enough time to deliver quality (argument from colleagues) and we need enough time to allow the organization to accommodate with the changes (argument from clients).
I fully understand theses challenges as we’re still very used to the “traditional way” of approaching requirements, and we’ll need more time to get fully used to the Agile, iterative way to approach development. The prototype shouldn’t indeed be considered as a final deliverable, but rather as the first milestone that will be refined and elaborated during the development on some of its aspects. Indeed, while the developers work on User Stories to be delivered in the first sprint, the service designer, UX designer and UI designer continue refining the prototype by adding the potential missing screens or flows. And that represents a real paradigm shift.
Finally, for Ueli Steck, going as fast as possible was not a goal as such, but a way to increase his security (he considered that more time he stayed in a face of a mountain, more dangerous it was for him), as he explained in his book “Speed”. And for our team, going fast also contributes to decrease the risk of getting stuck on details or endless discussions (e.g. expert debates) that generally end up in compromises that flatter egos but may heavily affect the quality of the user’s experience.
Do you also believe in speed? Or at the contrary, do you believe that we should take more time to design our concepts & prototypes in a slower and more cautious way? Leave a comment below!
Feel free to take a look at how we depict the full digital delivery model to get the big picture.
