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.

Evolution of man to modern day with phone
Evolution of man to modern day with phone
Interfaces should evolve to encourage failing fast and learning from our mistakes

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.

Stack of books
Stack of books
Evolutionary prototyping is a useful tool for team learning. Endless reading will only get you so far!

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.

“We like you too” text on a wall. A very succinct piece of feedback.
“We like you too” text on a wall. A very succinct piece of feedback.
Small, regular feedback is far more effective in driving feature direction than many upfront conversations

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.

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.

New York City Gridlock Alert Notification
New York City Gridlock Alert Notification
Endless discussion cycles can leave features blocked

Lead software engineer with a strong interest in Agile, UX and Usability. Lover of cooking, tea, photography and gin!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store