Building Training Systems, Not Sessions | Andrew Adam  🔗 **Source:** [Building Training Systems, Not Sessions | Andrew Adam](https://www.youtube.com/watch?v=FKfdL7sK6Og) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Building Training Systems, Not Sessions | Andrew Adam > ## 🧭 Table of Contents > - [References](#-references) > - [Summary](#-summary) > - [Main Content](#-main-content) > - [References (Primary Sources)](#-references-1) > - [Paraphrase](#-paraphrase) > - [Newsletter](#-newsletter) > - [Action Items](#-action-items) > - [Hypotheses](#-hypotheses) > - [Methodology](#-methodology) > - [Questions](#-questions) > - [Future Research](#-future-research) > - [Implications](#-implications) > - [Learning Styles Assessment](#-learning-styles-assessment) > - [Accessibility Assessment (WCAG 2.2 AA)](#-accessibility-assessment-wcag-22-aa) > - [DEIB Assessment](#-deib-assessment) > - [Logical Validity](#-logical-validity) > - [DARVO Analysis](#️-darvo-analysis) > - [Conclusion](#-conclusion) > - [Refactor Appendix](#-refactor-appendix--building-training-systems-not-sessions--andrew-adam) > ### 🔗 References > - Andrew Adam — QA engineer, Modern Tribe by Nexus (speaker) > - Modern Tribe / Nexus — the agency behind the "Modern Press" internal WordPress framework > - Modern Press — Modern Tribe's internal WordPress framework (custom themes, plugins, blocks layered on core) > - Learn Modern Press (learn.tri.be) — the shared training resource showcased in the talk > - WordPress.org documentation — named as a trusted, allowed source for the AI assistant > - Learn WordPress — named as an existing general WordPress learning resource the talk positions against > - ChatGPT (custom GPT) — early tool used to build the documentation assistant > - Claude (Claude Project) — the tool the team migrated to for the documentation assistant > - Yoast, RankMath, Redirection — named plugins flagged as future documentation targets > - WooCommerce — named as a future documentation target (e-commerce coverage) > ## 📝 Summary > - **What happened**: Andrew Adam (QA engineer, Modern Tribe by Nexus) gave a WordCamp talk on why one-time client training sessions fail to produce lasting competence, and how his team built "Learn Modern Press," a shared, AI-assisted documentation system covering ~100 guides for their internal WordPress framework (Modern Press). > - **Why it matters**: The talk reframes training as infrastructure rather than an event — a durable, maintainable knowledge system that scales across client projects instead of being re-created (and re-forgotten) per engagement. It's a concrete, reproducible case study of AI-assisted technical documentation with strong guardrail design. > - **Stakeholders**: Agency training/support/QA teams, client-facing editorial teams, WordPress agencies running multi-client custom frameworks, clients/end-users learning WordPress, WordPress Training and Community teams interested in scalable education models. > - **Risks**: Over-reliance on AI-authored documentation without adequate human review; risk of "confirmed sources only" guardrails being loosened over time; maintenance debt if the two-person team scales client load faster than upkeep capacity; documentation drift if the underlying Modern Press framework changes faster than the review cycle. > - **Bottom line**: A shared, foundational documentation system — authored by humans, drafted and scaled with a carefully guardrailed AI assistant — reduces repeated, inconsistent one-off training while freeing human experts to focus on project-specific and custom-feature support. > ## 📖 Main Content > ### 🗒️ Notes > *(No timestamps are present in the captured transcript — video is not chaptered/timestamped in the source. Structure below follows the talk's own segment order.)* > **1. The problem with one-time training** > Adam opens by noting that training success at launch is deceptive — clients "don't know what they don't know" until they're actually working in the site. Questions surface days, weeks, or months later. He identifies the core issue as fragility: any single-format training (docs, live sessions, recordings) has limited depth, absorption is capped, and guidance goes stale the moment WordPress, the built site, or client workflows change. Client team turnover compounds this — new hires inherit the site but not the training context, forcing re-training. Consequences: underused features and content/accessibility drift from the design system. > **2. From sessions to systems** > Adam's proposed reframe: document the *foundational* guidance that repeats across every client project once, and do it deeply — freeing the team to focus human time on custom, project-specific work. He argues the timing is right because (a) WordPress's block/site editor has matured and is unlikely to require constant doc rewrites, and (b) AI is now capable enough to make building such a system practical even for a small team. He explicitly distinguishes this from existing general resources (WordPress.org docs, Learn WordPress) — those teach WordPress in general, not a specific agency's *implementation* of it, which is what clients actually need. > **3. Showcase: Learn Modern Press** > The team's public resource (learn.tri.be) covers ~100 guides spanning both core WordPress and their custom "Modern Press" framework, deliberately blurring the core/custom distinction so clients experience "one system." Content spans: WordPress basics and publishing foundations (navigation, editor workflows, post types vs. custom post types, taxonomies, user roles/administration); deep overviews of major systems (block editor, site editor, navigation, templates, patterns — with safety warnings on higher-risk areas); and deep block-level documentation (settings plus *when* to use a block and content rules, e.g., capping columns at four). Shared cross-block topics (dimensions, animations, borders/shadows) are documented once and cross-referenced to avoid duplication. Walkthrough videos accompany most guides, chosen because documentation serves deep lookup while video serves initial learning. > **4. Accessibility as a first-class thread** > Two-pronged approach: (a) accessibility guidance embedded contextually throughout normal docs (heading hierarchy inside the heading-block doc, alt text inside the image-block doc) so users discover it at the point of relevance; (b) a dedicated "accessible content" section going deeper, including a publishing checklist and guidance on screen readers and keyboard navigation. > **5. Extending into project delivery** > The resource also absorbed the team's User Acceptance Testing (UAT) process and worksheets — previously built per-project — so ~80% of UAT guidance can now simply be referenced rather than recreated, saving time and familiarizing clients with a tool they'll use long-term. > **6. The three-layer model** > Layer 1: shared foundation (Learn Modern Press itself). Layer 2: project-specific guidance/training sessions (still necessary, but now a smaller share of total effort). Layer 3 (exploratory/in development): in-context support — surfacing shared docs directly inside the WordPress editor sidebar (non-AI, just contextual linking/video snippets), an AI chat assistant grounded in the trusted resource, and a longer-term AI-assisted page/section builder. > **7. How it was built — planning** > Two people, roughly a month, part-time. They mapped 100+ topics, built categories, deliberately split out shared/duplicated topics early, grouped rarely-used one-off blocks (terms, author, post-date) into the workflows where they naturally appear (e.g., post templates) rather than giving them standalone pages, and prioritized starting with *easier* topics to learn the documentation structure before tackling harder ones. > **8. AI assistant configuration** > Core configuration elements: an established assistant role, context about how WordPress works with the Modern Press framework, voice/tone/formatting rules (reused from an existing assistant), governance/decision rules (when to ask for more info, what never to assume), multiple "response modes" for different audiences, and attached reference files — baseline templates per doc type, "gold standard" Hope everyone have is having a great day here at Word Camp so far. I'm excited to be here and thank you all for coming to this session. I'm excited that you're all here in this room together because we're going to talk about some topics that don't always get enough attention. We're going to talk about training documentation and how we can better support the people that we make these websites and tools for. WordPress is more capable and flexible than it's ever been. But with that comes a steeper learning curve, especially for someone who is new. It's not exactly intuitive to use WordPress extremely well. My name is Andrew Adam. I'm the QA engineer with Modern Tribe by Nexus, and I've worked with WordPress for over 15 years. I've trained, supported, and onboarded more clients than I can even remember. And I've had a lot of success with this. I think I run some really great training sessions. But even still, the results can be inconsistent. Not everyone gets it, and not everyone gets it as well as I would love them to do. This talk is called building training systems, not sessions. And we're going to explore a case study of a recent project that I was involved with where we built a large client-f facing knowledge resource that was designed to help our clients work with confidence in WordPress and also to integrate into our project processes. So here's what we're going to cover. First, just to understand the problem a little bit more, we're going to talk about why one-time training sometimes falls short. Then, we're going to talk about why a shared training system makes sense and can be practical to build today. Then, we'll do some showcase and we'll have a look at the system that we built. This is our resource just for inspiration. And then finally, we'll talk about how AI helped build, scale, and maintain the resource. So, the problem typically begins at a moment that looks like success. A website launches, training seems to go very well, everyone's excited, they're confident, they're ready to go get to work. But our clients are really only just getting started. They don't know what they don't know. Once they're in there working in WordPress, that's when the questions really start to come in. Sometimes days later, weeks later, months later, and sometimes just for the life of the project, and they never really stop. We're all helpful. We love answering questions, but the questions are not really the problem. The problem is bigger than that. The problem is that one-time training is just fragile. Regardless of the format, whether it's some documentation, live training sessions, or recorded videos, all of these things, the coverage can only go so deep. We only have so much time. Our clients can only absorb so much upfront. And then that guidance becomes outdated right when it's done. WordPress changes, our sites that we build change, and client workflows also can change. These questions continue after launch and sometimes the questions are on the basics, the fundamentals that we don't want to have to repeat that training and our clients have turnover too. New team members miss out on training. They inherit the site, but they don't always inherit the context that comes with it. And then sometimes the training needs to restart over again, and that's never fun. And then we see the consequences which we build awesome tools, great design systems and we would love our clients to feel great using it, not frustrated. And features often go underused and content sometimes drifts from the design and accessibility standards that we had built. So how does a shared training system solve these problems? Well, what even is a shared training system? It's a term I made up quite honestly, but really what it is in the concept here is that we take the foundational guidance that repeats across our projects, the things that are the same and we document them once and we do it extremely well. Then the coverage can go much deeper. We can go as deep as we want and we can learn from our clients and improve our resource over time. This allows our own teams to focus on the custom work. We're not building the same websites. We're building custom websites, but our teams can now focus on supporting our clients where they need it the most quite often with those custom features. And WordPress has matured. In my opinion, it is pretty stable today. The block editor and the site editor specifically are not things that we think are going to need to be reinvented and our documentation have to be updated repeatedly. It feels like a pretty good time to create a resource like this. Also, AI is extremely powerful. It's also matured, although I'm sure it will keep evolving. But it makes the system practical today. It's a great copywriter. It can help us create these training training resources very easily, even for small teams. But hold on, there's already a lot of great WordPress knowledge out there. Some great resources like WordPress.orgs documentation, learn WordPress, and hundreds more. Why wouldn't we just use these? Why are we making something new? We're not in reinventing the wheel, though. These resources teach WordPress, and that's great, but they don't teach our sites. And our sites are unique. The documentation on a custom implementation is very important. Our clients don't want to have to piece together different parts of information, trying to feel what's important to them, what's not applicable. We want to document our own sites and give our clients one resource that's their site and super helpful. The opportunity is to go deeper with support without recreating it for every project. So this led us to shift our thinking from sessions to systems where a session is just one moment. A system can start before that moment and continue well when it has passed. So our idea was to make one shared and scalable training resource. Shared in the sense that it applies to all of our clients and scalable in the sense that we can improve it, expand it and adapt it for our specific client's custom needs. So without further ado, I would like to introduce you to our resource. It's called Learn Modern Press. And this is our resource. This is just an example. You can use it for inspiration, but it's about our custom platform which is called Modern Press. Modern Press is not a new version of WordPress. This is just our own internal framework that we roll out for all of our clients on our WordPress builds. At a high level, I'm not getting into what WordPress or sorry, what modern press is, but at a high level, basically we leverage core WordPress. We use the block editor, we use a site editor, we have custom themes, plugins, c a lot of customizations to core blocks as well as our own blocks. So the documentation that we're going to show right now is largely related to that. But if you use a page builder, your own framework or other tools, as long as you have a consistent system, which many of us do. We like the tools that we like and we tend to use them repeatedly. This gives us a foundation that we have consistency and you can be motivated and empowered to create something like this yourself. So let's look a little bit deeper into our resource. So we have about 100 guides published right now. They cover both WordPress and modern press functionality all in one shared resource. There's no distinction between what is custom and what is core. Our clients have one system. They want to understand that. Not the friction of knowing what tools come from where. It's not technical guidance. It's editor friendly guidance. So we are writing about content, how to use these tools to produce good consistent content and getting pretty deep within that as well. We have walkthrough videos for most of our topics. Walkthrough videos and documentation serve two very different purposes where documentation can go extremely deep. It can help service getting answers and finding guidance when you're encountering a specific problem. But videos, especially for someone new, most of us, it's just the easiest way to learn. Having a visual guide with someone telling you what's going on is just the best way to learn. So, we did both of these things. Our resources guided by humans, but it's assisted with AI. AI helped us build this at the scale that we wanted, with the depth and consistency we wanted, and to maintain it. But it's important to note that this wouldn't be possible without our own human experts. They know the knowledge. They know the clients and they know what communications that we need to relay. And it's very important to make that distinction. AI can't just do this on its own. Our tools also built into project workflows. And this is one of the ways that it expands beyond just being a documentation resource that we've seen before and it turns it into more of a system. So we started with the basics, WordPress basics and publishing foundations. This was important for us to document. A lot of our clients are coming to us new to WordPress, maybe a little rusty or just worked with it in a completely different way. So we wanted to cover navigating WordPress overall and real editor workflows like updating a homepage, creating a page, publishing statuses, all those basics. This is terminology that we feel might just be simple, but not all our clients understand it the way that we do. We also documented the differences between post types and custom post types, what's a taxonomy and how to work with it well and think about systems for maintaining your categories and your tags. So, we're giving guidance beyond just this is what a taxonomy is, but how can you use it well within your own systems? And that's really important guidance, especially for bigger editing teams. We also included administration guidance here as well. Things like what's a difference between different user roles and how can you add users and manage them securely while keeping tips involved with all of these pieces here. Next, we covered deep overviews of all of the major systems inside of WordPress. The block editor is where most of our clients are working daytoday. We wanted to give a full tour of how to use the block editor. Well, looking at the list view and discovering all the different settings that are buried within menus and preferences that are super helpful and most people just work around because it's not obvious to them when they're working in the editor to begin with. The site editor, navigation, and templates. Now, these are all a little bit more risky to update. Our clients have full control over managing these things and we wanted to caution them. So we wanted to give some deep guidance but including warnings as well with how to maintain these items safely. Patterns are super important in our own framework and workflow. We leverage these hugely to help our clients have a great design system that is easy to work with. So we wanted them to understand what they had available, the different types of patterns and the different categories of patterns that we provide to them, but also how to use patterns and expand it for themselves, having power to create their own new workflows and leverage what we've built for them, not just be stuck with what they have right out of the box. We considered stopping right here. This would be easy for us to maintain. It's not too much documentation, but we wanted to go deeper once we saw the ease that AI was helping us with creating our documentation and we knew that there's more ways we can be helpful. So, we went deeper into blocks. Blocks are definitely where most of the day-to-day content decisions happen, especially by bigger editing teams. So, we documented most blocks, not every single block, but the ones that we felt were most helpful to our clients. And we'll probably expand upon this. Again, no distinction between core and custom blocks. We have lots of customizations in our framework to core blocks. And we also have a lot of custom blocks that we provide to our clients. So, it's just all one system. They're living in harmony. We separated them into clear categories within our resource just so it's easy at a glance to see the different types of blocks that are available for different purposes. things like layout and structure, text and writing, media, and utility blocks that are just helpful in certain situations. So, we wanted to keep this nice and lean, a good organized list, helping our clients navigate what they're looking for, uh, and finding it easy. We went very deep into blocks. So, this is beyond just documenting settings. We did cover every single setting that's available in the toolbar, the sidebar, how to use them well, but we also wanted to talk more about when you should choose a certain block over another block and good content rules within those blocks like don't use the column block and having eight columns. It's not going to look good. Use a max of four just as an example. We didn't want duplication across our documentation. So, anyone creating a resource, this is a good tip that we caught early and it was helpful for us. So things that were shared across blocks, we wanted to document deep and just do it once. We can reference it in each block and point over to the topic that goes deeper. So this is things like block dimensions, animations, borders and shadows, things like that that apply to every single block. Accessibility is super important. It's industry standards today. Our clients care deeply about this and they want to understand it. We create accessible foundations, but our clients are responsible afterwards at being good stewards of accessibility and making sure their content decisions work within that framework. So we saw this as an opportunity an opportunity that we implemented in two different ways. So first we included accessibility guidance throughout our whole documentation in the places where it logically the workflows that it you know logically fits within. So when we talk about the heading block we talk about hierarchy when we talk about the image block we talk about alt text. This is a way for people who don't know about accessibility to discover it and discover the importance of it at the moment that it matters to them. But a lot of our clients care even more about accessibility and we went beyond that and created an entire accessible content section within our resource and this goes deeper into all of those topics. It explains it at a higher level beyond just on a single block instance. We also provided a quick publishing checklist right at a glance and we went deeper into the tools like understanding screen readers, keyboard tab navigation and giving some suggested tools for understanding how to go deeper with validating their own work if they would like to. So beyond just the tools within WordPress, we saw another opportunity to expand our resource into our project delivery guidance. So one major example is our user acceptance testing or our client testing process. This is a huge process that takes a lot of effort both on our client side and our internal team. We wanted to be clear and consistent across our teams and we wanted our clients to be able to learn this early on and understand really how it's important and what tools are going to be involved. So we included this in our own resource. It could have been kept separate for sure, but in the spirit of one resource, we included it here and we're really happy that we did. Further, we provide very detailed UAT worksheets worksheets to our clients, basically giving them guidance as to how to verify and test all the different functionality. Previously, we had to kind of manually create this per project. And again, it was a lot of work and inconsistent. Now, we have a great resource that 80% of what we're delivering, we can just reference the guides that we already have. saves us a lot of time and it's getting our clients familiar with this tool that we hope they're going to use day-to-day after with their new site. So all of this fits into a three layer model. Basically first layer is the shared foundation. This is learn modern press. Everything we just discussed is our shared foundation. The second layer is project specific guidance. I want to be clear that we're not getting away from training sessions or custom documentation. That is super important. But this allows us now to focus way more of our time and energy on this area. And it just it matters more to our clients when we can give them this deep guidance here. We're not going to go deeper into this particular um project specific guidance layer, but everyone can do this in their own way. We don't have a framework that's really worth getting into too deep right now. And then the third layer is kind of a bonus. It's extending the shared foundation into in context support where our editors are actually working. So one is imple implementing it directly into some of our processes like our UIT process but also bringing it directly into the editor and we're going to look at this a little bit more closely. So this is exploratory for us right now. It's an active development and we're working through rolling this out to our clients. Basically, the idea is taking the shared guidance that we have. We have this great resource, but we don't expect our clients to be, you know, living in this resource. They're going to live in the editor. They're going to live in WordPress. So, one way we're exploring this is taking our docs and implementing it directly into a sidebar. If you're editing any particular block, like our custom carousel block, there will be a section where you can get a little snippet of a summary of what this block is for. the video will display there and also a link through to the full documentation. It's easy. It's not AI. It's a small implementation for us and it just helps expose this documentation at the place our editors are working. The second way is with an AI chat assistant. So allowing our clients right in WordPress to ask questions in their own words and get back answers that is grounded in our trusted resource. Building upon that is an AI assisted builder. Something that we're really excited to offer to our clients as well. This would be super cool if you can ask the agent to build you a page, build you a se section, or even just show me some different versions that I could use for this particular use case and it just magically appear. Couple years ago that might sound crazy, but sounds pretty a pretty awesome today. Okay, so we're not doing a live demo of our resource. It's public. You can check it out. It's at learn.tri.be. I hope you get some inspiration from seeing it. And I know what you're probably thinking. You're thinking, is this guy done yet? And the answer is no. I'm going to keep going. Or maybe you're thinking, can this get any more exciting? And I think it can. So, we talked so far about why we did this and what we did, but really the story is about how we did it, and that's what I'm most excited to share. So, let's get into that next. We planned, we didn't know how far we were going to go. We didn't really know what we wanted to do here in the beginning, to be honest with you, but we knew we needed to go somewhere. We needed to make some documentation. This is what our project was all about. So, we mapped everything out. We went through the editor. We went through our tools and we mapped out well over a hundred topics. This helped us just to understand the scale of what we were getting into and to kind of build a bit of a road map. We knew we were going to have to present these topics in a clear way to our clients. This was going to have to live in our resource and be organized very well. So, we created some clear categories right away. And this was helpful. It helped us think beyond just blocks, site editor patterns and into publishing workflows and foundations and it was a helpful exercise. AI also helped us with this a lot. It knows what people how people learn and how to give good training resources. So working with an AI assistant was very helpful. Uh again we wanted to reduce duplication so we split out some shared topics and I'm really glad we caught that right at this stage. It just helped our planning. So that's a little tip. Uh similarly, we grouped one-off topics into logical workflows. So things like the terms block, author block, post date block, these are not commonly used. They're usually found within a template. And we didn't want this to bloat our block documentation. So we included these within the post template as an example or whatever workflow it just best fit. It just helped to kind of reduce the number of topics we needed to cover. And then we prioritized. And we didn't start with what was most important. We knew there was going to be learning and we needed to scale what we learned. So we started with what was kind of easiest. We wanted to make some progress. We wanted to learn how our documentation was going to be structured. And that was a smart decision. So we didn't have full-time dedication. We didn't have a huge team building this. This was two people trying to get this done over a month or so. So, we knew we needed the power of AI. We knew we needed a very well-configured AI assistant that could take our source notes, brief notes, and convert them into nearly ready to publish documentation. And we know what we wanted to say. We had that expert insight. It was the overhead of creating documentation and writing and context switching that really was the problem. So the configuration that worked for us and is really working for us and we're going to get a little bit deeper into each of these but at a high level we established the AI assistance role the context of how WordPress works with our modern press framework so it can understand the environment that it's operating within and then the output was super important. We wanted this to be written in the language that we wanted to speak to our clients. So establishing the voice, the tone and the formatting rules was was key. Luckily, we already had this from some other AI assistants we had. So we just applied it here. But this is pretty easy to create, but also a really important um part here. And then we needed some governance. We needed our agent or assistant to behave in a certain way. So decision rules are very important. what structure to use when, when it should ask for more information, and what it should never assume. We wanted to also broaden the use of our assistant to our team beyond just documentation, and we'll get a little bit more into those. We introduced different response modes. And finally, for more structure, the files that were attached to our assistance configuration were really the biggest key here. So having some baseline templates for the different types of documentation, some gold standard examples to tell the assistant what we were really looking for and a content map of basically everything that was published to date so that the assistant can see our progress and start to understand the bigger system as it came together. The bigger the content map became, the better the results became. We did not start with a great configuration. We didn't start with what I just reviewed. Something like that, but it wasn't great. And the early drafts were just not good enough. It really evolved with the work. And this is a super important part. No one is going to just create an assistant and it's just going to do what you need. It's going to be a process. The process doesn't take a long time, but it is a process. So, we started with a few simple topics. We chose a simple block, a bit more complex block, and a custom block. Working through these helped us establish the structure and the depth of the documentation that we were looking for. And we did this with a feedback loop. This is a key part. The AI assistant would take our notes. It would give us a draft that it thought was good. Again, it was not good enough. We had to review it, edit it, and identify what was missing. So, initially, yes, there was some manual editing needed. We needed to help this assistant nudge along to where we wanted it to go. But we still asked it for its opinion. We asked it for ideas and it really helped us along the way. And then we turned those successful decisions back into the configuration. We did not manually go update the configuration. Well, I guess we did. We we entered it in there. But these weren't our ideas. These ideas came from the assistant. We wanted it to understand the problems and for it to guide us how it wanted the configuration to be improved and that was a great decision. It worked really well. In the beginning, we worked with longer chat sessions, so multiple topics in one session. This allowed the assistant to build up some context and to learn across a couple different topics. But later on once it was configured one topic per session straight up and it works very well. And then once blocks were nailed down and our documentation was working great, it took us about 10 blocks to get there and things were really really smooth after that. Then we moved on to overviews and features. So, our system really has three different content types essentially, blocks, overviews, and features. And this covers most of the needs that that we have. Guard rails were super important. We wanted trust to be built and not to be assumed. So, first we grounded the assistant in our own context. Who are we? Who are our clients? What is our framework? How does that work with WordPress? How do our training workflows and client onboarding workflows work? And all of this again established the environment that the assistant is working within. This next one was also interesting. At first, we allowed the assistant to just go find information and it wasn't giving us back what we wanted. We learned that we needed to only use confirmed sources. And this was really helpful. The assistant would never go off on its own and pull information from a source that we didn't specify. So WordPress.org's documentation is great. We know we can trust it. As an example, if we provide our own source notes and say, "Here's another resource you can use." It can help fill in gaps, but only from the sources that we've allowed. This limited and kind of eliminated any assumptions from being made. editor-f facing settings and behavior. They require especially strict accuracy. We didn't want labels and settings and paths to be using different names. It had to be exact. So, we instructed it to never invent these. If we don't provide it, it stays missing. Anything that we don't provide stays missing. The assistant doesn't fill in blanks. It will ask for more information. It'll flag gaps if they're there or it'll straight up omit, but never would it go off on its own and make assumptions. This was helpful for our workflow, but there were times that we wanted more and we would just ask the agent for guidance. And as our configuration and documentation evolved, the answers we would get back were also much more helpful. Even still, with all of these guardrails in place, human review is still required. Absolutely. We can read a great draft that's probably good enough, but when we read it, we're still going to find little opportunities to tighten things up, relay things in the, you know, the way that might be a little bit more understandable or fill in some small blanks, come up with new tips, etc. So, all of this helps AI work within a system, not just a prompt. The input comes from us. We know what we want to say. We are the experts. We have that guidance, but AI is going to help us with basically all the copywriting and giving us some more ideas along the way. The structure comes from the baseline templates. Now, we learned that our templates were too rigid and every single block, for example, was being documented in the exact same way, which seemed okay, but that's not the reality. We wanted some flexibility. So we included within our templates opportunities for the assistant to think about where flexibility should be included and this actually was an idea that came from the assistant itself and it really helped. We set the quality bar with our gold standard examples. So as our documentation got better, we would come back and reconfigure with a new example. Basically we wanted to say this is now what we expect you to be aiming for. And again, our content map. This is basically a markdown file that summarizes every single topic that we have published with a link to where the full documentation is stored in our resource as well as a categorized list and a little bit of context about who the audience is and what the topic is about. It's really a little bit more detailed site map. And it was very helpful for the AI to really quickly navigate our system. To help expand this beyond just documentation, we created another markdown file that was called response modes. Again, another genius idea from our AI assistant. So, this file helps in interpret the way we're asking questions or we can specify what we're looking for and it would allow us to create video scripts which were helpful when we're creating videos. Not having to think about that is just produced and it was wonderful. We also allow our teams to ask the assistant questions on behalf of our clients and get back client-f facing answers, things that we could copy and paste. And it always included a link back to the source in the documentation. And for our own internal teams as well, we can use this for our own onboarding. Somebody new to our company can now learn more about our system and we can ask the assistant questions and get back answers that are a little bit more technical. Here's an example of an AI prompt that we would use. It's not an exact representation. We would probably typically provide a little bit more than what you see here, but I just wanted to illustrate that this is something that's really easy to create. Bullet point lists. We don't need to think too much about organization or writing or the language we're using. All of this feeds into the AI system and we get a wonderful output that is consistent, clear, concise and it saves a lot of time. Context switching is now eliminated. Our team can shift from one task over here to AI and get some documentation pumped out in between on their lunch hour if they want. Not that we did that, but you see what I'm saying. This is nice and easy to use. Here's a look at our editorial workflow. This can look very different. There's probably ways to even optimize this and have AI integrated directly into Google Docs or even directly into WordPress and save some steps. But we wanted a little more control and we wanted our team to be able to collaborate. We use Google Docs. So, we would start with our source material. This would get sent to our AI assistant. It would give us a draft. And now you can see the feedback loop is happening here where a human is always reviewing. We're going back to AI if we need to. At first, we might have six or seven rounds of revisions with the first documents, but by the end, it's one or zero. It's it's nailed down. And then we would publish and then we would do videos afterwards. We didn't want videos to hold us up from getting our documentation out there. Again, the more documentation that we had, the better our results were and we can move much faster with it. So, we published and then videos came later. And then is the maintenance is the scary part. And honestly, we were a little worried when we had all these guides. How are we going to maintain them? I'll get into that in a second. So, this is an ongoing system. And one little tip, if you're not familiar with Markdown, get familiar. This is AI's love language, especially for documentation. This made our content portable across AI, Google Docs, and WordPress. We could copy and paste Markdown and not have to touch any formatting right from AI. into WordPress. So AI came to our rescue again with maintenance. Now this is still a new platform for us. The maintenance that we've done on it has only been going on for a couple months, but we absolutely do not want more stale training. That's the whole purpose of doing this to begin with. So we have two main inputs that are really helpful for us. First, we track our own framework changes obviously and typically the work that we do has some developer notes or scope notes. We can just provide those to our assistant and it will find the topic that needs to be updated and guide us through that updating. Similarly, with WordPress, we can use release notes and field guides which exist for every every release. feeding these into our assistant. We'll flag all the topics across our documentation set that likely need updates, but then we'll work individually on each topic one by one because AI helps accelerate this, but people still own it. We're not letting AI go free with updating our documentation, at least not yet. So, AI has become a big part of the story, and that's because of the scale that it made much more practical. But the value wasn't really producing more documentation. It was helping us turn this into a system. A system with guidance that is structured, reusable, and maintainable. And that leaves me with a thought that I want to leave you all with. Training doesn't have to be just a deliverable. It can be built into the tools, the workflows, and the resources that people use every day. If there's one thing that I hope you take away from this talk is to just look internally at your own support for your clients and the training that you offer and consider if AI opens opportunities. What does it make possible to allow your clients and your customers, people using your websites that you build and your tools to work more confidently and independently? Thank you everybody. I hope you found some inspiration from this talk. >> [applause] >> We have a little bit of time here for some questions if we have any, but otherwise you can find me in the lobby or Tuesday, Wednesday at the Nexus booth in the sponsor area or connect on LinkedIn. >> Hi. Um, I actually have a couple questions. This was really cool. Thanks. Uh so first question is did uh client common questions factor into your selection of topics and the way you organized them at all? >> That's a good question. It it uh probably should have. It quite honestly didn't. We ended up just covering kind of everything. Um but we know our clients very well. We have great relationships and I have worked with many of them. So it was kind of guided just by our experience. So in a way, yes, >> that's fair. I I know it was a quick project for you. Um, so the next question is, do you know yet how the clients actually use these resources? Is it more ad hoc in the moment I'm doing a specific job so I need to learn how to do it or do they frontload the learning as a sort of training session? >> It's another great question. So this is actually a pretty new resource for us. We've only started rolling it out to just a few clients. So, so far the reaction has been glowing. Our clients love it. They're impressed that this even exists for them. And a few have started using it early on. Uh the biggest actually has been for existing clients uh who have new team members and our own team providing it to them to get them some answers and show them what we have available. So, um I guess still TBD on exactly how that will go. >> Thanks and good luck with your in context learning. >> Thank you. Any more questions? >> First, thank you for uh attacking the topic. I think we all hate documentation. So, uh it's much appreciated. Uh the question I have is within the context of curating this AI assistant, could you elaborate on where does it live on like a VM inside of your WordPress instance? um how would you minimize hallucinate hallucinations from this AI and then uh yeah just kind of kind of what the configuration is for that setup. I'm curious. >> That's a great question. So quite honestly this is AI basics with how it's implemented. We didn't have developers involved essentially and a good point is actually we started with uh with chat GPT with a custom GPT. We later migrated over to uh claude with a claude project and actually that was a great test of our configuration because we were worried that is things going to change a little bit and it didn't it was it was solid. So we're essentially working directly in claude project with the assistant there uh right now pretty basic anyone can do that. Uh there's a lot more further that we could push this with like you said with a with an MCP. There's a lot that we are going to explore now that we've proven this is working for us and we want to expand it out. Second question. Um so hallucinations were rampant at the beginning. The guard rails that I discussed in this talk here were what were most important. So having the the baseline structure and most importantly the most important rule for reducing hallucinations was to never invent any settings at all and to only use confirm sources. This really contained it to you're going to use our source notes and if there's a link that we provide you can use information from there nothing else. And that made a huge difference in terms of what we were getting back. Uh really great talk. I had a quick question for you. Um going forward, you had mentioned it took a team of two roughly a month I guess combined to do this. What's your expectation going forward because you have so much documentation here for uh ongoing staff time to keep it current and not stale? >> Uh it's a great question. So we're we're lucky enough to have a reasonablesized team. We're not a huge team, but reasonable. So for for maintenance, our process really is it's it's kind of tied to other processes quite honestly. So when new WordPress releases come out, we already have a pretty robust testing and documentation internal process for logging the change logs that matter to our team. We can use this very easily now to give it back to our assistant and typically might be two or three hours of work after that point to go update the applicable docs. Each release might be different depending on how much the change is there. So, we're not too worried about the maintenance part at all because we've been through a couple WordPress releases now and it's been okay. It can obviously depend on how big of the changes are out there in terms of what we need to refactor across our documentation. And then where do we go from here? Um, a couple things that there's a lot that we still haven't documented. We have great coverage on WordPress block editor, site editor, administration, but things like plugins, we have a lot of plugins that are a few plugins that are a part of our core system. Things like redirection, Yoast or RankMath, there's a lot more guidance that we can provide on some of those tools which we haven't done yet. And then things like e-commerce, WooCommerce, there's a lot that we can also document there. Uh, and that's what we're working on next. All right, I think we are at our time. Thank you everybody., Building Training Systems, Not Sessions | Andrew Adam, Andrew Adam, 01m0ar73dnx0wq273m295r0wzr.