diff --git a/_memo/builder-design-pattern.md b/_memo/builder-design-pattern.md
index 75dee0ab..d11f0855 100644
--- a/_memo/builder-design-pattern.md
+++ b/_memo/builder-design-pattern.md
@@ -16,10 +16,10 @@ hide_title: false
 
 ![](assets/builder-design-pattern.pdf)
 
-### Problem statement
+## Problem statement
 We want to create complex object without worrying too much about the hows, we could use Factory pattern to abstract away those details and just give us the output, but the drawback is you get a fixed same object everytime. There will be cases where you need to tweak some properties of that object to get the desired result, look no further than the Builder pattern.
 
-### Builder design pattern
+## Builder design pattern
 Create a Builder of the object you wanna build, e.g. QueryBuilder, ButtonBuilder, etc,...
 
 Add methods that act as steps to gradually build your object, this method must return an instance of the builder itself to allow method chainning (not required but a very distinct feature of this pattern).
@@ -72,7 +72,7 @@ new DrinkBuilder()
 
 Notice how by defining each step as method we (the consumer, one that uses the builder) can easily add/skip/modify certain properties of the object, this would all have been hidden away by the Factory class. And the method chaining helps with the readability too.
 
-### Real life examples
+## Real life examples
 jQuery was one of the early pioneers to adopt this pattern in their APIs, those little `$(something).on("click", func).toggle("class")...` is the Builder pattern in action. In fact, the javascript ecosytem is very fond of this pattern, some other libraries that make use of this are:
 
 - [wretch](https://github.com/elbywan/wretch) - a wrapper for native Fetch API with intuitive syntax
@@ -80,7 +80,7 @@ jQuery was one of the early pioneers to adopt this pattern in their APIs, those
 - [Spotify Nodejs wrapper](https://github.com/thelinmichael/spotify-web-api-node) - A wrapper for Spotify's web api
 - and many others...
 
-### Pros & Cons
+## Pros & Cons
 Pros:
 
 - Readablity: each step of the builder communicates clearly what it's doing and what parameters it requires.
@@ -90,5 +90,5 @@ Cons:
 
 - For each object that you wanna build, you will need to create a separate Builder class for it, this can quickly become a problem as the codebase grows.
 
-### Reference
+## Reference
 - https://refactoring.guru/design-patterns/builder 
diff --git a/_memo/prototype-design-pattern.md b/_memo/prototype-design-pattern.md
index 9561bcd5..bceb0d20 100644
--- a/_memo/prototype-design-pattern.md
+++ b/_memo/prototype-design-pattern.md
@@ -17,13 +17,13 @@ hide_title: false
 
 ![](assets/prototype-design-pattern.pdf)
 
-### Problem statement
+## Problem statement
 
 We want a copy of an object, but the config only initialized at runtime, its fields and methods were private, or its properties were manipulated through multiple processes, so it is difficult to recreate the object. For example: 
 - DB Access Object with credentials only provide in runtime.
 - A ledger object has transaction histories, which are protected through private fields, and exposes a Total() function to get the total balance. To replicate the whole ledger, we must recreate all its transaction histories.
 
-### Prototype design pattern
+## Prototype design pattern
 
 Request a Clone of the object(Prototype) without the need to look up its class and implementation.
 
@@ -57,7 +57,7 @@ type (h *Hero) Clone() Hero {
 }
 ```
 
-### Case by case
+## Case by case
 
 When developing a system, the Prototype design pattern works in tandem with other creation patterns:
 - Factories, abstract factories, and builders help create the original object. Prototype provides a clone of the object without the need to call the above patterns
@@ -68,6 +68,6 @@ The most common use cases for Prototype design patterns are:
 - Ledger/Bank statement objects, we clone the object to the statistics and simulations.
 
 
-### Reference
+## Reference
 
 - https://refactoring.guru/design-patterns/prototype