A new project always brings enthusiasm, expectations and a certain amount of caution. When we start talking with a new team that is considering working with us, one question almost always comes up: what is your approach?
For us, the answer cannot be a single one. Over the years we have learned that many problems in digital projects stem from an initial mistake: applying the same method to very different contexts. It is one of the reasons why projects often don’t go exactly as planned. There are projects that can be tackled in a linear way, others that require in-depth analysis, and others still where the path only emerges by working through hypotheses and iterations.
To orient ourselves we also use the Cynefin framework, a decision-making model developed by Dave Snowden that helps distinguish different types of context and choose the method best suited to the actual situation.
So when we discuss a new digital product, the first thing we try to understand is not only what needs to be built, but what context we are operating in.
Cynefin identifies five domains: simple, complicated, complex, chaotic, and disordered. Each corresponds to a different context and therefore requires a different approach. Looking at a project through this lens helps choose the method with greater awareness. Here is how we apply these domains in our work.
Domain #1 – Simple
The simple domain concerns projects where the picture is clear from the start. Requirements are known, the solution is largely predictable, and external dependencies remain limited. The work does not proceed by discovery, but by execution.
This happens, for example, with a one-pager, a marketing site, or a brand sprint for a startup when positioning has already been well understood together with the founders. In these cases you can follow an orderly plan, with fairly defined phases and a horizon often of a few weeks.
It is not a domain that requires less quality or less seniority. It mainly requires the ability to turn a clear direction quickly into solid output, without unnecessarily complicating the path.
Domain #2 – Complicated
The complicated domain concerns projects where the goal may be clear, but the path to get there requires analysis, expertise, and alignment.
This often happens, for example, in a UX/UI design project where you need to understand the business domain well, gather know-how from different stakeholders, and clarify priorities and constraints before designing. The same applies to a web platform with ERP integrations to analyse or to a replatforming that requires studying an existing system.
In these cases, at Moze, we don’t jump straight into execution. We open the project with an initial discovery phase, made up of workshops and structured work sessions that serve to clarify objectives, requirements, constraints, and priorities, but also—when needed—to understand the starting as-is.
Over time we have also defined a format we call the Co-design Workshop, useful for moving from an initial concept to a shared set of specifications or to a navigable prototype to align on.
Only when the scope has been defined with sufficient clarity does it make sense to start the actual implementation phase, in design or development. The point here is to understand what to do before doing it.
Domain #3 – Complex
The complex domain concerns projects where the context changes while you work. In these cases, trying to define everything upfront can even be counterproductive: it slows the project down and leads to building plans that become obsolete too quickly.
This happens, for example, when developing a new product, when the direction takes shape as you do customer discovery and test the market response. Or in situations with external dependencies, requirements that can only emerge progressively, technical constraints or legacy systems that you only really understand by starting to work on them. Here you can neither execute a linear plan nor do an initial analysis and then commit to a rigid plan.
In these cases, at Moze, we do an initial discovery to define a first direction and then we work in sprints, as an extension of the client’s team. It is an approach we use both on products that are complex on the UX/UI side and in iterative and incremental development, when the software takes shape little by little. Over the years we have seen that this model works well especially in digital innovation contexts, where change is a constant.
The chaotic and disorder domains
The chaotic domain concerns situations where there is no readable path upfront and the priority is to act quickly to restore control. It can emerge in extraordinary software maintenance, in the urgent management of vulnerabilities, or in updating packages and dependencies. In these cases the focus is not on planning well, but on reducing risk and restoring stability.
The disorder domain is when it is not yet clear what the real nature of the problem is. It is a fairly common condition at the start of a project, when there is a lot of information but a shared reading of the context is still missing. This is where framing work begins: understanding which domain you are in, in order to choose the most suitable method.
What is your approach?
So to the question “what is your approach?”, the right answer for us is always: it depends on the context. Not all projects ask for the same method, and trying to tackle them all in the same way is often the quickest way to create friction, delays, or wrong expectations.
Using this lens helps above all to start with the right frame: understanding when it makes sense to execute, when you need to analyse first, and when instead you have to work in iterations, accepting that part of the direction will emerge along the way. It is not a guarantee that everything will go smoothly, of course. Even the most suitable method does not eliminate the risk of problems or surprises entirely.
What it can do, however, is surface the real knots earlier, especially when there are more structural critical issues. We have, for example, accompanied two teams from two different companies in a co-design phase around the idea of a possible joint venture for a new digital product. Precisely thanks to the discovery and facilitation work, it became clear that the operational conditions for the initiative to really work were not there. At that point, the project did not continue.
These are edge cases, but they happen. And even in situations like this, realising before starting the actual project is not a failure: it is already a useful result. Framing the context well is not about promising absolute certainty, but about making better decisions before time, budget, and energy are invested in the wrong direction.
