Decision tree modeling

Alex reed
4 min readOct 22, 2020


Part of the problem with trying to uncover user needs and desires is that you must first get into the mindset of the user. That means empathizing with the user and understanding their goals. We may start a project with our assumptions and those sometimes prove correct some of the time, but in general we need to do our homework to put out a high performing product. This takes time though. In the world of rapid iteration and week-long sprints we know that some of that important work never gets done. Yet the user needs still need to be sought and we can not speak for the end user.

“You are not the user…”

We have all been trained on this early on. Failing to understand this can have dire implications on the outcome of product designs. You might end up making designs for your ego and not for the public. There is a definite need to rush products out the door in record time. Business needs to make money. Competition can be fierce. So some of the research and discovery phase gets pinched in order to prioritize the design/prototyping process.

We have to get back to the point where we are giving credence back to the user needs. I came up with a small addition to the research/discovery phase that can help maintain the processes while maintaining the speed necessary to keep it relevant and keep us from relying on assumptions.

Now I realize that the title of this article normally refers to statistical and machine learning models or a branching point of computational algorithms; Here I am using it to name a new method. Decision trees also refer to charting a user’s thought process in making a decision on a subject. It is usually shown as a visual graphic. Similar to a sprint board, but with less text and jumble. Although I should add, feel free to add all the text and jumble you want.

Designers updating a sprint board.

Decision tree modeling is the underpinning of the research and discovery phase of product development. The decision tree modeling is a visual tool to aid the UX designer in expediting the process and guide the research and discovery phase. It is not meant to replace any other methods or sprints. It is simply a visual guide that can be slapped up on the office wall and supports the process by acting like a ‘table of contents.’

After the project scope is established, the team will graph the main decision and pivot points as a timeline. Each action or needed step should be noted. Dates should be included when known. Rather than a strict structure like an agile sprint, this model allows flexibility so that different steps may elicit differing amounts of time spent. It can be adjustable as well. If one point is reached earlier than expected, more time can be placed elsewhere or move up the pace of the phase.

A basic decision tree model. A simple path forward with loose structuring.

The design is intended to provide a direction and indicate possible pivot points for consideration. This framework would be similar in fashion to how an agile sprint works only looser. In effect it treats the the research phase as one entire sprint. Also since this is considered a visual tool it can be referenced quickly and easily. Sprint boards and task-tracking apps can be cumbersome to comprehend, so the decision tree model provides a birds-eye view for quick consumption. For further detail one can still refer to their preferred task app.

You know where I’m going with this right? More visibility (and visuals) for us designers to follow. We love looking at visuals and icons and graphs. We do love research documents too, but I’ll save that discussion for another day. We need something to look at to keep us focused. Remember that whole visual, auditory or kinesthetic learning styles thing? I think most of us fall in the first category. So without further ado I will leave off with a few examples of how this decision tree modeling will work.

A more detailed version of a decision tree model. The canceled pathway at top shows the flexibility in the process.

Tell me what you think. I designed this project method with the intention of having a simple process flow to follow. I like and use more established methods, like Agile, but I feel the need to have an additional visual to support the process and provide quick situational awareness to the research/design team.