I hope you remember our talk from yesterday. We talked about AI-wrapper prototyping, and today we want to dive a little bit deeper and show you more details of how the team around Union Investment and PRODYNA collaborated on getting this thing to their product owners. So today, from prompt to wow, how Union Investment empowered their product owners to generate UI and UX experience within a few days and not weeks. Okay, so I'm not Sebastian, I'm Stefan. Sebastian called in sick today, so unfortunately I'm going to stage. And together with Martin, our digital product designer, we will walk you through our experience here. Okay, so again, as yesterday, we want to talk about who's who, what did everybody contribute to the full picture, and then we want to repeat the chatter from yesterday so that you remember it again. And then Martin will walk you through the very details of their accomplishment. Sorry for that. Now we have it. Okay, so what was the goal of the whole project? So the goal was to have one workshop shared with people from the product team and the stakeholders to generate UI and UX experience in one workshop. So that is one day with a little bit of preparation, which we have seen yesterday. But in that workshop, you basically start with the content creation, the iteration of the properties and the prototype, and then the validation of, okay, this is what you really want. Right. And so Human Investment, contributed their product expertise because they know their markets, they know their stakeholders, and that's what they brought to the equation. And we brought in our AI support, the delivery experience, because we have been doing that for quite a while, as we talked about yesterday. So the two teams are connected, and then they came up with this workshop as basically an internal product for the product owners. And what is it all about? It's all about getting the requirements into a value stream. We talked about that yesterday. So it's very important to get new ideas out to the market very fast. And this is true, especially if you have political decisions, and like all of your competitors are jumping on that topic and getting out the content within like two weeks, and you're standing there and saying, okay, I take like two weeks to talk to the stakeholders. I take three weeks to do prototyping and user testing, then I do development and yeah, I don't know, in three months, maybe we have the website live. So that is not good for your income and your revenue. So you need to be very fast, right. And in that agile structure that we need to investment build up over the last three years, we have these domain journey teams. So they are defining the journeys for the end users. And then you have the subdomain teams who are responsible for different products, like the Magnolia CMS or calculators or FAP Prod, some information. And these teams collaborate and need to put out the ideas that came in as requirements. So that's again, the detailed picture from yesterday, if it comes up, then I just press space. So we have the ideas and the domain journey teams do a lot of iterations with UX design team, and then they hand it over to the development team to take a look. Can it be realized that like that or are there drawbacks or possibilities in the design? And then eventually, when you have a lot of iterations, then you go to the coding. And this takes a lot of time. And especially with this first idea generation ATX design is what we want to shorten. And that's when I invite Martin onto the stage to talk about the solution. Thanks, Rippa. Right. Good morning, once again. Awesome. So this is the first slide actually where the term of prompt comes in. And as Stefan mentioned already, for the Union Investment Project, we figured out early on that it needed a bit more than a bit of preparation. As we figured out because it definitely was a brown field project and their experience and all the different artifacts they have created over a couple of years. Act of this project. Let's say it needed a bit of preparation in terms of making it really machine-readable and also collecting different sources. So they really could be used in Shirtam now. So when the idea came in, we figured out a way to really connect all the different sources. We tried to set up a structure that handles different agents, sub-agents in the end and was able to create this prototype. That was our goal. Out of a workshop situation where different stakeholders, product owner, the ex-designer, top meta experts came together. So we really created this first wow moment for all of them, not only visually, but also in terms of content. The actual text was already up to far from their point of view regarding tonality. It had the right product information already within and so on. So it was really a state that they said this is great to further iterate on and further validate. Terminierst du? Oh. Right, so actually we decided to have like three pillars, so divide our preparations to our three pillars. One was the context. What is the context that was already there? They had definitely their target groups defined ahead. They had the whole company information already ahead. That various decision criteria is already defined a font, but it was all over the place, basically, to put it. Some of the information was in Confluence. Some information was in some internal pages, that there were some documents, there were some images that really represented the page structures. For example, we had the design component repositories in GitHub, but it was missing other page descriptions. How did Magnolia templates look like? What is the overall pattern, top-down of a page? How do you introduce into a topic? How do you close the topic in offering a scheduled appointment with a consultant, for example? And this was all distributed numbers that we had to combine to really reflect on the expertise. Then there was the design layer, UX patterns, Therian to Play that we also had to combine. And also, look, what should be the technical framework that we're going to A4, so we can really use the prototype later on as an artifact to build upon the next stages, generating user stories out of them, being able to map Magnolia templates out of them, and really to fit it into our agenda guest DLC. The prompt guidance itself was a topic of its own. I mentioned yesterday, and we can see it in the next overview again. I think I've shown this yesterday already, but today we're going to dig a bit more deeper into the structure. The prompt guidance came in with set two, which we called a filler agent, which was the way of a so-called prompting master template. Prompting master template was divided into a various section, and it was like a blueprint without the content, without the expertise that could be filled. And it was very strict in the beginning of really taking this raw integrity questions from step two, the integrity agent, and filling out all those gaps and asking questions again in case there was something missing, for example. So you could remember that in the first step, users barely mentioned like a couple of user journeys, but probably the group of workshop and members did not define them end-to-end. So this would be number two, where it was still the authority of the duty the agent would recognize there are some user stories maybe missing in definition, and you need really to fulfill these to get to a higher prompt in your scope. And the prompt readiness score, that was under part number three, the validation check agent empty context window, starting out of then really checking about the structure of the system. Then it went into Figma Make, and I go to the next chart, where we go a bit more into the details of what was the context and also the expertise documents that we fed in. We also allowed in the very first stage where it says interview agent to allow the workshop members to add maybe additional documents into the progress. So it was really a hybrid session. Some people were on-site, some way joined in remotely, and then it started like a real collaboration. One person was putting his voice input into the system, had it transcribed. Other people were adding documents about product information or the chat that could be thrown in, and all of this made really the, I would say, perfect context for the prompt to be enriched on. In the down left corner, we see the domain knowledge context. We see the context index. I'm going to explain this in a bit. We see the person journeys also on the different target groups and persona. We see product information already coming in and the domain context. I think it's important to mention that the main context for new investment just represents one out of many different domains, and it also has only the knowledge about this particular domain. There will be a point later on when you talk about next steps when we see that we need a bit more of an orchestration there for different domains in the future. We're able to really distribute from a starting point, an orchestration agent, for example, to the knowledge of these different domains than we talk. What we created initially was always like an index file, and this also represents, at the very end, guidelines for the actual building system, the generative AI. So we always started with a kind of an index, and we treated in our doing, the AI or the AI agents always like young professionals. So we said to ourselves, we need to explain the processes and the knowledge to them as if we were a guiding, a young professional. So if it's not clear, or if it wouldn't be clear to a young professional, probably also isn't clear through the AI agents, so it follows a kind of a logic. And therefore we said, you need to create an index that is like an easy navigational map for the AI. If you're searching, or if you're going to this road, look into this folder. If you are looking for deeper information about target groups at the sonar, go into this direction. If you want to use components, this component usually uses this icon set, uses or is been used typically in this kind of template, on this kind of page padding, and so on. So it's like a network of knowledge which starts frequently indexed in the very beginning. The preparation for the actual alternative AI part was also based on GitHub as their coded component source. However, we figured out that it also needed more preparation than just taking the components from there. The meaning was there. It looked perfect on a component level, but when we created the first pages, we figured out that the whole understanding on how online investment creates their own page templates was missing. So AI did not have a clue what was the header typically like, how to treat like an introduction story, how to distribute it into different knowledge topics, how to close the whole page at the end, getting a FAQ section, getting a CTA at the end, on how to schedule a meeting, for example. So this was all unknown, and we had to extract this information, as I said, from different sources here. What we also did was to scan or to analyze the structure of given Magnolia pages where they said, these are our hero pages, and we like to know or to use the best practice of their patterns. So analyze them, know the patterns afterwards and saw there's returning patterns that we could reuse, and we gave these structures again to the generative AI in the end to be able to really follow up on those patterns and to give the AI agent an idea how pages are structured. Next up would be the demo that we've recorded. It's not really a live demo, since it... I don't know. First, and this is just for one domain, the knowledge, you don't have to read all of it. This is really the knowledge that we extracted for just one domain. And you can see it's quite a lot. It's still not perfect. I think we have a lot of ideas how we can improve, but also we have a lot of ideas what is still needed for other domains or how to interconnect with different other topics. For example, this didn't reflect really on legal topics already. So for example, if you're creating a page, especially in the fun sector, you have to cover also legal topics as well. And to figure out, it might be a good idea to also include those topics as a knowledge base into the system and see if we can achieve an 80% solution already. So it has been checked. It has been validated upfront before it goes to the video department. Now, I think, yes, we will see a video in the background and it starts with the very first agent. I think it looks quite fluent. Have you read that? So unfortunately, it's German, so I'm sorry for that. What happens in the background is that we start relatively lightweight. It's a low threshold and you can imagine that the workshop group is really sitting together and one person is speaking to the microphone doing voice-to-text transcription and putting his idea, his product idea into the system and the agent in the background who knows about the domain knowledge and has a question structure as a knowledge base asks about information. It is able to really fill out all of the questions, not necessarily in the top-down order, but also to go down to question number one for the answer for that. If that has been mentioned, for example, the very first voice input. So the idea was really to speak freely to this very first input. This is a fast forward. So you can see there's a lot of back and forth. It's really like a conversation between the workshop participants and the agent in this sense. And we also figured out a little technical detail. We started with GPT 5.1 in a high reasoning mode and that took like one, two minutes for getting back the first answer, which was way too long for this conversation. We were then able, because it was their internal tool to upgrade to 5.5 in no reason mode, which was totally sufficient for really this dialogue of dimming information in and getting fast answers back, which was really important during that case. Secondly, you will see the filler agent, meaning it takes over the raw answer from the very first agent. And you can see there's also some questions that needs to be clarified. So he figured out against the structure that we put in as an empty template, there needs to be some information to be added. So for example, it's a public web page. There's no login required, which is like the input method that tends to go as touch devices and keyboard as well. And then really general arrangement can see from the structure, it follows really a structured form in a way following up to eight sections. And it's a lot of information that is already in there, a lot of knowledge from perspectives that we put into the stat. Third stat is the validation agent where the result really from step number two comes in. And again, empty context window is really again checked against those measures. And in the end, there will be a readiness score at the final prompt. This is Figma Make them. As you can see, the prompt goes in just on the left input field. And we just say implement the attached prompt, which is already ready. Unfortunately, the colleague hasn't chosen the appropriate model. So I really recommend to choose a good thinking model right in the beginning of starting your prompt, maybe also right towards the end of doing refinements. And as you can see, I think it was a fast forward five to six minutes that you can already see a page that has been generated using their imagery, using their wording. And it was also interactive, meaning you could go down and see different teasers. Even the calculator has been generated that really takes out for like a little example calculation in that sense. And was functional. Could also imagine to go further into this direction of calculators because they have a whole range of calculators already being tested out. And it can start with the CTA. All right. I think for them, it was really that wow effect after just one prompt as we have aimed for. it looked like their products. It had their wording. It had their really totality inside. And it took also a huge set towards like the contents of the actual page. So this taken and extracted for user stories has already much more information than just the Figma design, maybe Figma prototype, because we have prompted for all this usability, all these different interactions that have been included. that this is something that sits on the prototype and can be handed over to the next stage, which for sure would be the goal to have a ship feature in the end. But on the very left-hand side, we see that validates prototyping, which sure needs to be iterated a bit more, I think, during that workshop. maybe also, and this is really recommended, use it for real user tests, real user validation. So what you do with the time that you saved in the whole process, you have to become more effective. You could use the time and just ask real users about their opinion and feedback to the system. So immediately it becomes a couple of rounds of iterations before it becomes a backlog slice. You can do the tag refinement, the mapping, the Magnolia implementation at the end. And it becomes a ship feature in much less time. Okay. So what were our key takeaways from the whole process? The speed, as we figured out, did not come from just writing two or three lines of a property code. And also, it required much more preparation actually before the print. So the own knowledge needed to be curated. It needed to be conserved to be machine readable. It was really like a hand selection to pick the right sources that were also recent sources and to have them extracted as information. So it's not about skipping expertise at this point. You will get that speed back once you have established really the knowledge for one domain so you can really reproduce results that look more or less the same each one of the prompts. So therefore, it's also the structure and the check for the structure again to really get to results in the end that can be reproduced. Also, what we figured out, product owners can validate much earlier if the prompts carry a certain amount of expertise or context already. Meaning, you don't come to that state where you have wireframes or baronet structures and so on in the beginning and you had taken weeks and days again to reiterate on those and have your touch points. You're skipping a few steps on the way. There's also a shift in thinking, I think, to get to a point where it already looked almost like the magnolium page and you can iterate on that in different directions. Very change-changing. as I said, you are now free to really want even more user tests and usability tests with actual users so it really allows for that and you also have to think about or to include the framework from the very beginning so it doesn't make sense to really start for example with Think or Make if you're planning to have an Angular feature in the end because Make doesn't provide for that at the moment at least so think about which system to start with and as a consumption as well the very last point it's really a speed up or a win of effectiveness you can do things nowadays in days instead of weeks but you don't must stop thinking and to really skip skipping expertise. With that thank you so much and we are open for a couple of questions I have now on stage Stefan, I'll ask to come to me or we will be around until the end of the day for any additional questions thank you thank you very very much for that very insightful talk but I think speak for the room when I say wow no just me any questions from the room oh one over here Tatjana wait for the microphone please just a quick question about the agents that you created that's me how long did it take you to validate those agents that they were in the way you provided of course let's say for each agent how to guide those agents read about like three to four iterations only but we we played a lot could be different modes of reasoning so to say so we had as I said we started with pipe void one at the beginning with high reason which was much too slow then we shifted to tpt 5.5 at the end with low reason which was totally sufficient and our next step is to not only copy and paste like the information over but create a multi-agent system out of it so we had one orchestrator agent in the beginning that would hand over the results automatically to the next sub-agent on the chain and he also knows about their task in the end what we figured out so we compared the results and this also took some time of iterations to compare the results and we figured out that the approach in one go it was less output I think it was like 25% less output which is also dependent a bit to the reasoning mode so another idea would be to start with no reasoning switch to a medium or high thinking towards the checking process because essentially there was nothing crucial missing as we figured out it was just less redundancy it was a better structure but it was less redundancy redundancy however is important actually in the last step so if you enforce certain topics with a certain amount of redundancy that's even better so it can really make sure it will be different in the system thank you very much do you have any other questions we've got time for one more anyone's got one no okay thank you both for the talk and on that note thank you thank you thank you thank you thank you