What Makes a Great User Experience in WordPress Hosting?  🔗 **Source:** [What Makes a Great User Experience in WordPress Hosting?](https://www.youtube.com/watch?v=jlPAdN3AU2c&feature=youtu.be) > [!note]+ Document Notes > tags: [product-design, design-systems, wordpress-hosting, ui-conventions, wp-cloud, ai-prototyping, coordination-cost] > author: Sanja Grbic (Automattic) with host Jesse Friedman - Impressive Hosting podcast > source: https://www.youtube.com/watch?v=jlPAdN3AU2c > reference: "What Makes a Great User Experience in WordPress Hosting? (with Sanja Grbic)" - Impressive Hosting > date created: 2026-08-26 15:20 > > > [!info] Generated analysis - not the speakers' words. Sections below are machine-written > > from the captured transcript. Only text inside `> [!quote]` blocks is verbatim. > > Do not quote or attribute any other line to the named speakers. > > # Title: What Makes a Great User Experience in WordPress Hosting? (with Sanja Grbic) > > **Attribution.** Reader's `author` field reads `YouTube`. This is an episode of **Impressive Hosting**, hosted by **Jesse Friedman**, with guest **Sanja Grbic**, senior product designer at **Automattic**. > > **CAPTION WARNING - flagged up front because it affects every quotation.** The auto-transcript mangles essentially every proper noun in the episode: **Sanja Grbic** renders as *"Sonia Gri"* and then *"Sonia"* throughout - **Automattic** as *"Automatic"* - **Jetpack** as *"Jetack"* and *"Jetback"* - **Jesse Friedman** as *"Jesse Freriedman"* - **Filipe** as *"Phipe"* - **Blacklane** as *"Black Lane"* - **Issuu** as *"issue"* - **Plesk** as *"plesque"*. **Correct spellings here come from the episode title and from context, not from the captions.** Anything quoted verbatim below preserves the caption's text; anything naming a person uses the corrected form. > > **Register.** An industry podcast conversation - friendly, two colleagues (they state they work together at Automattic), promotional at the edges. **Not adversarial, and that matters**: the host and guest are colleagues and the episode is partly about products they both work on. > > **Why it matters here.** Two things. It's the clearest available articulation of **why hosting panels should look alike** - a genuinely counterintuitive design argument with a portability payoff. And it puts a **live case study in direct tension with three other sources in this batch**: Sanja describes AI removing coordination friction as pure empowerment, while Cunningham and the LeadDev manager argue that removing exactly that friction is what stops judgment forming. **That tension resolves, and the resolution is the most interesting thing in this analysis.** > <!-- deep-read:sections start --> ## Table of Contents 1. Summary 2. Main Content and Notes 3. References 4. Paraphrase 5. Newsletter 6. Action Items 7. Hypotheses 8. Methodology 9. Questions 10. Future Research 11. Implications 12. Learning Styles Assessment 13. Accessibility Assessment 14. DEIB Assessment 15. Logical Validity 16. DARVO Analysis 17. Conclusion 18. Refactor Appendix 19. Template Library ## References (in-page) - **The WordPress open-source design system** - the component library she contributes to. - **The Design System Tracker** - her RSM project, stated to be **publicly available**. - **Jetpack** - 80+ features for self-hosted sites, and the underlying technology for the same features on WordPress.com. - **WP Cloud** - described as **100% API-based**. - **Panel Alpha** and **RT Camp** - named as white-label panel providers. - **cPanel** and **Plesk** - the historical convention-setters for hosting panels. - **Radical Speed Month (RSM)** - an Automattic-wide initiative she credits to Matt Mullenweg. - **impressive.host** - the show's site, which also hosts a list of open-source projects seeking support. - Her prior employers: **Blacklane** (since acquired by Uber) and **Issuu**. ## Summary **Who she is.** Ten-plus years designing, background in **architecture and graphic design**, agency work, freelance, and her own design studio in **Belgrade, Serbia**. Then product design at **Blacklane** and **Issuu**, and **five years at Automattic on the Jetpack design team**. Also worked on **WP Cloud** and WooCommerce products. Friedman's characterisation, which she accepts: she never approaches work *"from a perspective of scale"* - *"it doesn't matter so much if it's used by millions or if it's used by 10 people."* **Radical Speed Month.** An Automattic initiative - participants paired up, chose their own project, and shipped fast. She did two. Her account of why it worked is the most transferable thing she says about process: > *"having the opportunity to choose what you want to work on to to channel that energy um that you have when you're passionate about an idea without having to lose it on on persuasion on on ne negotiation on gathering a team and then just going for it."* **Project one - the Design System Tracker**, built with Andrew and Melody in about two and a half weeks. Its users are designers: one place to determine *"which component to use or whether a new component needs to be created or who to contact or where to find more information."* **Now publicly available**, and she directs hosting companies to it. **Project two** - with Filipe, her design lead and a five-year collaborator. **Six days** from idea to research to a working **chat app connecting merchants with customers on a site** - an iOS app paired with a plugin. She attributes the speed to how well they already knew each other's processes. **On the WordPress design system**, and note what she names first: *"it is very important to make sure that the accessibility is in place, that it's compatible for all the versions, and that in terms of UX it can serve many use cases and that it can be flexible enough for everyone to use it."* **Her advice to hosting companies:** check the open-source system first - audit what you already have - **use the simple components** (buttons, typography) - consider the complex ones carefully - and if something doesn't fit, *"share that in the repository, share thoughts, open issues, contribute to it so that we can all have those conversations together."* **The panel-versus-WP-admin oscillation**, from Friedman: hosts pull everything into their panel, get told users want it in WP admin, then build a must-use plugin and push it all back. His conclusion - *"you're never going to make every customer happy with one single solution"* - and Jetpack's answer: **be where the user is** rather than funnelling them somewhere. Panel, WP admin, app, and increasingly **email**, where 2FA and confirmation actions now live. **The central design argument, and the best part of the episode.** Asked whether hosts should differentiate on interface innovation, Sanja goes conservative: > *"a a toggle a a toggle switch is a toggle switch and it should work the same everywhere... usually when someone tries to innovate there. Sometimes it does not serve its purpose in terms of like I'm not sure if the sggle is on or off."* And: *"the essence of that component is to have you switch something on or off and you should be aware of what what your action you know just provoked... it needs to be obvious you shouldn't have to think about it."* **Friedman's light-switch story** carries the point further. His grandmother's dining-room switch was installed upside down - but you always knew what happened, because the light responded. Then the deeper observation: **the convention is learned, not innate.** The original switch was a turn dial; *"there was no inherent brain pattern to say that up means on and down means off. That wasn't something that existed. So it was something that had to be ingrained."* **Where innovation belongs**, per Sanja: *"the innovation should happen in terms of new features, allowing people to use new technologies, solving problems for them that they express that they have"* - not invented. Her example: Jetpack's early AI features went **into Gutenberg using existing patterns** - *"we didn't have to come up with new ways of designing interfaces in order to be innovative."* **The cost test**, which is the line worth keeping: > *"things can be improved, but uh but what is the price of that improvement? Is it really um changing things for the better or is it just there to to do something new that that that might be ultimately confusing"* **Friedman's differentiation thesis**, and it has a portability edge: differentiate on *"the partnerships that you create, the technology that you add on, the things that you bolt on"* - because diverging far from convention *"create[s] an uncomfortable feeling when someone either arrives **or leaves** your hosting company. I think that would be to the detriment of the whole system."* **The white-label defence.** The objection he hears is *"it's going to look the same for everybody and it's not going to differentiate us."* His answers: your brand sits at the top; **Samsung, Motorola, and Google all ship Android and you can move between them easily**; and **cPanel and Plesk** established that a hosting panel is a recognisable thing - *"cPanel was cPanel and you would know if you were in cPanel or if you weren't."* The conclusion: > *"it's more around the user experience is more about the emotion that the customer is going to feel. Do they feel empowered? Do they feel like they're getting the things done and it's less about like the little intricacies of of a design?"* Sanja's version is tighter: *"The system is the base that you can rely on at all times and then... you have the time to innovate where actually where it'll make the biggest impact."* **A concrete AI-in-production data point.** WP Cloud is 100% API-based, so partners either integrate it into an existing panel or build one. Friedman reports **a partner going live within weeks who rebuilt their entire panel from scratch** using *"AI and a couple developers and designers... in just a matter of days."* **On code as a tool** - her closing theme, and the batch's live case study: > *"I think code is a tool just as much as Figma is a tool or AI is a tool to visual visualize something."* She never intended to be an engineer; she took HTML and CSS courses long ago and can *"figure out the basics."* What changed: *"in the past I wouldn't mind to have code in my toolbox, right? But but it's just too much work to do everything. Uh but now with AI, I have this incredibly powerful tool in my toolbox and I can choose depending on the situation."* **Her scoping is honest**: *"engineers have knowledge that I don't have and some complex features are still not something that AI can entirely do well."* And the anchor: *"my biggest contribution is is in the thinking."* **The recurring phrase.** Friedman suggests she no longer has to wait for someone to build what's in her head. Her answer echoes her RSM framing exactly: *"less friction, less negotiation, less, you know, trying to to convince."* She flags a next episode on *"how organizations might adapt... we will all have to work together a little differently from now on."* ## Main Content ### Notes **The show.** *Impressive Hosting*, hosted by Jesse Friedman - *"a podcast about the role hosting plays in shaping the open web... we go deeper than uptime and dashboards. We talk about hosting as infrastructure, about ownership, independence, and what it takes to build ethical high-end WordPress hosting."* Site: **impressive.host**, which also carries *"a list of open source projects that need support... whether it's code, community, or cash."* **Sanja Grbic's background** (her own account). - Designer for **over 10 years**; background in **architecture and graphic design**. - Agencies, freelance, and **her own design studio in Belgrade, Serbia**, working with startups worldwide. - Product design at **Blacklane** (since acquired by Uber) and **Issuu** (*"the number one global PDF to magazine platform"*). - **Five years at Automattic**, on the **Jetpack design team**. - Jetpack: serves self-hosted customers across security, growth, and analytics - *"more than 80 features"* - **and is the underlying technology for the same features on WordPress.com**. - Also worked on **WP Cloud** and WooCommerce products. *"always serving millions of customers."* - Friedman's read, which she accepts: *"you never seem to approach it from a perspective of scale. It's always about the user first... it doesn't matter so much if it's used by millions or if it's used by 10 people."* - Calling in from **Automattic's San Francisco office in the Mission**. **Radical Speed Month (RSM).** - Attributed to Matt Mullenweg. Participants **paired up**, chose their own work, and built something fast. Roughly six weeks before recording. - On AI's role: *"I think we're all using AI now a lot in our daily process also thanks to how automattic is actually enabling us to do that and encouraging us."* - **The key mechanism**, in her words: *"having the opportunity to choose what you want to work on to channel that energy that you have when you're passionate about an idea without having to lose it on persuasion, on negotiation, on gathering a team and then just going for it."* - She did **two** projects *"because it was so much fun and the time allowed for it."* **Project 1 - the Design System Tracker.** - Team of three: herself, **Andrew**, and **Melody**. Finished in *"3 weeks, like two and a half weeks."* - **Intended users were internal designers.** *"working with design systems is always complicated everywhere. It's an evolving thing that connects and lives inside many different products if the company is big enough."* - Purpose: one place to find *"all of the information that they need... so that they can make a decision whether which component to use or whether a new component needs to be created or who to contact or where to find more information."* - **Now publicly available**, and she points hosting companies to it. **Project 2 - the merchant/customer chat app.** - Paired with **Filipe**, her **design lead**, after five years on the same team. *"we know each other very well and we know each other's processes very well. So we were able to align super quickly."* - **Six days** from idea through research to a built **iOS app paired with a plugin** connecting merchants with customers on the site. - A proof of concept they intend to develop further for customers. **On the WordPress design system.** - *"the open-source design system that we're contributing to actively... the nature of it is that it serves complicated workflows."* - **What she names as the hard requirements, in her order:** *"it is very important to make sure that the accessibility is in place, that it's compatible for all the versions, and that in terms of UX it can serve many use cases and that it can be flexible enough for everyone to use it."* **Her advice to hosting companies.** 1. *"if you're building an interface and you are able to use the open source system, definitely check it out first. See what's available."* 2. The **Design System Tracker** is publicly available - look there. 3. *"audit what they already have if they're redesigning"* or plan what they need to build. 4. **Start simple:** *"use as much of the simpler components as they can, like buttons and typography styles and things like that, just smaller items."* 5. *"then carefully consider also the more complex components that might fit their use case."* 6. **Contribute back:** if it doesn't fit, or you have an idea *"that could work not just for them but for other people,"* then *"share that in the repository, share thoughts, open issues, contribute to it so that we can all have those conversations together and make the design system better for everyone."* **The panel-versus-WP-admin problem** (Friedman). - The oscillation: hosts *"suck everything into our panel"* - hosting configuration, SFTP, email, marketplace add-ons - then hear *"I like to do everything inside the WP admin,"* and respond by building **a must-use plugin** that moves it all back. - *"you're never going to make every customer happy with one single solution."* - **Jetpack's approach:** *"being where the user is instead of worrying about trying to funnel them into a specific place. We kind of just make sure that they have a great experience wherever that is."* Panel, WP admin, app. - **And email:** *"there's more and more functionality being brought into email as well... everything from two-factor login to updating settings or configurations or confirming something."* - His hypothesis: a shared design system would make it *"feel the same"* across all those surfaces, so users *"aren't getting confused about how to set something up."* **Sanja on whether a design system saves time.** - **For users: unambiguous.** *"in more cases than not users know what to expect. If the patterns are familiar, they can get used to that and they're becoming kind of a universal experience."* - **For designers: qualified.** *"design systems evolve continuously, so you can never say that it's ready and it never really fits entirely the use case that you're working on."* There is always work to use what's available *"but also keep the experience at a high standard."* - *"systems thinking is always helpful, especially within the WordPress ecosystem that can be very very complex and it's serving very complex workflows quite often."* **Hosting companies watching each other** (Friedman). - Competition is good and *"the diversity in hosting is something that's valuable."* - **But:** *"they often feel like every other hosting company has it figured out and that they feel a little bit like they're kind of wading through tough waters and trying to sort things out themselves and so they're always looking at what someone else is doing."* - **The experiment problem:** Automattic runs many experiments; an observer *"might stumble upon an experiment and think to themselves, 'Oh, they're making a big paradigm shift... We need to get on board and do that kind of thing too.' And then all of a sudden, our experiment is gone because it didn't work... it leaves people guessing."* **The toggle argument.** - Her instinct: *"I would go the conservative route here and I would make sure that some basic patterns are in there and always the same."* - *"a toggle switch is a toggle switch and it should work the same everywhere and there are some variations and you can try a few different ones, and usually when someone tries to innovate there, sometimes it does not serve its purpose in terms of like I'm not sure if the toggle is on or off. Have you ever had that experience?"* - *"the essence of that component is to have you switch something on or off and you should be aware of what your action just provoked, right? And it needs to be obvious. You shouldn't have to think about it."* **The light-switch analogy** (Friedman). - His grandmother's dining-room switch was **installed upside down** - *"every time you'd flip the switch, it would be the exact opposite of your expectation."* - But: *"the thing about the light is that you would know exactly what happened in that exact moment"* - the feedback was immediate. (Sanja: *"unless the power is out."*) - **The deeper point:** the original light switch *"was like a turn dial... It wasn't an up and down."* And *"there was no inherent brain pattern to say that up means on and down means off. That didn't- that wasn't something that existed. So it was something that had to be ingrained."* - The **hamburger menu** is offered as the modern parallel - *"everyone felt like those three lines don't mean anything to people"* - and it became convention anyway. **Where innovation belongs.** - Sanja: *"the innovation should happen in terms of new features, allowing people to use new technologies, solving problems for them that they express that they have, that are not necessarily just anticipated or made up completely."* - **The Jetpack AI example:** *"we experimented with integrating AI features when it was just the beginning... we incorporated it into the WP admin, into the editor, into Gutenberg in a way by using patterns that already exist and people know how to use, but the tools were still there. We didn't have to come up with new ways of designing interfaces in order to be innovative."* - **The cost test:** *"things can be improved, but what is the price of that improvement? Is it really changing things for the better or is it just there to do something new that might be ultimately confusing for people who switch on their light every day - and if the light switch is different every time they walk into a room, that's not going to be a great experience."* **Friedman's differentiation thesis.** - Differentiate on *"the partnerships that you create, the technology that you add on, the things that you bolt on."* - **Not on interface divergence:** *"I don't think that it makes any sense to diverge from the pattern so much that you create an uncomfortable feeling when someone either arrives or leaves your hosting company. I think that would be to the detriment of the whole system."* **WP Cloud and the white-label question.** - *"with WP Cloud we're 100% API based."* Partners either integrate into an existing panel or build a new one. - **The AI data point:** *"with the use of AI we've seen a couple hosting companies develop panels."* One partner going live within weeks *"had an existing panel and then they were like, you know what, we're shifting everything to WP Cloud, this probably feels like the right time to recreate our entire panel from the ground up"* - and did it *"using AI and a couple developers and designers... in just a matter of days. Which was remarkable."* - **Panel Alpha** and **RT Camp** offer white-label panels. - **The objection:** *"why would we want to use a white labelled panel? It's going to look the same for everybody and it's not going to differentiate us."* - **His answers:** *"you have your brand at the top. Your brand will always be first."* - white-labelled software gives a familiar feel - **the Android argument** - *"Samsung and Motorola and Google are not differentiating themselves on... they take Android and the user interface is still very similar... you still can bounce around between an Android phone pretty easily."* - **the cPanel argument** - *"cPanel and Plesk have been around long enough... for the most part, cPanel was cPanel and you would know if you were in cPanel or if you weren't."* - **The conclusion:** *"you're not going to be differentiating yourself on a few pixels around an icon... it's more about the emotion that the customer is going to feel. Do they feel empowered? Do they feel like they're getting the things done? And it's less about the little intricacies of a design."* - **Sanja:** *"The system is the base that you can rely on at all times and then on top of that you have the time to innovate where actually where it'll make the biggest impact."* **Code as a tool.** - Friedman notes she hasn't been a developer, and now with AI is reaching into implementation. Asked how it feels: *"It feels cool and empowering."* - *"for my entire career I work in technology so I always had to understand and learn - like a hundred years ago I took courses in HTML and CSS, and afterwards when I build my site I can figure out the basics, but my idea was never to be an engineer."* - **The framing:** *"I think code is a tool just as much as Figma is a tool or AI is a tool to visualize something, to represent whatever - my job is to take something and to make it better and I have exact goals and how it needs to be improved and all of that is in my head, and now I'm using a tool to visualize that and communicate that and show how that's going to work."* - The options range from sketching on paper and handing off, to going through the entire process herself. - **The anchor:** *"my biggest contribution is in the thinking and the part of changing something to a better state to better serve the customer, to better serve the business."* - **What changed:** *"in the past I wouldn't mind to have code in my toolbox, right? But it's just too much work to do everything. But now with AI, I have this incredibly powerful tool in my toolbox and I can choose depending on the situation and the project which tool I want to use. I might still just write a blog post and describe how something can be better, or I can go through the entire process and even deliver that."* - **Her limits, stated unprompted:** *"engineers have knowledge that I don't have and some complex features are still not something that AI can entirely do well."* - Friedman: she was *"probably feeling a little limited by who you could pair up with or who you could hand it to... But now you actually maybe don't have to wait anymore."* - **Her echo of the RSM framing:** *"less friction, less negotiation, less trying to convince... sometimes it's super easy, sometimes it's just not working, and it's good to know that I can push it a little further."* Even a prototype lets you *"show people how it actually really works in the real world."* - **Teased for the next episode:** *"my insights around how organizations might adapt with these new- because we will all have to work together a little differently from now on."* ## References - **The Design System Tracker** - stated to be publicly available. **The most directly actionable item here** for anyone building WordPress-adjacent interfaces, and unverified in this analysis. - **The WordPress open-source design system / `@wordpress/components`** - the underlying library, and the thing she asks hosts to check before building. - **WP Cloud's API documentation** - the 100% API-based claim is the technical premise for the whole panel discussion. - **Panel Alpha, RT Camp** - named white-label options; useful for anyone weighing the build-versus-adopt question. - **cPanel, Plesk** - the historical convention-setters, and the evidence base for the familiarity argument. - **Cross-batch pairings, and this is where the value is:** - **The LeadDev "junior engineers" piece** - Sanja is a textbook example of its **accelerator** phase, which resolves the apparent contradiction between them. - **Cunningham's talk** - argues that removing exactly the friction Sanja celebrates is what breaks knowledge transmission. - **The Tech Times/Automattic registries piece** - Friedman's *"when someone either arrives or leaves"* is the same portability argument in interface terms. - **The GitHub alt-text post** - the toggle-state discussion is an accessibility argument neither speaker names as one. - **What's missing:** any user research, any usability data, any host that diverged from convention and succeeded, and any non-Automattic voice. ## Paraphrase **On the tension with the rest of this batch, which is the most interesting thing here.** Sanja describes AI removing coordination overhead as straightforwardly good: *"less friction, less negotiation, less trying to convince."* Cunningham, in this same batch, argues that squeezing out exactly that kind of time and interaction is how cultural knowledge stops transmitting. The LeadDev manager argues that delegating the hands-on work is how judgment fails to form. **On the surface these are in direct conflict.** **They resolve, and the LeadDev framework does the resolving.** Sanja is not a novice using a model to skip learning. She has **ten-plus years of design experience, five of them on this specific product surface**, deep domain knowledge, and - the decisive detail - **she volunteers her own limits without being asked**: *"engineers have knowledge that I don't have and some complex features are still not something that AI can entirely do well."* That is precisely the LeadDev **accelerator** profile: bringing clear requirements, questioning the output, catching what the tool can't. **The LeadDev model predicts Sanja's experience exactly.** It predicts something different for someone without her decade. **Neither source knows about the other, and together they're more useful than either.** **But the tension doesn't fully dissolve, and the residue is worth naming.** *"Less negotiation, less trying to convince"* is stated twice - once about RSM, once about AI - as pure gain. **Persuasion and negotiation are also how bad ideas get filtered and how other people's context enters a design.** The coordination cost being removed is real overhead *and* real review. For a senior designer with strong judgment that trade is probably worth it. **As an organisational default it is the enforcement-boundaries problem again**: the friction was doing work nobody had named, and removing it removes the work too. Neither speaker raises this, and the next episode - *"how organizations might adapt"* - is where it would belong. **On the toggle argument, which is better than it first sounds.** *"A toggle switch is a toggle switch and it should work the same everywhere."* This reads as conservatism and is actually a claim about **where the cost of novelty lands**: on the user, every time, forever, while the benefit accrues once to the designer. Her test - *"what is the price of that improvement?"* - is the right one, and *"I'm not sure if the toggle is on or off"* names a failure everyone has experienced and few designers price correctly. **On the light switch, which is the sharpest idea in the episode and it's Friedman's.** *"there was no inherent brain pattern to say that up means on and down means off... it was something that had to be ingrained."* **The convention isn't natural - it's amortised.** Decades of universal exposure paid off a learning cost once, and every subsequent user inherits the benefit for free. **That's what makes divergence expensive:** you're not competing against an obviously-correct design, you're competing against a cost that has already been paid across an entire population. The hamburger menu proves the point in the other direction - it was widely derided, became universal, and now costs nothing. **On "arrives or leaves," which sneaks a portability argument into a design conversation.** Friedman argues against divergence because it creates discomfort *"when someone either arrives or leaves your hosting company."* **A host optimising for its own users would only care about arrival.** Caring about departure is arguing that switching cost is bad even when it benefits you - the same position the Tech Times piece in this batch takes about domain portability, expressed in interface terms. **Convention is a portability guarantee that nobody has to enforce.** **On the white-label defence, which is stronger than the objection it answers.** *"cPanel was cPanel and you would know if you were in cPanel or if you weren't."* The Android comparison does the work: Samsung, Motorola, and Google compete hard and ship recognisably similar interfaces, and **nobody experiences that as a failure of differentiation.** Where they compete - hardware, cameras, price, ecosystem - is where competition is legible to buyers. Panel pixels are not. **On what the design system conversation gets right that most do not.** Asked what makes a component hard, Sanja's first answer is **accessibility**, before compatibility and before flexibility. That ordering is not the default in design-system discourse, and it's worth noticing given the episode's audience. It also makes the unnamed accessibility argument in the toggle discussion less accidental than it looks - *"you should be aware of what your action just provoked"* is a plain-language statement of a state-communication requirement. **On what to discount.** This is two colleagues at the same company discussing that company's products, on a podcast the host runs. **Every example of good practice is an Automattic example**; every product recommended is one of theirs or an open-source project they contribute to. Nothing is falsified by that, and the selection is not neutral. The **"panel rebuilt in days with AI"** anecdote is the clearest case: unnamed partner, unverified, unspecified scope, and it's evidence for a product the host works on. ## Newsletter **Why your hosting panel should look like everyone else's.** Sanja Grbic, senior product designer at Automattic, on Jesse Friedman's *Impressive Hosting*, asked whether hosts should differentiate on interface design. Her answer: > *"a toggle switch is a toggle switch and it should work the same everywhere... usually when someone tries to innovate there, sometimes it does not serve its purpose in terms of like I'm not sure if the toggle is on or off."* That sounds like conservatism. It's actually a claim about **where the cost of novelty lands** - on the user, every time, forever, while the benefit accrues once, to the designer. Her test is the one to keep: > *"things can be improved, but what is the price of that improvement? Is it really changing things for the better or is it just there to do something new that might be ultimately confusing?"* Friedman's light-switch story is the best thing in the episode. His grandmother's dining-room switch was installed upside down - annoying, but you always knew what happened, because the light answered immediately. Then the real point: **the convention isn't natural.** The original switch was a turn dial. *"There was no inherent brain pattern to say that up means on and down means off. That wasn't something that existed. So it was something that had to be ingrained."* **Conventions are amortised.** Decades of exposure paid a learning cost once, and everyone since inherits the benefit free. That's why divergence is expensive - you're not beating an obviously-correct design, you're competing with a cost already paid across an entire population. The hamburger menu proves it going the other way: universally mocked, now invisible. So where do you differentiate? *"The partnerships that you create, the technology that you add on, the things that you bolt on."* Not pixels. And the reason is quietly generous: > *"I don't think that it makes any sense to diverge from the pattern so much that you create an uncomfortable feeling when someone either arrives **or leaves** your hosting company."* **A host optimising purely for itself would only care about arrival.** Caring about departure means arguing switching cost is bad even when it works in your favour - which is the portability argument, in interface clothes. Convention is a portability guarantee nobody has to enforce. The white-label objection - *"it's going to look the same for everybody"* - gets answered with Android: Samsung, Motorola, and Google compete hard and ship near-identical interfaces, and nobody calls that a differentiation failure. And with history: *"cPanel was cPanel and you would know if you were in cPanel or if you weren't."* Sanja's summary: *"The system is the base that you can rely on at all times and then on top of that you have the time to innovate where it'll make the biggest impact."* **Two more things worth flagging.** First, an accessibility note neither of them makes: *"you should be aware of what your action just provoked... it needs to be obvious, you shouldn't have to think about it"* is a plain-language statement of a state-communication requirement. And when asked what makes a shared component hard to build, **accessibility is the first thing she names** - before version compatibility, before flexibility. That ordering isn't the default in design-system talk. Second, and this is the part that connects to everything else this week. Sanja is a designer who now ships working code through AI, and describes it as *"less friction, less negotiation, less trying to convince."* Elsewhere this week, Zoe Cunningham argued that squeezing out exactly that time is how knowledge stops being transmitted, and a LeadDev engineering manager argued that delegating hands-on work is how judgment fails to form. **Those look contradictory. They aren't.** Sanja has ten-plus years of design experience and five on this product surface, and she volunteers her own limits unprompted: *"engineers have knowledge that I don't have and some complex features are still not something that AI can entirely do well."* That's the LeadDev model's **accelerator** profile, exactly. The model predicts her experience *and* predicts a different one for someone without the decade. The residue, though, is real and nobody raises it: **persuasion and negotiation are also how bad ideas get filtered and how other people's context gets in.** For a senior designer with strong judgment, removing that friction is probably a win. As an organisational default, it removes review along with overhead. She's promised a next episode on *"how organizations might adapt."* That's exactly where this belongs. ## Action Items **DevRel** - `#action/h1` **The light-switch/amortised-convention argument is a talk.** It explains why familiar-is-better without appealing to conservatism, and the hamburger-menu counterexample makes it honest. - `#action/h1` *"What is the price of that improvement?"* is a one-line design review question that travels to any interface work. - `#action/h2` The **"arrives or leaves"** framing is a genuinely unusual thing for a vendor to say, and worth citing as an ecosystem-health argument. **OSPO** - `#action/h1` **Shared design systems as ecosystem infrastructure.** Her contribute-back advice - *"open issues, contribute to it so that we can all have those conversations together"* - is the standard open-source ask, applied to design rather than code. - `#action/h2` **The experiments-look-like-strategy problem** is real for any large open-source contributor: observers can't distinguish an experiment from a direction, and act on the wrong one. **Community** - `#action/h2` **The Design System Tracker being public** is a concrete, low-friction on-ramp for agencies and hosts who currently rebuild components from scratch. **WordPress subteams** - **Design** - `#action/h1` **The most relevant subteam.** Two items: the Design System Tracker is a model for making component decisions legible, and **accessibility is named first** among what makes a shared component hard - worth reinforcing. - **Accessibility** - `#action/h1` The toggle discussion is a **state-communication argument made without accessibility vocabulary**. *"You should be aware of what your action just provoked"* is exactly the case for accessible name/role/state, and it landed with a hosting audience precisely because it wasn't framed as compliance. **A model for how to make a11y arguments that stick.** - **Hosting** - `#action/h1` The whole episode is addressed to this audience: use the open-source system, differentiate on partnerships and technology, don't diverge on toggles. - **Core** - `#action/h2` *"Being where the user is instead of funnelling them"* is a live design question for core as functionality spreads across WP admin, panels, apps, and email. - **Meta** - `#action/h2` The Tracker's approach - one place to answer *which component, or does a new one need to exist, and who do I ask* - is applicable to the component library's own documentation. - **Themes, Plugins** - `#action/h2` "Use the simple components first, consider complex ones carefully, contribute back what doesn't fit" is directly transferable guidance. - **Core AI** - `#action/h2` The Jetpack precedent - **ship AI features inside existing patterns rather than inventing new interfaces** - is the right default for core AI work. - **Training, Documentation** - `#action/h3` The light-switch analogy is a good teaching device for convention versus innovation. - **Support, CLI, Playground, Polyglots, Openverse, Photos, TV, Mobile, Marketing, Core Performance, Core Program Team, Tide** - **Not applicable to this source.** **The WPOCC** - `#action/h2` The design-system-first advice is practical for freelancers and small agencies who currently rebuild UI per client. Low-cost, immediately usable. **FAIR** - `#action/h2` **Convention as an unenforced portability guarantee.** Friedman's *"arrives or leaves"* is the same structural argument as domain portability in the Tech Times piece: what protects users is a shared standard nobody can unilaterally change, not any vendor's goodwill. **Personal / vault** - `#action/h1` **This resolves the apparent contradiction in this batch.** Sanja is the LeadDev model's **accelerator** case - deep domain expertise, clear requirements, and unprompted acknowledgment of her own limits. **The frameworks agree; they're describing different people.** Worth recording explicitly, because the surface contradiction would otherwise weaken the delegation-atrophy note. - `#action/h1` **The unexamined residue is the finding neither source has:** *"less negotiation, less trying to convince"* removes review along with overhead. **Persuasion is also a filter.** That belongs in the enforcement-boundaries note as its sixth instance. - `#action/h2` **The a11y-argument-without-a11y-vocabulary technique** is directly usable in her accessibility work. The toggle case landed with a hosting audience because it was framed as user experience, not compliance. - `#action/h2` **Check the Design System Tracker.** Relevant to her own plugin UI work (Post Kinds, Outpost, Social Webmention Importer), all of which currently roll their own admin interfaces. - `#action/h3` **The "experiments look like strategy" problem** applies to her own public work - a staging experiment read as a direction. ## Hypotheses 1. **The amortised-convention hypothesis.** Interface conventions are learned, not innate, and their value comes from a learning cost already paid across a population - so divergence charges users again for something already bought. **The strongest idea in the episode**, and it's the host's. *Well-reasoned, evidenced only by the light switch and the hamburger menu.* 2. **The novelty-cost-asymmetry hypothesis.** The cost of interface novelty lands on users repeatedly; the benefit accrues once to the designer. *Implicit in "what is the price of that improvement?"; never stated this directly.* 3. **The differentiation-elsewhere hypothesis.** Hosts should compete on partnerships, technology, and add-ons rather than interface patterns. *Argued by analogy (Android, cPanel); no market data.* 4. **The portability hypothesis.** Convention reduces switching cost in both directions, which is good for the ecosystem even when it's bad for the incumbent. **A vendor arguing against its own switching-cost advantage.** *Asserted, not evidenced.* 5. **The be-where-the-user-is hypothesis.** No single surface satisfies everyone, so meet users on all of them and make the experience consistent. *Reported as Jetpack's approach; no supporting data.* 6. **The accelerator hypothesis (cross-source).** A practitioner with deep domain expertise gains capability from AI without the judgment cost, because the judgment already exists. **Sanja is a live instance of the LeadDev model's third phase**, including its defining behaviour of questioning the tool's limits. *Strong as an illustration, single case.* 7. **The coordination-cost hypothesis.** The binding constraint on a senior practitioner was never the idea, it was persuading, negotiating, and assembling a team. *She says this twice, in two different contexts.* 8. **The removed-friction-was-also-review counter-hypothesis (reviewer).** Persuasion and negotiation filter bad ideas and admit others' context; removing them removes that function too. **Unaddressed by either speaker**, and the obvious objection. ## Methodology **Design: an industry podcast conversation between colleagues.** No study, no user research, no data, no dissenting voice. Two Automattic employees discussing Automattic products and an open-source project Automattic contributes heavily to, on a podcast the host produces. | Claim | Basis | Strength | |---|---|---| | Conventions are learned, not innate | **Reasoned, with the turn-dial example** | **Strong as an argument.** Doesn't need data - it's a claim about history. | | Interface divergence harms users | Reasoning plus the toggle-state example | **Moderate.** Recognisable and unmeasured. | | Familiar patterns reduce switching cost | The Android and cPanel analogies | **Moderate.** Analogies, not evidence. No host that diverged and succeeded is considered. | | Design systems save designers time | **She qualifies this herself** - systems evolve, never fully fit | **Honest and appropriately hedged.** She declines the easy claim. | | Accessibility is a hard requirement for shared components | Her direct professional experience | **Credible**, unelaborated. | | A partner rebuilt a panel in days with AI | **Second-hand, unnamed partner, unverified** | **Weakest claim in the episode**, and it's evidence for a product the host works on. No scope, no team size, no definition of "panel." | | RSM produced two shipped projects | **First-hand account** | **Strong for what it is** - her own work, with named collaborators and stated durations. | | AI lets a designer implement | **First-hand, with stated limits** | **Credible and well-scoped.** The unprompted limits are what make it so. | **Methodological strengths.** - **She declines the easy claim about design systems saving time**, volunteering that they evolve continuously and never quite fit. That's a real concession in a conversation that would have rewarded enthusiasm. - **She scopes her own capability unprompted** - *"engineers have knowledge that I don't have"* - which is the single most credibility-earning line in the episode. - **Concrete, checkable specifics** on her own work: named collaborators, stated durations (2.5 weeks, 6 days), stated artifacts. - **The experiment-observation problem is a genuine self-criticism** from the host: Automattic's experiments mislead the ecosystem. **What is not established.** - **No user research anywhere.** An episode about user experience contains no user data, no usability testing, no support-ticket evidence. - **No counter-case.** Not one host that diverged from convention and benefited. Since the thesis is that divergence is costly, its absence is the whole test. - **The AI panel-rebuild anecdote is unverifiable** and structurally promotional. - **Every good example is an Automattic example.** Jetpack, WP Cloud, the design system, RSM. - **No non-Automattic voice**, on a question where competing hosts have an obvious interest. - **"Innovation should solve problems people express"** - no method offered for how those expressions are gathered. **Bias checks.** *Vendor interest* - **high and structural.** Host and guest are colleagues at the company whose products are recommended. Nothing appears false; the selection is not neutral. *Survivorship* - only successful projects are described; RSM's failures, if any, don't appear. *Self-reported* - everything, though her own-work claims are specific enough to be checked. *False precision* - mostly absent; the durations are real and modest. **The exception is "a matter of days"** for a whole panel, which is doing promotional work without a definition. *Anecdote generalised* - the light switch and the Android comparison carry conclusions about an industry. *Newer-is-better* - **actively inverted**, which is the episode's most distinctive stance: the designers are arguing *for* convention. ## Questions 1. **Has any host differentiated successfully by diverging from convention?** The thesis predicts no. Nobody checks, and one counterexample would be more informative than every analogy offered. 2. **What did the AI-built panel actually involve?** Unnamed partner, undefined scope, no team size. **The one claim that would matter most to the audience and the least supported.** 3. **How are the "problems people express" actually collected?** Innovation is supposed to answer expressed problems rather than anticipated ones, and no mechanism is described. 4. **Does the Design System Tracker cover the open-source system or Automattic's internal one?** Her advice conflates them somewhat, and the distinction determines who it's useful to. 5. **What did RSM cost?** Two projects shipped; nothing about what didn't get done, or what happened to the merchant-chat proof of concept after. 6. **Where is the line between "using existing patterns" and stagnation?** The hamburger menu was novel once and she'd have opposed it on this reasoning. **The episode has no test for when divergence is warranted.** 7. **Who filters the ideas now?** If persuasion and negotiation are gone, what replaces their filtering function? The next episode is teased on organisational adaptation and this is the question for it. 8. **Does "be where the user is" scale?** Panel, WP admin, app, and email is four surfaces to keep consistent, and the maintenance cost is never priced. ## Future Research - **Look at the Design System Tracker directly.** Stated to be public, and the most actionable artifact mentioned. - **Find a divergence counterexample.** A host that broke convention and won would test the central thesis better than any of the analogies offered. - **Verify the AI panel-rebuild claim** - scope, team, timeline. It's the most quotable and least supported statement in the episode. - **Listen to the follow-up episode** on how organisations adapt. **That's where the removed-friction question belongs**, and it's the one this episode leaves open. - **Read the WordPress design system's accessibility requirements** against her claim that accessibility is the hardest part of shipping a shared component. - **Test the amortised-convention claim** against interface history more broadly - the hamburger menu's rehabilitation suggests the picture is more complicated than the light switch implies. ## Implications **Practice.** Two portable items. **"What is the price of that improvement?"** is a one-line design review question that surfaces the cost asymmetry immediately. And **start with the simple components, consider the complex ones carefully, contribute back what doesn't fit** is a workable adoption sequence for any shared design system. **Policy.** **Convention functions as an unenforced portability guarantee.** Friedman's *"arrives or leaves"* is the same structural argument the Tech Times piece makes about domain portability: what protects users is a shared standard no single party can change unilaterally. **A vendor arguing against its own switching-cost advantage is worth noting**, and it's the ecosystem-health case for shared design systems. **Security.** Only tangential, but the state-communication point has a security edge: **a user who can't tell whether a toggle is on has no reliable way to confirm a security setting took effect.** Two-factor toggles, permission switches, and public/private controls all depend on the state being unambiguous, and the episode's example is exactly the failure mode. **Education.** The light switch is a genuinely good teaching device precisely because it's mundane: it demonstrates that a convention everyone treats as natural was learned, universally, at cost, and is now free. That's a better foundation for teaching interface design than any appeal to intuitiveness. **For Courtney's practice.** Three things. **This resolves the batch's apparent contradiction** - Sanja is the LeadDev accelerator case, so the frameworks agree and are describing different people. **The unexamined residue is the new finding**: removing persuasion and negotiation removes review as well as overhead, which is enforcement boundaries again from a fresh angle. And **the a11y-argument-without-a11y-vocabulary technique** is directly usable: the toggle case landed with a hosting audience because it was framed as user experience rather than compliance. ## Learning Styles Assessment - **Visual** - **Absent, and unusually costly here.** An hour about interface design with no visual reference. The toggle-state problem, the Tracker, and the panel-versus-WP-admin split all want screenshots. The medium fights the subject. - **Aural** - **Native and strong.** Warm, conversational, two people who clearly enjoy talking to each other. - **Verbal** - **Mixed.** Ideas are good; delivery is loose. Heavy hedging and restarts, and the host's questions are frequently longer than the answers. - **Kinesthetic** - Moderate. A publicly available tool, a named component library, and a concrete adoption sequence. - **Logical** - **Good in patches.** The convention argument builds properly: instinct -> toggle example -> light switch -> learned-not-innate -> therefore divergence is costly. Other sections wander. - **Social** - **Strong**, and the format's real advantage: two practitioners building on each other's points, with the light-switch analogy emerging from the exchange rather than from either alone. - **Solitary** - Weak. Loose structure and no summary make solo extraction laborious. - **Naturalistic** - Not applicable to this source. **Reading level estimate.** Roughly grade 11-12 spoken. Vocabulary is accessible; **the assumed context is not** - WP admin, must-use plugins, SFTP, Gutenberg, white-label panels, and design systems all arrive undefined. Written for the industry it names as its audience. ## Accessibility Assessment Assessed as a **podcast episode with an auto-generated transcript**. 1. **Perceivable - captions (1.2.2).** **The clearest failure in this batch.** The captions mangle essentially every proper noun: **the guest's own name** becomes *"Sonia Gri"* and then *"Sonia"* throughout; **Automattic** -> *"Automatic"*; **Jetpack** -> *"Jetack"* and *"Jetback"*; **Filipe** -> *"Phipe"*; **Blacklane** -> *"Black Lane"*; **Issuu** -> *"issue"*; **Plesk** -> *"plesque"*; the host's own name -> *"Jesse Freriedman"*. **A transcript that renames the guest is not an equivalent alternative** - it fails anyone relying on text, and it makes the episode unsearchable by the names it's about. 2. **Perceivable - audio-only alternative (1.2.1).** A transcript exists, which is the right instinct; its quality undercuts it. 3. **Perceivable - visual content.** No visual references made verbally, which is appropriate for audio-first. **Pass by design.** 4. **Operable - timing (2.2).** Recorded, pausable. **Pass.** 5. **Understandable - language (3.1).** **Mixed.** Plain vocabulary, heavy undefined jargon. A newcomer to WordPress hosting will follow the sentences and miss the substance. 6. **Understandable - predictable (3.2).** Weak. No chapter markers or section signposting in the captured text; the conversation wanders and there's no summary. 7. **Robust (4.1).** Transcript extracted cleanly with timing spans intact. **The content-level accessibility point, which is the notable one.** *"You should be aware of what your action just provoked... it needs to be obvious, you shouldn't have to think about it"* is **a state-communication requirement stated in plain language.** A toggle whose state is ambiguous fails users generally and assistive-technology users specifically - and **neither speaker frames it as accessibility.** Separately, when asked what makes a shared component hard, **Sanja names accessibility first**, ahead of version compatibility and flexibility. **The episode is more accessibility-literate than its vocabulary suggests, and less accessible than it should be in delivery.** **Highest-value remediation:** a corrected transcript, starting with the guest's name. Then chapter markers. **A podcast that misnames its own guest throughout is a fixable problem with a one-hour cost.** ## DEIB Assessment - **Representation is genuinely strong here, and largely unremarked by the participants.** A **woman senior product designer** with a non-traditional route in - **architecture and graphic design**, agency work, freelancing, **her own studio in Belgrade, Serbia** - now at a major platform company in San Francisco. **That is a career path the industry claims to value and rarely showcases**, and she describes it matter-of-factly without it being made into a story about overcoming anything. - **The accessibility ordering is the substantive DEIB content.** Asked what makes a shared component hard, her first answer is *"it is very important to make sure that the accessibility is in place"* - before compatibility, before flexibility. **In design-system discourse accessibility is routinely third or absent.** Naming it first, unprompted, to a hosting audience, is a small structural act. - **The convention argument is an equity argument nobody labels.** Users who benefit most from familiar patterns are those with the least capacity to absorb re-learning costs: people with cognitive disabilities, people using assistive technology built around expected patterns, older users, people operating in a second language, and anyone under time pressure. **Novelty taxes the least-resourced user hardest.** The episode makes the argument entirely in terms of comfort and expectation, and the distributional point is available and untaken. - **"Be where the user is"** is inclusion reasoning in product form - meeting people on the surface they already use rather than requiring them to come to yours. - **Inclusive language.** Neutral throughout. No gendered defaults. - **Neurodiversity support.** **Mixed, and the content contradicts the delivery.** The argument - predictable patterns, obvious state, *"you shouldn't have to think about it"* - is directly supportive. The delivery is a loose, unstructured, hour-long conversation with no signposting or summary, which is the opposite. - **A gap worth naming.** The whole conversation is between two employees of one company about that company's products, and *"we can all have those conversations together"* is said about a design system one company dominates contribution to. **The invitation to contribute is genuine; the power asymmetry around whose patterns become everyone's defaults is not discussed.** - **Global framing.** Belgrade and San Francisco both appear. The hosting-industry framing is otherwise Western and English-language throughout, and internationalisation never comes up despite being a real design-system constraint. ## Logical Validity **Strong reasoning.** 1. **The learned-convention argument is well-built and genuinely non-obvious.** Turn dial -> up/down was arbitrary -> the pattern was *ingrained* -> therefore conventions carry a paid-once cost that divergence charges again. **Historical rather than aesthetic, which is what makes it hold.** 2. **The hamburger menu is a self-supplied counterexample.** Introducing an initially-derided pattern that became universal complicates their own thesis, and they include it anyway. 3. **The toggle example is well-chosen.** It's the simplest possible component, so *"I'm not sure if the toggle is on or off"* can't be blamed on complexity. 4. **She qualifies the design-system time-saving claim herself.** *"design systems evolve continuously... it never really fits entirely the use case"* - declining an easy win. 5. **She scopes her own capability unprompted.** *"engineers have knowledge that I don't have and some complex features are still not something that AI can entirely do well."* **The most credibility-earning line in the episode**, and nobody asked. 6. **The self-criticism about experiments is real.** Automattic's experiments mislead observers who read them as strategy - a cost to their own ecosystem, volunteered. 7. **"Arrives or leaves" argues against their own interest.** Reducing switching cost in both directions is not what a host optimising for retention would advocate. **Fallacies and weaknesses.** 1. **No counter-case considered** - `#fallacy/suppressed-evidence`. The thesis is that divergence is costly; **not one host that diverged and succeeded is examined.** The single biggest gap. 2. **Argument by analogy throughout** - `#fallacy/false-analogy`, mild. Light switches, Android phones, and cPanel carry conclusions about WordPress hosting. The analogies are apt; they aren't evidence. 3. **Structural vendor interest** - `#fallacy/conflict-of-interest`. Colleagues discussing their employer's products on the host's own show. Every positive example is internal. 4. **The AI panel-rebuild anecdote is unverifiable and promotional** - `#fallacy/appeal-to-anecdote`. Unnamed partner, undefined scope, *"a matter of days,"* and it's evidence for the host's product. 5. **No test for when divergence is warranted.** By this reasoning the hamburger menu should have been rejected. **They raise the counterexample and don't resolve it.** 6. **"Solve problems people express"** - no mechanism for how expressions are gathered, and no acknowledgment that users often can't articulate the problem. 7. **The removed-friction claim is one-sided** - `#fallacy/suppressed-evidence`. *"Less negotiation, less trying to convince"* is stated twice as pure gain; **persuasion is also a filter**, and neither speaker notices. **Tone of voice.** Warm, collegial, and unhurried - two people who have worked together and enjoy it. The register is **industry-insider without being gatekeeping**: jargon goes undefined, but nothing is condescending. Sanja is the more careful speaker, hedging genuinely and qualifying her own claims; Friedman is the more expansive, and several of his questions are longer than the answers they get. **The most interesting tonal feature is that two designers spend an hour arguing for restraint** - against innovation on the interface, in favour of looking like everyone else. That is not the default posture of the profession, and they hold it without defensiveness. ## DARVO Analysis **Not applicable to this source.** DARVO describes a pattern in accounts of wrongdoing - denial, attacking the accuser, reversing victim and offender. This is a friendly industry podcast about design systems and hosting interfaces. **No accusation, no accused party, no contested harm.** **Two adjacent observations.** **First, and creditably: the one moment that could have been defensive isn't.** Friedman raises that hosting companies watch Automattic and misread its experiments as strategic direction - *"then all of a sudden, our experiment is gone because it didn't work... it leaves people guessing."* **He frames this as a cost Automattic imposes on the ecosystem**, not as other companies being foolish. Given that he could easily have told it as a story about competitors copying badly, the framing is a choice. **Second, and this is the structural note.** The episode's persuasive work is done almost entirely by **selection rather than argument**: every positive example is an Automattic product, every recommendation points at something the participants build or contribute to, and no competing voice appears. **That isn't DARVO and it isn't dishonest** - it's two colleagues talking about the work they know. It does mean the episode's implicit claim that these are the industry's best patterns rests on the absence of anyone positioned to disagree. **Recorded as: no DARVO, one creditable refusal of a defensive framing, and persuasion by selection.** ## Conclusion **Bottom line.** The clearest available case for why hosting panels should look alike, plus a live example of an experienced designer shipping code through AI that resolves an apparent contradiction elsewhere in this batch. **The argument worth keeping**, and it's the host's: *"there was no inherent brain pattern to say that up means on and down means off... it was something that had to be ingrained."* **Conventions are amortised.** A learning cost was paid once across an entire population, and everyone since inherits the benefit free. That is why divergence is expensive - you're not competing against an obviously-correct design, you're competing against a cost already paid. And it's why Sanja's test is the right one: *"what is the price of that improvement?"* **The cost of novelty lands on users repeatedly; the benefit accrues once, to the designer.** **The unexpectedly generous move:** don't diverge, because it creates discomfort *"when someone either arrives **or leaves** your hosting company."* **A host optimising purely for itself would care only about arrival.** Caring about departure means arguing that switching cost is bad even when it works in your favour - **convention as a portability guarantee nobody has to enforce**, which is the same structure as the domain-portability argument elsewhere in this batch. **Two things the episode does better than it realises.** The toggle discussion - *"you should be aware of what your action just provoked... it needs to be obvious"* - is **a state-communication requirement stated without accessibility vocabulary**, delivered to a hosting audience, and it lands precisely because it isn't framed as compliance. And when asked what makes a shared component hard, **Sanja names accessibility first**, ahead of compatibility and flexibility, which is not where design-system discourse usually puts it. **The cross-batch resolution, which is the most useful output of this analysis.** Sanja describes AI removing coordination overhead as pure gain - *"less friction, less negotiation, less trying to convince."* Cunningham and the LeadDev manager, in this same batch, argue that removing that friction is how knowledge stops transmitting and judgment stops forming. **These are not in conflict.** Sanja has ten-plus years of design experience, five on this product surface, and volunteers her own limits without being asked: *"engineers have knowledge that I don't have and some complex features are still not something that AI can entirely do well."* **That is the LeadDev model's accelerator phase, exactly** - bringing clear requirements, questioning the output, catching what the tool can't. **The model predicts her experience and predicts a different one for someone without the decade.** **But the residue is real and nobody in the batch has it.** *"Less negotiation, less trying to convince"* is stated twice as unambiguous benefit. **Persuasion and negotiation are also how bad ideas get filtered and how other people's context enters a design.** For a senior designer with strong judgment, that trade is probably worth making. **As an organisational default, it removes review along with overhead** - enforcement boundaries again, from a new direction. She teases a follow-up episode on how organisations adapt, which is exactly where the question belongs. **What to discount.** Two colleagues at one company discussing that company's products on the host's own show. Every positive example is internal, no competing voice appears, and **no host that diverged from convention and succeeded is ever considered** - which is the only real test of the central thesis. The **"partner rebuilt an entire panel in a matter of days with AI"** claim is the weakest thing here: unnamed, unscoped, unverified, and evidence for a product the host works on. **And a fixable failure worth naming:** the auto-transcript **misnames the guest throughout** - Sanja Grbic becomes "Sonia Gri" - along with Automattic, Jetpack, Filipe, Blacklane, Issuu, Plesk, and the host himself. A transcript that renames its subject is not an equivalent alternative, and it makes the episode unsearchable by the names it's about. **Next steps.** 1. **Record the accelerator resolution** in the delegation-atrophy note - the frameworks agree, they describe different people. 2. **Add the persuasion-is-also-a-filter point** to enforcement boundaries as its sixth instance. 3. **Look at the Design System Tracker**, and check it against her own plugins' admin UI. ## Refactor Appendix ### Literature Split Pad (H3) > [!quote] `#atom/literature/h1` > "there was no inherent brain pattern to say that up means on and down means off. Like that didn't that wasn't something that existed. So it was something that had to be ingrained." **The best idea in the episode**, and it's the host's. Conventions are amortised: a learning cost paid once across a population, inherited free by everyone since. That's what makes divergence expensive. > [!quote] `#atom/literature/h1` > "things can be improved, but uh but what is the price of that improvement? Is it really um changing things for the better or is it just there to to do something new that that that might be ultimately confusing" The design-review question in one line. **The cost of novelty lands on users repeatedly; the benefit accrues once, to the designer.** > [!quote] `#atom/literature/h1` > "a a toggle a a toggle switch is a toggle switch and it should work the same everywhere... usually when someone tries to innovate there. Sometimes it does not serve its purpose in terms of like I'm not sure if the sggle is on or off." Well-chosen example: the simplest possible component, so the failure can't be blamed on complexity. **Also an accessibility argument neither speaker names as one.** > [!quote] `#atom/literature/h1` > "I don't think that it makes any sense to like diverge from the pattern so much that um you create an uncomfortable feeling when someone either arrives or leaves your hosting company. I think that would be to the detriment of the whole system." **A vendor arguing against its own switching-cost advantage.** Convention as an unenforced portability guarantee - the same structure as domain portability, in interface terms. > [!quote] `#atom/literature/h2` > "having the opportunity to choose what you want to work on to to channel that energy um that you have when you're passionate about an idea without having to lose it on on persuasion on on ne negotiation on gathering a team and then just going for it." The RSM mechanism. **Note the same framing recurs about AI later - for her the constraint removed is organisational, not technical.** And note what neither speaker raises: persuasion is also a filter. > [!quote] `#atom/literature/h2` > "I think code is a tool just as much as Figma is a tool or AI is a tool to visual visualize something... my biggest contribution is is in the thinking" The accelerator posture. The tool changes; the contribution doesn't. > [!quote] `#atom/literature/h2` > "engineers um have knowledge that that I don't have and some you know of course complex features um are still not something that that AI can entirely do well." **The most credibility-earning line in the episode**, and unprompted. Scoping your own capability is the accelerator's defining behaviour in the LeadDev model. > [!quote] `#atom/literature/h2` > "we incorporated it into the WP admin into the editor uh into Gutenberg in a way by using patterns that already exist um and people know how to use but um but the tools were still there. We we we didn't have to you know come up with new ways of of designing interfaces in order to be innovative." **The right default for shipping AI features:** new capability inside existing patterns. > [!quote] `#atom/literature/h2` > "it is very important to make sure that the accessibility is in place that that um it's uh compatible for all the versions" **Accessibility named first** among what makes a shared component hard - ahead of compatibility and flexibility. Not where design-system discourse usually puts it. > [!quote] `#atom/literature/h3` > "The system is the base that you can rely on at all times and then you have on top of that you have the time to innovate where act actually where um it'll make the biggest impact." The whole design-system argument in one sentence. Convention buys you the budget to innovate where it counts. > [!quote] `#atom/literature/h3` > "they often feel like every other hosting company has it figured out and that they feel a little bit like they're kind of um you know waiting through tough waters" Plus the experiment problem: observers read Automattic's experiments as strategy, then the experiment disappears. **Volunteered as a cost they impose, not a competitor failing.** > [!quote] `#atom/literature/h3` > "being where the user is instead of worrying about you know trying to funnel them into a specific place." Jetpack's answer to the panel-versus-WP-admin oscillation. Inclusion reasoning in product form, and the maintenance cost is never priced. ### Atomic Split Pad (H4) - `#atom/zettel/z1` **Conventions are amortised, not natural** - An interface pattern's value comes from a learning cost already paid across a population. Divergence charges users again for something already bought, which is why familiarity beats improvement more often than designers expect. - `#atom/zettel/z1` **Novelty's cost is asymmetric** - The designer pays once; users pay every time, forever. Any proposed interface change should be priced against that asymmetry before its merits are considered. - `#atom/zettel/z1` **Convention is a portability guarantee nobody enforces** - Shared patterns reduce switching cost in both directions. A vendor advocating them is arguing against its own lock-in, which is why it's a credible signal about ecosystem health. - `#atom/zettel/z1` **A control whose state is ambiguous has failed at its only job** - If you can't tell whether the toggle is on, nothing else about the design matters. This is an accessibility requirement that persuades better when framed as user experience. - `#atom/zettel/z1` **Ship new capability inside existing patterns** - Innovation belongs in what the tool can do, not in how it's operated. Novel capability plus novel interface charges the user twice for one benefit. - `#atom/zettel/z1` **Removing coordination cost removes review with it** - Persuasion, negotiation, and assembling a team are overhead *and* a filter: they kill bad ideas and admit other people's context. Removing the friction removes both functions, and only one of them gets missed immediately. - `#atom/zettel/z1` **Expertise is what makes delegation safe** - A practitioner with deep domain judgment gains reach from a capable tool without the judgment cost, because the judgment already exists. The same tool given to someone without it produces a different outcome, and the tool cannot tell the difference. - `#atom/zettel/z1` **Scoping your own limits unprompted is the strongest credibility signal** - Volunteering what you don't know, before anyone asks, distinguishes calibrated confidence from fluency. It applies identically to people and to model output. - `#atom/zettel/z1` **Experiments look like strategy from outside** - An observer cannot distinguish a test from a direction. Organisations large enough to be watched impose a cost on their ecosystem every time they experiment in public. ### Fleeting Queue - `#atom/fleeting/f1` **THE ACCELERATOR RESOLUTION.** Sanja is the LeadDev model's third phase - deep expertise, clear requirements, unprompted limits. **The frameworks in this batch agree; they describe different people.** Record this in the delegation-atrophy note before the surface contradiction weakens it. - `#atom/fleeting/f1` **"Persuasion is also a filter"** - the residue neither speaker sees. **Sixth enforcement-boundaries instance**, from a new direction. - `#atom/fleeting/f1` **Check the Design System Tracker** against her own plugin admin UI (Post Kinds, Outpost, Social Webmention Importer) - all currently roll their own. - `#atom/fleeting/f1` **The a11y-argument-without-a11y-vocabulary technique.** The toggle case landed with a hosting audience because it was framed as UX, not compliance. **Directly usable in her accessibility work.** - `#atom/fleeting/f1` **Accessibility named first** among what makes a shared component hard. Worth citing to the WP Design team. - `#atom/fleeting/f1` **Verify the "panel rebuilt in days with AI" claim** before repeating it anywhere. Unnamed, unscoped, and promotional. - `#atom/fleeting/f1` **Caption failure is the worst in this batch** - the guest's own name is wrong throughout. Good teaching example for why auto-captions aren't captions. - `#atom/fleeting/f1` **"Arrives or leaves"** pairs with the Tech Times domain-portability piece. Same structure, different layer of the stack. - `#atom/fleeting/f1` **Listen for the follow-up episode** on how organisations adapt - that's where the removed-friction question belongs. - `#atom/fleeting/f1` **No counter-case anywhere** - no host that diverged and won. The central thesis is untested by its own episode. ## Template Library ### -> Fleeting refactor Two-line capture: *Sanja Grbic (Automattic) + Jesse Friedman on hosting UX. "A toggle switch is a toggle switch." Best idea: conventions are LEARNED - the light switch used to be a turn dial, "there was no inherent brain pattern," so familiarity is a cost already paid. Differentiate on partnerships and technology, not pixels. Also: she's the LeadDev "accelerator" case in the flesh.* File under design systems and WordPress hosting. ### -> Literature refactor Three destinations. **"Interface Convention and Portability"** - new note: amortised conventions, the cost asymmetry, "arrives or leaves," and the white-label/Android/cPanel arguments. **Cross-link to the Tech Times domain-portability piece**; they're the same argument at different layers. **"Skill Formation Under Delegation"** - add Sanja as the accelerator case study that resolves the apparent contradiction, and note that the resolution is only visible across sources. **"Enforcement Boundaries"** - sixth instance, via persuasion-as-filter. ### -> Atomic refactor Strongest Permanent Note candidates: 1. **"Conventions Are Amortised, Not Natural"** - the best idea from this source, non-obvious, and it generalises past interfaces to any shared standard. **Include the hamburger menu as the honest complication.** 2. **"Removing Coordination Cost Removes Review"** - the finding neither speaker has, and the one this analysis contributes. Pairs with enforcement boundaries. 3. **"Expertise Is What Makes Delegation Safe"** - the accelerator resolution, and it's the note that keeps the delegation-atrophy argument from over-claiming. **Without it, that note reads as "delegation is bad," which none of the sources actually says.** 4. **"A Control Whose State Is Ambiguous Has Failed"** - short, usable, and a model for making accessibility arguments that persuade non-specialists. ### -> Things 3 - Record the accelerator resolution in the delegation-atrophy note (**high priority** - it prevents that note from over-claiming, and it's only visible across sources). - Add persuasion-as-filter to the enforcement-boundaries note (high priority - sixth instance this week). - Look at the public Design System Tracker; compare against own plugin admin UI (medium priority). - Listen for the follow-up episode on organisational adaptation (low priority - but it's where the open question lands). <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/What Makes a Great User Experience in WordPress Hosting.md|What Makes a Great User Experience in WordPress Hosting? by Sanja Grbic (Automattic) with Jesse Friedman - Impressive Hosting]] ## Highlights - >> Yeah. Yeah. Yeah. Yeah. Yeah. >> Right. So many everyone felt like those three lines don't mean anything to people. And but the reality of the situation is is that like, you know, like like the light switch, we >> we didn't have, >> you know, the original light switch was like a turn dial, right? It was like a on and off. It wasn't an up and down. >> And so there's no >> to >> Yeah. But there's really no like >> there was no inherent brain pattern to say that up means on and down means off. ([View Highlight](https://read.readwise.io/read/01m0z44phaw24xvy9efk7e9ra7)) - Note: THE BEST IDEA IN THE EPISODE, and it's the host's. CONVENTIONS ARE AMORTISED, NOT NATURAL — the light switch used to be a turn dial, so up-means-on was arbitrary and had to be ingrained across an entire population. That's why divergence is expensive: you're not competing against an obviously-correct design, you're competing against a learning cost already paid. The hamburger menu is the honest complication they supply themselves — universally derided, now invisible. #atom/zettel/z1 - WordPress interfaces or or hosting interfaces in a way that it is familiar for everyone no matter what hosting company they're with. But the the the way in which you differentiate yourself is in the partnerships that you create, the technology that you add on, the things that you bolt on. But I don't think that it makes any sense to like diverge from the pattern so much that um you create an uncomfortable feeling when someone either arrives or leaves your hosting company. I think that would be to the detriment of the whole system. ([View Highlight](https://read.readwise.io/read/01m0z454myxs30mzvx9d7gxcv2)) - Note: "ARRIVES OR LEAVES" — a vendor arguing against its own switching-cost advantage. A host optimising purely for itself would care only about arrival; caring about departure means arguing switching cost is bad even when it works in your favour. CONVENTION IS A PORTABILITY GUARANTEE NOBODY HAS TO ENFORCE — the same structure as the domain-portability argument in the Tech Times/Automattic piece this week, one layer up the stack. #atom/zettel/z1 - when I can like I don't know whatever you know but um >> uh things can be improved, but uh but what is the price of that improvement? Is it really um changing things for the better or is it just there to to do something new that that that might be ultimately confusing uh for people who switch on their light every day and if the light ([View Highlight](https://read.readwise.io/read/01m0z45h8d9g96rmm6kzb35j23)) - Note: The design-review question in one line. NOVELTY'S COST IS ASYMMETRIC: the designer pays once, users pay every time, forever. Equity note the episode doesn't make — the users who benefit most from familiar patterns are those least able to absorb re-learning costs (cognitive disabilities, assistive tech built around expected patterns, older users, second-language users, anyone under time pressure). Novelty taxes the least-resourced user hardest. #atom/zettel/z1 - my um idea was never to be an engineer. I think code is a tool just as much as Figma is a tool or AI is a tool to visual visualize something um to represent whatever my job is to take something and to make it better and I have exact goals and you know how it needs to be improved and all of that is in my head and now I'm using a tool ([View Highlight](https://read.readwise.io/read/01m0z45yknmzwj3qc7z4m1yqc7)) - Note: THE ACCELERATOR CASE IN THE FLESH — and this RESOLVES the apparent contradiction in this week's batch. Cunningham and the LeadDev EM argue that removing friction stops judgment forming; Sanja describes it as pure gain. Both are right: she has 10+ years of design experience, five on this surface, and volunteers her own limits unprompted ("engineers have knowledge that I don't have"). That's the LeadDev model's third phase exactly. THE FRAMEWORKS AGREE — they describe different people. Record this before the surface contradiction weakens the delegation-atrophy note. #atom/zettel/z1