Build your own method (ee 3/6)
Knowing how to build a method also means being able to create a Design roadmap tomorrow.
There are two definitions of the term roadmap:
- a map, a ‘schematic representation of the main roads used mainly by motorists to find their route’;
- a roadmap, a ‘simplified graphical representation for effectively communicating and sharing a strategic intent in order to mobilise, align and coordinate the efforts of stakeholders to achieve one or more objectives’.
In my opinion, every designer should try to visualise their project as an object.
They should turn it around to see all its perspectives. They should hold it in their hand, weigh it and test its coherence; they should handle it to check its ease of use and accessibility; they should scan it and check all the connections and finally they should put it on the table and document it.
Design is not a linear method, it is a holistic methodological approach, even a domain in itself.
This approach must take all perspectives into account. To align and coordinate the efforts of the stakeholders, the designer will often have to travel the different routes on the map, checking that there are no obstacles to the smooth flow of information and ensuring the junctions between the routes, but more broadly he or she will have to connect all the routes of all the other types of transport.
The Design roadmap should not be only a roadmap, but one of the deliverables, a map.
To create this map, you need to know how to build your framework and/or your method and processes using all the methodologies available. So this is our subject ;-)
Design, a methodological approach.
For designers, discovery is the best-known method. Whether Scale or Focused, continuous or dual track, there are many ways to frame this discovery.
But it is rare for a universal method to correspond to the context of a Design department or team.
The context is the maturity of each player, the maturity of the project and/or product, and the maturity of the organisation. It also includes the distribution of functions between the players (product managers, designers, developers, etc.).
To adapt a universal method or create your own, you need to understand its structure and the origin of its tools, canvas & practices.
1. Operational
1.1 Method and process
Method = composition of steps, tools and practices established to obtain a deliverable; descriptions of the functions of the people involved in the project.
Each step starts with a necessary input which is the required output (deliverable) from the previous step. There may be several inputs and outputs at each stage and more complex variations than one input = one output, but this is a sound basis for facilitating a production chain.
Process = sequence of interconnected activities transforming inputs into outputs: clear description of roles and responsibilities.
- Methods and processes are interconnected;
- the process is the what, which can be represented by an operation flow;
- the method is its how.
‘The developers didn’t see all the feasibility problems when they first read the mock-ups!’
‘A new priority function is requested by the business owner!
‘The mock-ups are not respected!’
‘How do you choose your panel?’
‘How do you reassure stakeholders that they have control over the product?’
All these points, and many more, depend on the process.’
The process, often considered by stakeholders as a big unnecessary machine, often proves to be vital for the teams in their operational exchanges by guiding their way.
1.2. Methodology
Methodology = choice and combination of Methods and actions adapted to the problem in order to implement the approach.
Design Playbook contains the practices and tools available in the Framework. You’ll understand better.
While it is the methodology that enables you to choose the practices to be implemented in a method, it is the methodological approach (see below) that will determine the Framework and its Design Playbook.
The methodology breaks down a long method into phases to reveal its main principles.
1.3. Framework
The simpler and more linear the framework, the more replicable it will be and the more systematic it can be made. This will make it easier for those involved in the project to work together thanks to a known routine.
This linear framework works when all the functions are fulfilled (including roles and responsibilities) and the main function of the product is well established.
Organisations working in feature teams or squads can easily switch to this type of method.
2. Global view
2.1 Methodological approach
Approach = the way in which the objective is approached, based on broad principles and concepts.
The Design Playbook contains a number of tools and practices that can be used depending on the context. The term ‘Design Playbook’ does not imply that these practices are originally in the field of Design. In fact, this is rarely the case. The next note in this series will look at the methodological fields (outside design) that contribute to design through the methodological approach.
2.2 Design Roadmap
When we don’t mux up roadmap and method, we often think of a Roadmap Design Teams when we talk about Roadmap Design
Design Teams Roadmap = future planning of the various teams by domain (interactive, content, user) or by feature.
Design Roadmap = the path to follow to obtain the deliverables needed to weave the links between a group of experts and ensure the link between organisation and operations. Encourage the creation and industrialisation of the product and its innovation.
2.3 Example of a contextual roadmap
The example above shows a roadmap for the construction of a services sales site. The client had a low level of digital maturity and a high level of ‘business’ expertise. The aim was also to support them with a post-launch roadmap.
For these reasons, I proposed a Quality Matrix workshop (Quality Function deployment, I talk about it here) to :
- prioritise the essential functions
- define the KPIs
- identify the adherences in the functions
- estimate the technical and business load per function
- comparer according to benchmark
Re-analyse information requirements
To draw up this quality matrix, we had to collect a certain amount of information upstream, which can be found in a Business Model Canvas. To complete the Business Model Canvas, we needed the Value Model Canvas, which in turn required the empathy maps, etc.
As you can see, it was the final deliverable and the presence of information that determined this roadmap.
I’m convinced that building a design roadmap can be made even easier if you work in atomic mode (boilerplate) and work with these types of road’s plates. That’s another subject ;-)
Creating your roadmap can also free up your design by proposing more intuitive and personal creative practices to convey a singular vision…
What do you think?
