Recently, we used our UX Power Days approach (an adaptation of the infamous Google Ventures Design Sprints) once again in a client project. The task: to define the scope of a digital solution for an assumed future problem in the radio industry. Normally, we conduct all joint activities in an intensive workshop week. For organisational reasons, however, we had to stretch the process over several weeks this time. The result is quite useful, but on closer inspection not nearly as concrete, coordinated, implementable and testable as I am used to from this approach. This made me wonder. Was it because of the stretched turnaround time, or might another approach like LeanUX have been more appropriate?So let's compare the two approaches:Basically, they both serve to solve design problems, but they target different challenges and thus have different advantages.

UX Power Days

These are best for solving well-defined, moderately complex problems. They are particularly effective for digital solutions of medium scope, such as a core function of an app or software. The main advantage of UX Power Days is that stakeholders are integrated into the process, which means that their thinking and input becomes part of the solution. The outcome of the UX Power Days is a solution idea for the core feature together with a tangible user flow. This is tested and validated with real users. The actual development with wireframes and screen designs, however, takes place without the involvement of users. In order to ensure that the UX Power Days realise their potential, there must be a clearly defined problem. Looking back at the project mentioned at the beginning, it also seems important to me to hold the workshops in a limited time frame (e.g. 2 x 6 hours on site or 3 x 4 hours remotely). Spreading the activities over several weeks or months significantly affects the dynamics of the process, leads to blurring and reduces the development of a common goal picture.

LeanUX

This approach seems to me to be more suitable for spreading the activities over a longer period of time (perhaps a few weeks). It also allows for asynchronous remote processing by team members, making it much more flexible to use.
This is probably due to the associated canvas that supports the process and allows teams to understand the problem to be solved. This identifies the most important points to be validated before the concrete solution is created (wireframes, screen designs).
The Canvas is divided into four main sections. The first section "Problem" helps to understand the problem to be solved. The "Solution" section identifies the key elements for a possible solution. This is followed by the "Metrics" step, which defines how the success of the solution can be measured. Finally, the "Assumptions" section formulates hypotheses that need to be tested.

It's the combination that makes the difference

Both methods have their advantages and disadvantages and aim at different results. To choose the right set of methods, it is important to understand the goals and needs of a project or the current project stage.

A new idea could be to combine both approaches and use them for a more comprehensive product development process. In this way, the most important points to be clarified in advance would be answered in LeanUX and then concrete solution ideas would be developed in the UX Power Days.

‍

‍

‍