diff --git a/README.md b/README.md
index 83458ee..ad88777 100644
--- a/README.md
+++ b/README.md
@@ -7,16 +7,4 @@ The project is based on [Kubebuilder](https://github.com/kubernetes-sigs/kubebui
# Design
-The controller listens for Custom Resource which defines client registration request. Once Custom resource is created, the controller register oauth2 client in hydra using hydra's REST API.
-Client Id, Client Secret and Identifier of the client in hydra are be stored in the kubernetes as a secret and referenced in the applied CR.
-Reference is used to identify in which kubernetes secret are stored mentioned properties. Secret iscreated in the same namespace of applied CR.
-By default controller should be deployed in the same pod as hydra. Service discovery will come in place in the future.
-
-
-## Synchronization mode
-
-Additionally, controller supports synchronization mode, where it tries to register all clients in hydra.
-Synchronization is an optional mode, enabled via config, which is meant for use cases where hydra is deployed with in memory storage.
-If hydra pod is restarted for some reason then it does not have client in its storage. With synchronization mode the controller makes sure that hydra has up to date clients.
-Synchronization is done by making POST request to hydra with payload describing all client information including clientID,clientSecret and Identifier of last applied client.
-If client exists in hydra storage 409 is returned which is considered as ok and synchronization continues with other clients.
\ No newline at end of file
+Take a look at [Design Readme](./docs/README.md)
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..b60ef48
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,24 @@
+# Design
+
+
+## Controller design
+
+The controller listens for Custom Resource which defines client registration request. Once Custom resource is created, the controller register oauth2 client in hydra using hydra's REST API.
+Client Id, Client Secret and Identifier of the client in hydra are be stored in the kubernetes as a secret and referenced in the applied CR.
+Reference is used to identify in which kubernetes secret are stored mentioned properties. Secret iscreated in the same namespace of applied CR.
+By default controller should be deployed in the same pod as hydra. Service discovery will come in place in the future.
+
+
+It is represented in the diagram
+
+
+
+## Synchronization mode
+
+Additionally, controller supports synchronization mode, where it tries to register all clients in hydra.
+Synchronization is an optional mode, enabled via config, which is meant for use cases where hydra is deployed with in memory storage.
+If hydra pod is restarted for some reason then it does not have client in its storage. With synchronization mode the controller makes sure that hydra has up to date clients.
+Synchronization is done by making POST request to hydra with payload describing all client information including clientID,clientSecret and Identifier of last applied client.
+If client exists in hydra storage 409 is returned which is considered as ok and synchronization continues with other clients.
+
+
\ No newline at end of file
diff --git a/docs/assets/synchronization-mode.svg b/docs/assets/synchronization-mode.svg
new file mode 100644
index 0000000..0e5ca58
--- /dev/null
+++ b/docs/assets/synchronization-mode.svg
@@ -0,0 +1,2 @@
+
+
\ No newline at end of file
diff --git a/docs/assets/workflow.svg b/docs/assets/workflow.svg
new file mode 100644
index 0000000..c0c5fc3
--- /dev/null
+++ b/docs/assets/workflow.svg
@@ -0,0 +1,2 @@
+
+
\ No newline at end of file