Design-athon: When and where to use it in the Design Process.
Mapping is one of the most essential and indispensable exercise to define and detail a relevant and valuable offering. As a designer, I have always been averse to the idea of ‘Design Hackathon’ primarily because it trivialises the process of mapping in particular, and Design Thinking in general. Hackathon in essence seems like a brute force method to arrive at a solution.
However, a shift in the perception and its usage could yield to altogether different results. Design Hackathon could be useful if employed as an early part (/iteration) of the design process and not as its alternative.
Designing a system requires UXers to get rich inputs from stakeholders. In a multi-stakeholder scenario, taking inputs can be tricky business. Sequential interviews can lead to several problems such as biased, opinionated, unfeasible and individually motivated viewpoints coming into consideration. These can lead to ill-informed decision making or at worst: non-negotiable dead-ends. Even with unbiased inputs, there is a possibility of stakeholders being unaware about other aspects contributing to a product.
Design Hackathon can be utilised here to create more comprehensive picture. Bring together all the stakeholders: people defining the system, the planners, implementers and (diverse persona) users at a common place for a hack. When different parties related to a defined context interact, share and discuss their ideas, in an enclosed setting, it becomes easy for everyone to know, understand and analyse various perspectives. And when we add the restriction of time and implementation, the output tends to be both pragmatic and innovative.
While the primary outcome of hackathon is a balanced and weighted mapping of complexity at hand, the secondary outcomes are early-momentum, stakeholder alignment and as a bonus: couple of handy solutions.
Also, stakeholders themselves are able to visualize solutions more clearly, and add deeper insights. The frugal solutions can also be used for validation of early assumptions.
Make no mistake however, this is only the start of design process. Learning from here will go as input into a larger exercise (double-diamond in image), to lead to relevant, co-created and well thought-through solution(s).