diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 5f3a2b45c5c..637ff17d7bc 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -4,7 +4,7 @@
   pageNav: 3
 ---
 
-# AB-3 Developer Guide
+# AddressBook Developer Guide
 
 <!-- * Table of Contents -->
 <page-nav-print />
@@ -123,19 +123,11 @@ How the parsing works:
 
 The `Model` component,
 
-* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
+* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object) and all `Tag` objects (which are contained in a `UniqueTagList` object).
 * stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList<Person>` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
 * stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects.
 * does not depend on any of the other three components (as the `Model` represents data entities of the domain, they should make sense on their own without depending on other components)
 
-<box type="info" seamless>
-
-**Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.<br>
-
-<puml src="diagrams/BetterModelClassDiagram.puml" width="450" />
-
-</box>
-
 
 ### Storage component
 
@@ -158,6 +150,28 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa
 
 This section describes some noteworthy details on how certain features are implemented.
 
+### \[Proposed\] Event switching feature 
+
+As our target audience are student leaders, and they may be in-charge of multiple events throughout their course in NUS, we are proposing to implement a event-switching feature which allows them to switch between events and view contacts specific to each event.
+
+The proposed event switching feature introduces the concept of event-specific filtering to the existing EventBook. The key operations and components of the proposed implementation include:
+
+* Filtering Mechanism: filters contacts in the EventBook based on event tag, allowing for selective display of contacts based on event tag. 
+* UI enhancements: allow users to see each event as a tab and after navigating to a particular tab, they will be able to view contacts of members under that event.
+
+An example usage scenario illustrates how the event switching feature operates:
+1. The user launches the application. The application will be in its initial state showing the full list of contacts in the EventBook.
+2. The user switches tabs to a particular event by executing `switch eventTagName`. The `filteredPersons` list in `Model` class will be updated and user will be able to see all contacts of members under this event.
+3. User can further filter contacts by executing `search tagName`. This displays users in this event with the specified tag.
+
+Alternative 1 (Proposed Choice): Extend the existing Tag class to accommodate event-specific tags, allowing for flexible filtering based on events.
+Pros: Utilizes existing data structure without introducing additional complexity, easier to implement.
+Cons: Requires modifications to the tagging system to support event-specific tags, less OOP
+
+Alternative 2: Introduce separate address books for each event, providing a clear separation of contacts by events.
+Pros: Offers a straightforward organization of data by events.
+Cons: Increases complexity by managing multiple address books, harder to implement.
+
 ### \[Proposed\] Undo/redo feature
 
 #### Proposed Implementation
diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml
index 0de5673070d..e18df9c3d68 100644
--- a/docs/diagrams/ModelClassDiagram.puml
+++ b/docs/diagrams/ModelClassDiagram.puml
@@ -12,6 +12,7 @@ Class AddressBook
 Class ModelManager
 Class UserPrefs
 
+Class UniqueTagList
 Class UniquePersonList
 Class Person
 Class Address
@@ -35,17 +36,21 @@ ModelManager -left-> "1" AddressBook
 ModelManager -right-> "1" UserPrefs
 UserPrefs .up.|> ReadOnlyUserPrefs
 
+AddressBook *--> "1" UniqueTagList
+UniqueTagList --> "~*" Tag
+
 AddressBook *--> "1" UniquePersonList
 UniquePersonList --> "~* all" Person
 Person *--> Name
 Person *--> Phone
 Person *--> Email
 Person *--> Address
-Person *--> "*" Tag
+Person --> "*" Tag
 
 Person -[hidden]up--> I
 UniquePersonList -[hidden]right-> I
 
+
 Name -[hidden]right-> Phone
 Phone -[hidden]right-> Address
 Address -[hidden]right-> Email
diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml
index a821e06458c..6e29baf4210 100644
--- a/docs/diagrams/StorageClassDiagram.puml
+++ b/docs/diagrams/StorageClassDiagram.puml
@@ -40,4 +40,6 @@ JsonAddressBookStorage ..> JsonSerializableAddressBook
 JsonSerializableAddressBook --> "*" JsonAdaptedPerson
 JsonAdaptedPerson --> "*" JsonAdaptedTag
 
+JsonSerializableAddressBook --> "*" JsonAdaptedTag
+
 @enduml