new article ?!
This commit is contained in:
BIN
src/assets/article_hero_images/decision-tree.jpg
Normal file
BIN
src/assets/article_hero_images/decision-tree.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 158 KiB |
@@ -0,0 +1,114 @@
|
||||
---
|
||||
title: 'using decision trees for self documenting design reports'
|
||||
description: |
|
||||
decision trees are a tool more commonly used in contexts of probability modeling as well as business decision mapping. However, this article uses them in the context of product design as a method for continuous documention of design.
|
||||
heroImage: '../../assets/article_hero_images/decision-tree.jpg'
|
||||
pubDate: 'May 21 2026'
|
||||
---
|
||||
|
||||
Some background I enjoy to help out with some of the design courses at uni and act as a stakeholder in a product.
|
||||
These students then have to go out and design either some project that i had rattling around in the good old head hole or one of their on creation.
|
||||
Once they have designed it they then must write a design report and throw it as me so they can get marked.
|
||||
When reviewing these design reports I have seen both great reports and terrible reports (and even worse reports that make me question how they made it this far).
|
||||
Throughout that time I noticed the main thing that separates a great report from one that I would use as kindling, that being comparisons of different choices.
|
||||
To give and example this would be like a student comparing many different microcontrollers before selecting the one thats best for the job rather than just writing "i picked this one because ive used it before" (not to say that this is a bad rational for picking a MCU but it is bad rational if you didnt compare it to any others) or even worse they dont even specify the MCU.
|
||||
However, I believe (possibly naively) that students have thought of the alternative but have just not included them in their reports.
|
||||
This then leads to them not writing as much rational and therefor not creating an convincing argument for why this choice was made.
|
||||
As if you have not yet worked it out yet a design report isn't a report that tells the reading what you designed a design report is you attempting to convince the reader that your design is the best design.
|
||||
|
||||
So to solve this problem of not writing down alternatives during the design/research phase i have adapted the concept of decision trees. Decision trees are more commonly found in probability modeling, business decision mapping and many other fields.
|
||||
Firstly the syntax, normal decision trees tend to only have 3 node types:
|
||||
- decision
|
||||
- chance
|
||||
- end
|
||||
|
||||
These node then allow the user to map out a tree of possible decision and the optimise for their given path.
|
||||
these although good are not enough for the more complex system that is design.
|
||||
|
||||
Therefor my suggested syntax/nodes are:
|
||||
- `+` : problem <br/>
|
||||
this is the main problem you are attempting to solve some time solutions can create new problems. An example of this is if a motor draws too much power and now you have a new problem to deal with
|
||||
- `>` : solution <br/>
|
||||
this a solution to a decision
|
||||
- `?` : decision <br/>
|
||||
this is the node where decision are made like what microcontroller should we select
|
||||
- `^` : pro <br/>
|
||||
this allow the user to write down the pros for the given solution
|
||||
- `*` : con <br/>
|
||||
this allow the user to write down the cons for the given solution
|
||||
- `!` : depends on [^1] <br/>
|
||||
This allows for decision to depend on other decision within the system. lets say something needs to be actuated, the choice of actuator will depend on the power system available
|
||||
- `#` : tag <br/>
|
||||
this is used to tag multiple items when something depends on them
|
||||
- `${id}` : requirement <br/>
|
||||
this allows for the addition of requirement for a given decision
|
||||
- `-` : <br/>
|
||||
comment, reasoning, explanation
|
||||
|
||||
(i have given them characters has it's easier to identify when typed)
|
||||
So how does this syntax solve the problem of students not writing down their design during research; well it doesn't that's still on the student to do.
|
||||
However, this does allow for a fast way to check over your design to check if there are any gaps in your design. Therefor lets use this in an example project.
|
||||
Additionally, pros and cons can also be used to show that a given solution meets a given requirements ID.
|
||||
|
||||
## Example project
|
||||
|
||||
problem statement: need a device for continuous monitor for the temperature of a system over WiFi
|
||||
|
||||
Requirements: (i would write some here but thats not the main point of the article)
|
||||
...
|
||||
|
||||
|
||||
```
|
||||
+ need a device for continuous monitor for the temperature of a system over WiFi
|
||||
? off the shelf device
|
||||
> google nest temperature sensor
|
||||
> idk some other tempture sensor
|
||||
? bespoke device
|
||||
? microcontroller
|
||||
$1.1 the micro controller shall have WiFi
|
||||
$1.2 the micro controller shall have an interface to commuicate with a temperature sensors
|
||||
> esp32s3
|
||||
# bulitin temp sensor
|
||||
^ 1.1
|
||||
* more expensive
|
||||
? stm32
|
||||
# bulitin temp sensor
|
||||
> stm32wb
|
||||
^ built in wifi
|
||||
* requires RF routing
|
||||
> stm32g4
|
||||
# wifi-less
|
||||
> rp2040
|
||||
# wifi-less
|
||||
> atmega
|
||||
# wifi-less
|
||||
|
||||
? wifi
|
||||
! wifi-less
|
||||
> nrf24
|
||||
> WINCS02PE-I/100
|
||||
> esp8266
|
||||
|
||||
? temperature sensor
|
||||
?! bulitin temp sensor
|
||||
- the inbuilt temp sensor my not be good enough
|
||||
> tmp100
|
||||
? thermistor
|
||||
...
|
||||
? thermocouple
|
||||
? adc
|
||||
...
|
||||
? spec
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
So as you can see in the example project we are attempting to solve the problem of remotely measuring temperature using WiFi.
|
||||
So starting off we make the decision whether we make our own device on get one off the shelf.
|
||||
For the bespoke deice we recognize that we need a microcontroller, Some way to communicate over wifi and some way to measure temperature.
|
||||
Additionally, we can see in the decision to pick a Wi-Fi module that it depends on if we select a wifi-less MCU which is denoted by the tags.
|
||||
Again you can notice with the temperature sensor the bulitin temp sensor dependency also has a decision mark this is to show that this dependency is optional so even if it is met then you can still pick another one for a different reason.
|
||||
Now using this tree you can keep adding to it more rational more requirements
|
||||
|
||||
|
||||
[^1] : and yes, the depends on does now in technically make this a graph but if you end up with a circular dependence in your design that's your fault
|
||||
Reference in New Issue
Block a user