Before the session begins, a team that wants to get advantage of BRIDGeS should ensure it has all the necessary things in place. Our complete guide on the BRIDGeS preparation can help a lot.
BRIDGeS framework is applicable for both live and online team sessions. You may use any suitable tools: physical whiteboard and sticky notes, or online tools like Figma (check out the template), Mural, Miro, and other virtual whiteboards.
In BRIDGeS sessions cards are used to visualize the context and build flows by adding and moving them on the virtual or physical board. As a result, you get a snapshot of the whole context, which is easy to analyze and design solutions.
While working with the board, we recommend using a particular color and shape coding. For example the Subject is displayed with a big green card, descriptors are smaller and displayed as follows - Benefits are green, Issues - red, Risks - yellow, Domain knowledge - violet and the Goals are blue.
Divide your board into 2 spaces: Problem Space is meant for describing the context of the problem and Solution Space is for the solution details.
Start working on the Problem Space with a Problem description. It is a brainstorming session to define Subjects and their descriptors - Benefits, Risks, Issues, Domain knowledge and the Goals.
A Subject can be a user, role, institution, tactic, strategy, solution, activity, event or anything being discussed, described, or dealt with. Subjects represent stakeholders involved in the context, those who will benefit from the solution. The goals are usually connected to the main stakeholder (Core Subject) that has an intention to spot the problem and resolve it.
When working on the problem description, carefully consider each Subject descriptor one by one and add them to your Problem Space. Write down every Benefit, Risk or Issue you need to consider and do not hesitate to add extra notes if needed. The Domain knowledge notes are crucial in conjunction with this list as they can significantly influence the future Solution. Pay attention to the Goals of the key Subject as they will be your guides throughout the ideation Process.
Analysed context usually consists of multiple Subjects and their descriptors, that makes the backbone of the BRIDGeS framework. Different Subjects may have common Benefits or other descriptors. You don’t need to keep duplicates. Just leave one in between, so you know it is related to both subjects.
After you are done defining all Subjects and descriptors, set the right focus for the Solution stage. Prioritise all Risks, Issues and Benefits not to waste time on non-essential things. Mind that the type of descriptor doesn’t influence the priority. E.g. a Benefit may be of a higher importance than some Issue or a Risk. There are many prioritization techniques that you might like to use. We at Railsware prefer MoSCoW method. If you choose this technique, simply tag all Subject descriptors with MoSCow markers, defining what Must, Should, Could or Won’t be done.
Move to the Solution Space after the context of the problem is described and prioritized. Start with making up potential high level solutions that will satisfy needs listed in the Problem Space. Mark Solutions as big blue cards.
The beauty of BRIDGeS is that you can apply it recursively. In this case a Solution becomes a Subject which you can also analyse through the Benefits, Risks, Issues, and Domain knowledge. This will help you to find the optimal solution direction.
In case you had a non-complex task or day-to-day decision, this might be your last step as the solution becomes obvious.
However, you can go way deeper with this framework and proceed to the next step - Solution breakdown. This is where the magic happens if you have a complex project running (e.g. new product, game changing feature).
At this closing stage you describe the high level Solution through epics and the nested tasks. The context of the Problem Space influences how epics and tasks are detalized. You can dive as deep into details as the specific problem requires.
At this stage color coding is different. Each epic with its tasks should have their own colors. This time you may choose any colors you want. Just make sure there is a visible difference between colors of the different epics.
Go iteratively through the descriptors from the Problem Space and cover them with the related epic or a task. You need to make sure that at the end of the cycle each descriptor is addressed with a particular task in the Solution Space. It is not always a one to one match. One task can cover several Benefits, Issues and Risks. And vice versa one descriptor can be covered by multiple tasks. While mapping two board spaces, you can easily add more descriptors and solution details if you find new aspects of the context.
To prioritise your solutions details we recommend using the same prioritisation framework as in Problem Space. In our case it’s MoSCoW. Often the priority of the tasks is inherited from the descriptors they cover. But not always. You may have a situation when the business value of the task isn’t high, but there are other important tasks which depend on this one. In this case evidently the priority goes up.
The BRIDGeS framework is designed to provide users with a universal tool for problem solving as well as for product ideating. What is more, the approach allows you to get a clear instruction of what to do next when the solution is found!
If you apply BRIDGeS for a non-product matter, you get a clear implementation plan. If you use BRIDGeS for a product ideation, you get a list of epics and tasks that you could easily transform into a colored legend and then into a product development roadmap.
In case of non-product matter, you get an implementation plan after you are done with prioritization. With a product case you can transform your epics and tasks into a roadmap. Then your epic cards transform into the colored legend, while tasks are sequenced by priorities and other factors like time of execution, resources availability, etc.
