diff --git a/content/posts/what-about-design.md b/content/posts/what-about-design.md
index 0b1f1f2..b975285 100644
--- a/content/posts/what-about-design.md
+++ b/content/posts/what-about-design.md
@@ -102,11 +102,11 @@ is, and how the experience for it should be, i.e., design. This process should
 be applied across a set of implementations, using the same design guidelines and
 ensuring interoperability.
 
-In practice it is not enough if somebody using [Conversations] on mobile talks
-to somebody else using [Dino] on desktop, even if they both follow the
-Compliance Suites of year X and can then interop on a “basic” level (still
-pretty advanced to be honest), they have different design guidelines and there
-will inevitably be areas where they differ and some features won't behave as
+It is not enough if somebody using [Conversations] on mobile talks to somebody
+else using [Dino] on desktop, even if they both follow the Compliance Suites
+of year X and can then interop on a “basic” level, which to be honest, is
+still pretty advanced, they have different design guidelines and there will
+inevitably be areas where they differ and some features won't behave as
 expected on the other side. The issue is not that there is no design
 guidelines, it's that they're not the same.
 
@@ -115,7 +115,7 @@ guidelines, it's that they're not the same.
 [CS-2020]: https://xmpp.org/extensions/xep-0423.html
 
 
-# What now?
+# And in practice?
 
 Multiple solutions following this design process already exist, such as
 [Xabber] and [Tigase]. [Snikket] is a new addition in this domain. You can
@@ -128,12 +128,11 @@ its goal: to provide a server and a (set of) client(s) that interoperate
 properly and have common design guidelines that match the expected userbase.
 
 Maybe you're not part of Snikket's target, in which case there might someday
-be a similar solution that's more adapted to your use-case.
-
-For the more technical of us who understand the protocol and/or can deal with
-less unified designs, it may be ok to continue using our current applications
-and work around these issues ourselves. For the mass audiences I believe this
-is not an option.
+be a similar solution that's more adapted to your use-case. For the more
+technical of us who understand the protocol and/or can deal with less unified
+designs, it may be ok to continue using our current applications and work
+around these issues ourselves. For the mass audiences I believe this is not an
+option.
 
 [Conversations]: https://conversations.im
 [Dino]: https://dino.im
@@ -150,9 +149,10 @@ To the question I set to answer at the beginning I say this: Why does it
 matter? For whom? My goal is to bring standardization, decentralization, and
 extensibility to mass audiences. Not to bring XMPP to them. As explained above
 I believe we need product suites with common design guidelines, and they
-should include these properties. The protocol by itself is not enough.
+should include these properties. XMPP has good building blocks but lacks
+consorted design.
 
 I want decentralization and standardization to prevent users from being locked
 in closed -- often also proprietary -- silos such as WhatsApp, Hangouts,
-Slack, MS Teams, or even Signal.  And I want extensibility to prevent being
-stuck in the past and adapt to the people's needs.
+Slack, MS Teams, Tik-Tok, or even Signal. And I want extensibility to prevent being
+stuck in the past and to adapt to the people's needs.