Rudie Can’t Fail
The Case for Evolutionary UI Prototyping Over Primary Feature Perfection
Over the past through years, innovation has become a buzzword in many technology domains. This includes the finance industry where I currently reside. Yet many consider it to be an extra function, rather than a core tenet of their daily responsibilities. Or even a one day event in those circles that host regular hackathons. Yet the fail fast mantra has a strong synergy to Agile development. No UI development technique could be more imperative to regular innovative development than prototyping.
Last week during my daily article perusal, I came across a piece on Agile misconceptions. The key item that caught my eye was preconceptions that adoption of Agile methodologies have stifled their ability to innovate. My initial reaction is that adoption of Scrum and Kanban for various teams has ignited a fire of innovation among our engineers. This is true in the production of our overall system infrastructure. However, UI design remains an area where we are unwilling to make mistakes.
Wireframes are one option to explore product designs. They are certainly worth considering when you have a dedicated designer. My musings on this were presented some time ago. Evolutionary prototyping is another powerful tool in our quest to fail fast. Particularly for development of the user experience. As a visual medium, everyone from developers to clients to designers has an opinion of what is considered usable and intuitive. Here I reflect on our struggles of building evolutionary prototypes, and the resulting impact on features.
Perfect Illusion
Programmers are perfectionists. Despite adoption of Agile practice, we still often struggle with showing work in progress. Yet we then become frustrated that we didn’t get it right first time. Or that the requirement still keeps changing an we want to lock it down to complete the work and move onto the next shiny feature. We should all hold up our hands to being guilty of this cardinal UI sin. Myself included.
Breaking the programmer psychology that I can only present a complete feature. The fear of feedback in a cycle needs to be broken. Showcasing of smaller increments does not make development of any feature appear less impressive.
The learning opportunities evolutionary prototyping presents are another ignorable advantage. Lack of UI development expertise has been a considerable challenge for us. To the extent that we wrote our own blended learning course to up-skill our existing engineering contingent. Evolutionary prototyping follows the same philosophy of learning by doing.
A Little Less Conversation
Regular demos have been attempted within several squads, with mixed results. The aforementioned developer perceptions is one hurdle. Another would be the rate at which client feedback can be obtained, along with the number of stakeholders involved in discussions.
Smaller, regular feedback on small changes has worked well in one space. This is down to having an extremely engaged pair of stakeholders that possess a strong vision for the product. In another space, time to market for equivalent features is longer due to the degree of dialog required to achieve client consensus.
Some upfront discussions will of course be required to identify the initial features. User story mapping is an invaluable tool for generating the initial story subset. Constructing client side features through evolution changes the conversations. Any artefacts serve as a conversation stater, as opposed to a validation.
Time After Time
Despite the justification for their usage, prototype production time will affect delivery times. Regardless, making space for evolutionary prototyping should not be discounted. Neither should we ignore the advice of Fred Brooks and simply throw more people at the problem. More people does not necessarily mean more time to prototype.
Adding manpower to a late software project, makes it later.
Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
Some companies adopt design sprints, but regular small prototypes can be just as powerful. Arguably, depending on the agreed deliverables, teams may still fall into the upfront design trap with design sprints unless they are embedded into regular practice. Discipline is required with either option to ensure regular feedback and experimentation.
Failure by Design
I don’t think regular design sprints are the silver bullet that we seek. Even if a dedicated designer was present in our squad, I doubt it would break the discussion deadlock that we have seen with some features. It will also restrict developer learning opportunities, as discussed previously.
Arguably it will reinforce the perfection paradigm that currently plagues our practice, and leaves us in endless discussion loops. It has been found that regular discussion of prototypes, even down to the smallest design aspect has lead to rapid turnaround of new features. Now it’s time to experiment with other teams to ratify that this technique works regardless of the client base.
Thanks for reading! Do let me know your prototyping experiences, regardless of whether they are similar are different. Claps are as always appreciated.
