Detailed Notes
We’re back with another Building Better Developers with AI episode — and this time, we’re revisiting a favorite topic: demo-driven development.
If you’ve ever struggled to get stakeholders, clients, or even your own team aligned on what a project should look like, this episode is for you. Rob Broadhead and Michael Meloche break down why interactive prototypes and clickable demos are such powerful tools in the software development lifecycle.
💡 In this episode, we cover: • What demo-driven development is (and what it isn’t) • How prototypes improve communication and reduce costly misunderstandings • Benefits for developers, managers, and clients alike • Pitfalls to avoid so you don’t end up shipping your demo to production • Using A/B testing with prototypes to validate ideas fast • Tools and practical tips to keep demos lean and effective
🎯 Whether you’re a developer, product manager, or business owner, you’ll see how demo-driven development can save time, reduce risk, and get everyone moving in the same direction.
đź”— Full blog recap here: https://develpreneur.com/demo-driven-development-software/
⸻
👍 Like what you hear? 👉 Don’t forget to LIKE this episode, SHARE it with your team, and SUBSCRIBE for more insights on building better developers and better businesses every week.
*Follow-us on:*
* [email protected] * https://develpreneur.com/ * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://x.com/develpreneur * https://www.linkedin.com/company/develpreneur/
Transcript Text
[Music] Okay. So, I pasted that in. All right. Boom. Click re book record. And now we are into the next one which is the power of clickable demos in the software development life cycle. This is my favorite ever. I love the whole concept of clickable demos and how you can turn those into just like the most powerful contraption for getting thoughts across and stuff. It's rapid application development essentially. But I loved it since the RAD was first invented back in like the 80s or whenever it was when it was well okay the word was then but then they added it you a little later when it became software development but I am a big fan of like let's get features in front of people let's get feedback so this one is going to be fun once again we've thrown this out to uh Google's Gemini instead of chat GBT so we're gonna get a little bit different uh thing but this is uh it's interesting like what it does is it like gives me a nice little uh it gives me an actual document that I can take and I can do something with it u which is a little better than what chat GPT does but that's yeah that's one of the things that um you get out of these tools is like some are a little better than others and you can you can uh talk to the AI and get it to send stuff out in a certain format and stuff like that if you want a good example um I took go out to the rb-ns.com site rb-sns.com Uh, and you'll see if you go to the about us, you can see about the team and you can see where there's each of the pages was is basically the same format. And that's essentially what I did is I said, "Okay, here's my content. Pick this format. Bam, apply it." So that I don't have to type out all that stupid stuff or I don't have to worry about copy and paste and things like that. And it made it a lot easier and a lot more error-free. Simple things like that are great ways for you to get your job done a little bit faster, particularly the repetitive pieces of it. And then sometimes we'll give you a little bit of bonus too, but you got to watch out because sometimes it also will get lost and the next thing you know it's like, you know, you you create four things that are supposed to look the same and the second one it didn't create white, but now it's just like, you know, it's like the old telephone game where it's like it was wrong and now it keeps doing it wrong everything from there. So check it out just like you do everything else. All right, that's good enough for now. Enough vamping. We're going to do a little th uno. Ah, we are back for yet another episode of building better developers the developer podcast. I am Rob Broadhead. Roberto Broadhead may maybe uh and I am again one of the founders here and also the founder of RB Consulting and not a founder of foreign language speaking because still working on that stuff. RB consulting we essentially we are have fractional CIO. We'll sit down with your business, with your owners, and we're going to talk to you about your business. How do you run it? What are the processes? What are your customers? What's the journey like? How do you fulfill all of that stuff? Your service, your product, all of those things that make your business run. And we're going to even probably extract some of that out of your head to make sure that we have a clear picture of the processes and the steps. And then we're going to basically, it's a process improvement project at that point. And basically, we're going to walk through and look at ways to improve that. Whether it's removing steps, whether it's uh integrating systems, whether it's simplification of the steps, whether it's automation so we can get past errors and things like that and do it faster. Or maybe it's innovation. Maybe we're going to take some stuff and we're going to switch it all up and we're going to turn out a new solution that combines multiple steps maybe into one thing that now is much more efficient. However that happens, we're going to help you build a road map essentially to say first, this is where you're at. This is where you want to go moving forward. We're going to help you, you know, get those low hanging fruit, solve some problems early on, but then also position your business so that you're in better shape for six months or six years from now when you are growing at whatever rate it is. Just like in a lot of cases, businesses hit that point where they're like, "Hey, we just got a huge new customer. Oh crap, we just got a huge new customer. We got to go hire 10 new people." Well, sometimes if you talk to us, we can help you find better ways than just having to go find hire more people. Instead, you can make the people you have more efficient. So now you have to hire maybe five instead of 10. And it's something that's actually reasonable and feasible instead of you just running into a corner and curling up in a ball and crying. Good thing, bad thing. Good thing is I'm not having to curl up in a ball and cry at any point. We are not getting swamped with customers that are, you know, taking up too much time or anything like that. Uh also good thing of that is it is it has allowed me recently to do some working in my business uh on my business instead of in my business. And so after a period of being very very busy for quite a while and doing too much in the business, I'm finally able to catch up a little bit on the on the business stuff which I've mentioned a little bit in recent episodes where we were updating the RB consulting website and actually I've even been looking at uh some stuff on the develop developer side. Uh have done a couple of changes and things like that which is what everybody should do. just periodically do a business checkup, take a look at what you got, check out your material, do some updates, uh see what you can do to, you know, better really, I guess, enforce your brand and things like that. Uh bad thing is is that it's I'm having too much fun working on my business and it's like dragging me away from in my business at times. It's one of those it's like, you know, you get in get in this right certain mindset and you're just like in that creative mode or whatever. You're like, I want to stick around with this. I want to go. And the next thing you know, you haven't just built like a, you know, blurb for one page. You've now like got an entire marketing campaign that you've created because you're just like you're you're in the zone. I have been in the zone. So, I'm going to take a deep breath and pass that over to Michael so I can recover just a little bit. Please introduce yourself. >> Hey everyone, my name is Michael Mlash. I'm one of the co-founders of developer building better developers. I'm also the founder and owner of Vision QA, where we help businesses run better by making sure their software works the way it should. We start by getting to know your business, reviewing your products, understanding your goals, and assessing what's working and what's not. From there, we recommend the right solutions, whether it's building a custom tool, fixing what's broken, automating your testing, or helping you prepare for a smoother launch. Our goal simply is to take care of the tech behind the scenes so you can focus on running and growing your business with competence. You can learn more at envisionqa.com. Good thing and bad thing. Uh good thing, my birthday's coming up. I've got a game coming out a few weeks after, so I'm looking forward to that. So, I'm getting a little stoked. Uh bad thing, which is kind of leading to the good thing, is I am way too far in my business right now. I have too much work to do from too many things. So, um I'm burning a lot of hours. So, I'm hoping that all that will wrap up. I'll get a little bit of working on my business time and then game time for a little bit. I can't even spell game anymore. It takes up too much of my time. So, this episode we are uh I actually failed to mention this right at the beginning, but you guys have been hopefully following us. But we are going back a couple a couple seasons, taking episodes, the topics, and we're dumping them into AI and seeing what it spits out. Uh we're doing it in Google Gemini this time. We did chat PPT before, but the last couple episodes now we're going to check out Gemini. Uh the topic, the title originally was the power of clickable demos in the software development life cycle. Uh and so it says, you know, hosts your name, the co-host name, opening one to two minutes, intro music upbeat and energetic. Holy nailed that. Start with the scenario. You're in a meeting showing off a new feature. You've got the mockups and the flowcharts, but the client client just can't seem to get it. What if you could give them something they could actually click? Uh, introduce the topic briefly. Explain that this episode is about leveraging interactive clickable demos, not just static pictures to get better feedback, align teams, and build the right product the first time. I'm going to come back to that actually. But part one, what is a clickable demo? A discussion item. Define an applicable demo. What it is? What it is? a series of static screens linked together with clickable hotspots to simulate a user's journey. What it's not a fully functional prototype for the or the final application. It's a loweffort way to test high impact ideas. Discussion item with spectrum of fidelity. Low fidelity simple wireframes, gray boxes, and basic text. The goal is to test flow and logic. High fidelity polish UI designs that look and feel like the final product used to test aesthetics and micro interactions. The sweet spot. by starting with low fidelity and only moving to high fidelity when necessary is a smart strategy. Now, I want to combine a little bit of that. Um, it's not just static pictures. There is some level of interactivity and it's not just because sometimes I've seen a a clickable demo and it technically I guess could be is it's just like a PowerPoint. It's like a slide and then a slide and a slide and a slide. that's okay and that does sometimes uh serve the purpose. But I think with a clickable demo, there's some things that I found that are very valuable for you moving forward that you can do that are make it a little more demo maybe and a little more real. Uh but then it also, you know, you don't want it to be too real because you don't want to be spending too much time. And this also gets into the fidelity side of it. A nice thing about a clickable demo that I found with a with an application is to actually throw up some screens is just get some basic screens up. They don't have to have a lot on them. And sometimes just take one screen and you can copy and paste it a couple times. Now you got four screens and you can click on menu items and you can open the various screens. It's yes, it takes you a little bit of time, but you should be able to spin up something like that within hours and have something that allows you to actually have the uh the rudimentary pieces of your application. Sometimes you can, you know, if you've got a week or two to do it, like maybe you've got sometimes you've got a first sprint that you're working on of two or three or more weeks, then you can do stuff like you can actually go through and think about like your CSS. You can think about your general headers and footers and look and feel and some of those kinds of things, which gets you into more of a high fidelity. Uh, but then also that's at the expense of maybe some of the functionality that you would want to show. And this is where the balance is. I think you need to you have to show something that isn't so god-awful ugly that they're like running away, their eyes are bleeding and they're like, "No, I never want to see that again." Or that they see it and they say, "Well, geez, you guys are completely incompetent because my kid could do a better app." Because there is some level of expectation. So, don't make it just completely hideous. But that depends if you can have some functionality that is a proof of concept or solving a problem that it's that they don't normally see then you can you know you can make it less low lower fidelity less pretty but focus on like look we are solving your problem. I have seen that in a couple of cases where I had something that was not a very good interface. One that I remember way back where it was basically it was it was a interactive way to lay out uh wallpaper and floor coverings in a building and it was in three dimensions and people are like I don't know if that's going to be any good. But then we had something that had a very horrible interface around it. It was basically the picture of the building and you could rotate it and you could click on something and you could select a product and it was a you know a lot of those pieces were were pretty ugly and they were very hardcoded but it gave us a start and then we could go back and we did have to rewrite pieces like uh the selector stuff. Yeah, you had to go back you had to rewrite it so it actually pulled data from a database and some things like that but it gave us a starting point and it gave us something to fall back on at any point as well. So if something technically wasn't working, we could go back and look at like, oh, okay, at least we had this thing that was working. Now let's compare the two. So there is a lot of value in this that is part of the implementation to me. It's part of the implementation and not just the presenting it to the user. But if you can put a proof of concept in there, if you can have something that they're like, I don't know if this problem can be solved. you can make that a part of your clickable demo, then you're really moving the ball forward because you're saying, "Look, this problem we we have shown that it can be done and now you can have the discussion of how to do it better or prettier." So, speaking of better and prettier, let's see what you can do with that. Where do you want to go with this one? Well, it's funny because I I know you kind of poked a little shade at the whole PowerPoint thing, which, you know, I like to do at the initial start to kind of just figure out what I want to do even for a clickable demo. Uh cuz I like the wireframe approach first because it it kind of helps at least me put together, okay, what's kind of the uh interface going to look like? What are because you kind of have to have a little bit of a basic understanding of what the interface is that you're going to be working with. Is it a mobile app? Is it a web app? it, you know, what type of application are you building? And then you structure around that. Okay, if I'm building a wireframe, do I need a menu? Do I need a slider? There's just certain features you need to think about when you're just kind of doing some UI work. But beyond that though, I love the clickable demo idea because you can, like you said, get something in front of them, but you there is a caveat to that because if you put too much into the clickable demo, you could potentially be driving the direction of the application or the product in a way that may or may not meet the requirements of the customer. So, you could build this nice cookable demo. They're like, great, that's awesome. Let's go with it. And then you find out 6 months later that oh we missed a whole bunch of things because what you showed us was kind of gave us a false direction of where we wanted to go. It's like you get halfway and it's like oh but we need to really do something else over here or add this. So you could miss some things. So, just be a little careful with what you do with these clickable demos because they are very powerful. And in some situations, you end up going to production with some clickable demos because it's like, oh, this is good enough. Publish it, get it out there, and then then next thing you know, you have this very clunky um, you know, thrown together code that's now live that you now have to support. So, there's a lot of good things to this. Um, more positive than negative. Just I want to throw out some of those caveats to just watch out for if you do start going down this approach. It could be too successful and you could be live, which is not necessarily a bad thing because that means you won the customer. But the bad thing is you may have to spend a little bit more time cleaning up some behind the scenes stuff very quickly that you didn't plan for initially. >> And I think that's part of it is that like clickable demos can be very uh rough and and sort of just like thrown together. I think that if you if you do it right, you actually have your own little framework or something like that or you know your code repository somewhere where you can pull some of those pieces in and they're not completely thrown together. So it's not I mean you can do them as a one and done but I think ideally you want your clickable demo to actually be a demo that you can build on top of. So be very careful that you don't just like throw crap in there and uh and there is going to be some cleanup. There will probably be some technical debt at some point of like oh we've showed them this but now we want to pull it back out. So those are some definitely some things to to keep an eye out for. Now as we go to part two, the why benefits for every role. Uh 8 to 10 minutes it says discussion item the value proposition for developers. Fewer surprises catching design flaws and usability issues before writing a single line of code. Better communication resolving ambiguities by physically demonstrating a flow rather than just describing it. Confidence and estimation. Understanding the user's journey helps in breaking down stories more accurately and identifying potential complexities. Discussion item. value proposition for product managers and designers. Rapid idea validation quickly testing multiple design concepts and flows within a large time in without a large time investment. Effective stakeholder communication getting buyin and feedback from nontechnical stakeholders in a language they understand. Clicking and interacting uh discussion item value proposition for clients and end users. Tangible feedback. It's easier to say I don't like how this works after trying it than just seeing after just seeing a picture. Early problem identification users can spot logical flaws or confusing flows that would have been missed in a static review. Now I think is where the where the clickable demo becomes most valuable is when you've got people that are watching you or you know whether it's interactive so they can do it or they're watching you go through a clickable demo and you click on something and you you enter some data and then you hit a button and then something happens. It is amazing how many times, and this is why I love clickable demo so much. It's amazing how many times that I've been in front of a customer and we've sat down and we've talked through requirements and we said this is how it goes and they agree and everybody's awesome and we're all the same page and we put a clickable demo in front of them and they say well wait a minute where did you do that and it's like well you've never told us what that is so let's go talk about that. What is this that that you are missing? And particularly this is valuable when you've got a representative of a user but not an actual user. There have been many times that we have had a clickable demo where we invite in you know frontline workers or people that are actually going to use this as opposed to whoever the representative of them is that maybe doesn't do it as often. And you will get questions or they'll say well wait a minute how do I get to from from to point B from point A because I never do it that way. I always have a A B C D and E before I get to there. And those are the things that are that's part of the bonus of and the benefit of uh to me of the clickable demos that it is going to draw that kind of stuff out. So from the and it works great for the clients and users to have that conversation around it. It's something they can see they can almost like feel and touch and say yes this is this makes sense. Uh but then as developers it gives you a way to it's sort of it's not quite the 8020 rule but it's something along those lines where you can just sort of put something out there and this is really helpful particularly when developers are trying to provide a better solution for the customer. They know what the why is. They know where they want to go and the customer is focused on a on a certain solution and as a developer you realize that you have a potentially better solution. So you can use a clickable deno to put something in front of it and say well what if we did it this way and sometimes that was going to be able to turn the key and say yeah this is great let's actually do the you know solve the problem in a slightly different approach which ends up being you know win-win for everybody. Uh where do you want to go with this one? So when you were just talking through some of the bullet points of this one, the first thing that came to my mind because again I'm all test-driven development, you know, testing first is AB testing. So one of the best things with this that I love is the idea of the rapid idea validations and the effective shareholder communication. You could quickly throw up a couple different clickable demos and put it in front of different uh users and see how they like it. You could put it on a website and say, "Okay, uh, put it on a like a rotator." So, every time someone comes to the site, they could get one version or the other and then get feedback at the end of the their experience to say, "Okay, which did you prefer? What did you like about this? What did you not like about this?" So this is also a very quick way to get feedback uh on multiple ways of solving the problem because one way might suit one customer base better than another but the one that it solves it better for uh may be the larger customer set. So you want to make sure that your solution is solid enough to meet most of the needs of your user base not just that 1%. You want to make sure that it covers at least that 80%. >> And it is a it is a great way to get it in front of a people people quickly. A lot of you know a larger uh audience. And you can do that through like you can do a demo and you can record it. There's things like that. I love interactive clickable demos because the nice thing about clickable demos if you do them right is people can click on them all day and it doesn't actually break anything. It's very easy to like just you know reset or something like that. And that allows people to actually put it, you know, do it themselves and you can get some really good feedback. So practical tips for building demos. This is a howto 7 to 8 minutes discussion item. Essential tools for creating demos. No code lowode tools. Mention tools like Figma, Sketch, or Adobe XD and how they make it easy to link screens. Code-based approach. When to use simple HTML, CSS or framework like React with state management to create a more dynamic demo. Uh discussion on the process of a demo-driven development cycle. Uh, step one, wireframe the flow. Step two, blank screen select. Step three, test and iterate. Step four, refine the demo based on feedback. Discussion item, common pitfalls to avoid overengineering. Don't spend too much time on visuals early on. Getting stuck on a single tool. The tool is less important than the process. Um, I think I want to talk a little bit about the the overengineering because this is particularly a dangerous thing when you start if you go low code and no code. Those typically are are because of what they are, you just don't have that level of customization. So, it's it those are very good tools for going in and like just getting it done for lack of a better term. It's like put something together. I love Figma. It can look very good. You can I I don't use it very well. I can but I can take a Figma uh diagram or series of diagrams and the controls and I can actually build something fairly quickly based on that. And I know people that are very good at building out uh actually I guess Adobe XD I've seen a lot of that kind of stuff where people are just very good at putting together something that has a look that you're like oh cool this is what we want it to look like. Uh when you get into codebased approach of HTML and CSS um this is where do it with caution. I do like having those HTML wireframes. I like having the CSS in place. I have like being able to as we're going through it thinking about things like you know these certain styles and these certain classes and how this is going to work and how are we going to make these things look for look you know how the use look and feel is going to look so it's not just a picture somebody did but this is like in real application real code um and especially if you get into react and stuff like that where you can this that's why some of these tools and some of these technologies are so great because it's real easy to just like start tackling stuff on especially like if you have a front end build all the front end and then it's just sitting there waiting for the back end and then you can slowly like connect it into the back end. Uh but watch out because you don't want to get stuck with the yeah you don't want to be in that situation where you like just lost two hours trying to align like two buttons on a a form or something like that. And this is actually very important when you do the demo as well that you find ways to to lead discussion away from that stuff. So, if you're sitting there, you put something in front of this customer, you're like, "Here's a clickable demo." And you've got a a label that's off or, you know, some buttons that don't look quite right. It's do everything you can to just like you can, you know, if it's if it's horrible, you just say, "Yes, we know these two buttons are here. Pretend that they're lined up or something like that, and then let's move on." And do what you can to get them to move on. Because sometimes people are going to get stuck on that. They're be like, "Wait, what about that? I don't like that blue." and like we will change the color blue. Let's move on please. You or whatever it is. Find ways to not get caught up in the details too much. And part of this goes back to the why. What is it you really want to demo with your clickable demo? Are you just trying to show stuff off and say, "Look, we can do all this cool stuff." Well, that ends up being not terribly useful. You're still selling at that point. You're not really giving them the solution. You're just talking in, you know, smoking mirrors and stuff like that. What you need to do is have a why and have a focus for that clickable demo to say okay this is what we want to show this is the path this is how it should work this is the kind of discussions we want and then very that makes it very easy when a customer decides to veer from that path you can either say you know what that's a great idea we're going to hold off and we want to talk about that at a different time or you can go down the rabbit hole and say you know what that is something we're going to spend a little bit of time on but then just make sure that you have a way back from the rabbit trails you go down uh thoughts on these Yeah. So, it h there's so many different ways, but you touched on quite a few of them. The biggest thing with this, as you mentioned, you know, find the tool that you like and that works for you, but be careful of the tools that you don't, like Rob said, get bogged down trying to align things. Um, especially if you're OCD like me, you can very quickly get, okay, that's not lined up. Well, and you you go down those rabbit holes that you don't need to waste time on. The other problem I have seen now that Figma's gotten really good and added a lot more tools is you can kind of overengineer the basic demo, adding too many bells and whistles um to your application for the demo. Try to keep it to the core essentials of what the why is. Don't go adding all these cool things that you think are cool that would look good in an application. Keep it as barebone as possible, but do make sure that you add all the correct features to solve the problem, to explain the why. Um, and like Rob said, make sure you quickly handle the elephant in the room because you don't want to get into the conversation of that button should be purple, not blue. Uh, it almost always happens in in the init in some initial clickable demos. you almost always have that one person that doesn't like something and you could easily get sidetracked. So, address it quickly and move on and just keep to the demo. Uh, the other thing too is before you go into your demos, make sure that everything that clicks works. One of the other things I've seen with some clickable demos is people put them together, but they don't go back through and make sure that all the clicks that they entailed uh within their demo for it to work weren't wired up properly. So, they get in front of the demo and things aren't working. So, please test your clickable demos before you do the actual demo. >> Oh, very much. Definitely make sure whenever you get on any kind of demo that you are walking through. I will answer for the from that Spigma side of it is that yes, you can you can do some things very easily in like a Figma or or Adobe or some of these tools and make it look really sharp, but then it ends up being a very complicated thing to get, you know, to actually code or to implement on the on the back end. And so be very cautious with that. uh make sure that you you're not setting up the implementation team to fail because suddenly now they've got something that is really a throwaway feature that they're spending huge amounts of time on and they end up wasting their time on bells and whistles effectively as opposed to the the requirements. One of the requirements I have that is not a bell and whistle is for you to shoot us an email. Okay, a requirement is a strong word. I am I apologize. I would have backed that one up. a uh fevered recommendation or something like that is please send us an email at info developer.com. We would love to hear from you. We'd love to get your feedback and where you'd like to see us go and what do we do good and what do we do wrong and how can we improve because we're building a better podcast while we're teaching you guys and ourselves how to become better developers. You can reach out to us on Facebook. We have a developer page uh at xdevelopure. You can check all follow us there and all of our various posts and things like that. uh out on YouTube. We have a developer channel. You may actually be watching it right now. Wherever you listen to podcasts, we have uh building better developers developing the podcasts and that's all we have right now. There's not a lot of merchandising or anything like that. We haven't gotten into that world, but you never know when it could happen next. So, keep an eye out uh on all those different areas. Obviously, the developer.com site, you can leave us a there's contact form there. leave us feedback on any article or anything that you're reading and we would love to uh we'll respond and uh help you out especially if you have any questions. Some of this stuff has been around for a few years. It may have changed a little bit. So, you know, we have to update a little bit, but we're more than happy to uh help you point you in the right direction so that you're not blocked because we just haven't updated some of the older material that's out there. That being said, once again, I just want to say how much I appreciate your time for you giving sharing some of it with us and go out there and have yourself a great day, a great week, and we will talk to you next time. Bonus material. So, let's start with conclusion and call to action. Three to four minutes. Recap the key benefits. Clickable demos reduce ambiguity, save time, and foster collaboration by making ideas tangible. Uh, personal challenge challenge listeners to try building a click a quick clickable demo for the next feature idea and see the difference in feedback. Call to action what's a feature you wish you'd built a demo for. Let us know on Twitter with developer uh actually on X with developer. Reminders where to find the podcast and how to subscribe and then outro music and a fade out. Um, I want to say that there have been many times and uh in many over the many years that I have had something where we're working on an application and I have built a clickable demo that is basically a page and I have done it in a lot of different ways and a lot of different tools to get there, but it's basically just to say like here's the page we're talking about and here's what it looks like and here's how it works. It's not even a whole application. It's really literally a demo of a page of a feature of something like that. Sometimes I take a screenshot of the existing application and I just am like pasting some stuff on it and then find a way to like display that image. Um, one of the I did that before where I took an image. I was doing a map kind of thing and I took a screenshot and then you could click on the image and I had another screenshot and it was very like low tech. It was very quick to do it but it did allow me to do with a little bit of markup. exactly uh explain to the user what was going on so we could have a good conversation about it. So don't be afraid to um to whip up a quick little demo clickable demo for something that you're working through this week, next week, you know, things along that line. Bonus uh bonus material from you. >> Yeah. So with this one, you know, given that we're talking about clickable demos, I like the kitchen sync app idea. This is a great opportunity to take a clickable demo, maybe pick uh like something you want to learn, like maybe build a mobile app and do a clickable demo for like an iPhone app or do something in React for like a little iPhone app and do a clickable demo, but keep it and put it into your kitchen sync app because then you have at least the setup of how to start a mobile application or an iPhone app or a web page. But however you build this, put it into your source control. Again, I like to say kitchen sync app where you have a go-to place the next time you want to do something like this. You have a template. You have a starting point and you don't have to start from scratch. >> And that's that's often what I'm going to end up doing is I'm going to say this. It's you you're going to take something you've done. You've you've got a repository. You've built maybe some of that framework before. Maybe it's you've got uh menus and navigation. Maybe you've got a screen that does exactly that or a customer profile or all these different pages and things you've done. And sometimes that's the best way is to just like quickly grab that code, add it into your new repository, link to that page, and then you could say, well, it's sort of like this or just take a screenshot sometimes and just display the image as part of the page that you've you've opened. There are definitely some low tech ways to get some of this done very quickly. As always, back to thanking you for spending some time with us and wrapping this one up. It has been a day as we've been going through this stuff and cranking out these uh we got a few more episodes left. Love to hear recommendations and suggestions. Where would you like to see us go next for our next season? Uh we can go back and do obviously we could go do AI again. That's actually been pretty fun. Each of these episodes we have left content on the table that we could go back to and we could do other episodes or possibly even entire seasons on some of these things that we have talked about in the past. So, we'll see where we're going to go next. That being said, you go wherever you want to go next because we're you're free. Blast is dismissed. Go out there, have yourself a great one, stay safe, and we will see you next time around. [Music]
Transcript Segments
[Music]
Okay. So, I pasted that in. All right.
Boom. Click re book record.
And now we are into the next one which
is the power of clickable demos in the
software development life cycle. This is
my
favorite ever. I love the whole concept
of clickable demos and how you can turn
those into just like the most powerful
contraption for getting thoughts across
and stuff. It's rapid application
development essentially. But I loved it
since the RAD was first invented back in
like the 80s or whenever it was when it
was well okay the word was then but then
they added it you a little later when it
became software development but I am a
big fan of like let's get features in
front of people let's get feedback so
this one is going to be fun once again
we've thrown this out to uh Google's
Gemini instead of chat GBT so we're
gonna get a little bit different uh
thing but this is uh it's interesting
like what it does is it like gives me a
nice little uh it gives me an actual
document that I can take and I can do
something with it u which is a little
better than what chat GPT does but
that's yeah that's one of the things
that um you get out of these tools is
like some are a little better than
others and you can you can uh talk to
the AI and get it to send stuff out in a
certain format and stuff like that if
you want a good example um I took
go out to the rb-ns.com
site rb-sns.com
Uh, and you'll see if you go to the
about us, you can see about the team and
you can see where there's each of the
pages was is basically the same format.
And that's essentially what I did is I
said, "Okay, here's my content. Pick
this format. Bam, apply it." So that I
don't have to type out all that stupid
stuff or I don't have to worry about
copy and paste and things like that. And
it made it a lot easier and a lot more
error-free. Simple things like that are
great ways for you to get your job done
a little bit faster, particularly the
repetitive pieces of it. And then
sometimes we'll give you a little bit of
bonus too, but you got to watch out
because sometimes it also will get lost
and the next thing you know it's like,
you know, you you create four things
that are supposed to look the same and
the second one it didn't create white,
but now it's just like, you know, it's
like the old telephone game where it's
like it was wrong and now it keeps doing
it wrong everything from there. So check
it out just like you do everything else.
All right, that's good enough for now.
Enough vamping. We're going to do a
little th uno.
Ah, we are back for yet another episode
of building better developers the
developer podcast. I am Rob Broadhead.
Roberto Broadhead may maybe uh and I am
again one of the founders here and also
the founder of RB Consulting and not a
founder of foreign language speaking
because still working on that stuff. RB
consulting we essentially we are have
fractional CIO. We'll sit down with your
business, with your owners, and we're
going to talk to you about your
business. How do you run it? What are
the processes? What are your customers?
What's the journey like? How do you
fulfill all of that stuff? Your service,
your product, all of those things that
make your business run. And we're going
to even probably extract some of that
out of your head to make sure that we
have a clear picture of the processes
and the steps. And then we're going to
basically, it's a process improvement
project at that point. And basically,
we're going to walk through and look at
ways to improve that. Whether it's
removing steps, whether it's uh
integrating systems, whether it's
simplification of the steps, whether
it's automation so we can get past
errors and things like that and do it
faster. Or maybe it's innovation. Maybe
we're going to take some stuff and we're
going to switch it all up and we're
going to turn out a new solution that
combines multiple steps maybe into one
thing that now is much more efficient.
However that happens, we're going to
help you build a road map essentially to
say first, this is where you're at. This
is where you want to go moving forward.
We're going to help you, you know, get
those low hanging fruit, solve some
problems early on, but then also
position your business so that you're in
better shape for six months or six years
from now when you are growing at
whatever rate it is. Just like in a lot
of cases, businesses hit that point
where they're like, "Hey, we just got a
huge new customer. Oh crap, we just got
a huge new customer. We got to go hire
10 new people." Well, sometimes if you
talk to us, we can help you find better
ways than just having to go find hire
more people. Instead, you can make the
people you have more efficient. So now
you have to hire maybe five instead of
10. And it's something that's actually
reasonable and feasible instead of you
just running into a corner and curling
up in a ball and crying. Good thing, bad
thing. Good thing is I'm not having to
curl up in a ball and cry at any point.
We are not getting swamped with
customers that are, you know, taking up
too much time or anything like that. Uh
also good thing of that is it is it has
allowed me recently to do some working
in my business uh on my business instead
of in my business. And so after a period
of being very very busy for quite a
while and doing too much in the
business, I'm finally able to catch up a
little bit on the on the business stuff
which I've mentioned a little bit in
recent episodes where we were updating
the RB consulting website and actually
I've even been looking at uh some stuff
on the develop developer side. Uh have
done a couple of changes and things like
that which is what everybody should do.
just periodically do a business checkup,
take a look at what you got, check out
your material, do some updates, uh see
what you can do to, you know, better
really, I guess, enforce your brand and
things like that. Uh bad thing is is
that it's I'm having too much fun
working on my business and it's like
dragging me away from in my business at
times. It's one of those it's like, you
know, you get in get in this right
certain mindset and you're just like in
that creative mode or whatever. You're
like, I want to stick around with this.
I want to go. And the next thing you
know, you haven't just built like a, you
know, blurb for one page. You've now
like got an entire marketing campaign
that you've created because you're just
like you're you're in the zone.
I have been in the zone. So, I'm going
to take a deep breath and pass that over
to Michael so I can recover just a
little bit. Please introduce yourself.
>> Hey everyone, my name is Michael Mlash.
I'm one of the co-founders of developer
building better developers. I'm also the
founder and owner of Vision QA, where we
help businesses run better by making
sure their software works the way it
should. We start by getting to know your
business, reviewing your products,
understanding your goals, and assessing
what's working and what's not. From
there, we recommend the right solutions,
whether it's building a custom tool,
fixing what's broken, automating your
testing, or helping you prepare for a
smoother launch. Our goal simply is to
take care of the tech behind the scenes
so you can focus on running and growing
your business with competence. You can
learn more at envisionqa.com.
Good thing and bad thing. Uh good thing,
my birthday's coming up. I've got a game
coming out a few weeks after, so I'm
looking forward to that. So, I'm getting
a little stoked. Uh bad thing, which is
kind of leading to the good thing, is I
am way too far in my business right now.
I have too much work to do from too many
things. So, um I'm burning a lot of
hours. So, I'm hoping that all that will
wrap up. I'll get a little bit of
working on my business time and then
game time for a little bit.
I can't even spell game anymore. It
takes up too much of my time. So, this
episode we are uh I actually failed to
mention this right at the beginning, but
you guys have been hopefully following
us. But we are going back a couple a
couple seasons, taking episodes, the
topics, and we're dumping them into AI
and seeing what it spits out. Uh we're
doing it in Google Gemini this time. We
did chat PPT before, but the last couple
episodes now we're going to check out
Gemini. Uh the topic, the title
originally was the power of clickable
demos in the software development life
cycle. Uh and so it says, you know,
hosts your name, the co-host name,
opening one to two minutes, intro music
upbeat and energetic. Holy nailed that.
Start with the scenario. You're in
a meeting showing off a new feature.
You've got the mockups and the
flowcharts, but the client client just
can't seem to get it. What if you could
give them something they could actually
click? Uh, introduce the topic briefly.
Explain that this episode is about
leveraging interactive clickable demos,
not just static pictures to get better
feedback, align teams, and build the
right product the first time. I'm going
to come back to that actually. But part
one, what is a clickable demo? A
discussion item. Define an applicable
demo. What it is? What it is? a series
of static screens linked together with
clickable hotspots to simulate a user's
journey. What it's not a fully
functional prototype for the or the
final application. It's a loweffort way
to test high impact ideas. Discussion
item with spectrum of fidelity. Low
fidelity simple wireframes, gray boxes,
and basic text. The goal is to test flow
and logic. High fidelity polish UI
designs that look and feel like the
final product used to test aesthetics
and micro interactions. The sweet spot.
by starting with low fidelity and only
moving to high fidelity when necessary
is a smart strategy. Now, I want to
combine a little bit of that. Um, it's
not just static pictures. There is some
level of interactivity and it's not just
because sometimes I've seen a a
clickable demo and it technically I
guess could be is it's just like a
PowerPoint. It's like a slide and then a
slide and a slide and a slide.
that's okay and that does sometimes
uh serve the purpose. But I think with a
clickable demo, there's some things that
I found that are very valuable
for you moving forward that you can do
that are make it a little more demo
maybe and a little more real. Uh but
then it also, you know, you don't want
it to be too real because you don't want
to be spending too much time. And this
also gets into the fidelity side of it.
A nice thing about a clickable demo that
I found with a with an application is to
actually throw up some screens is just
get some basic screens up. They don't
have to have a lot on them. And
sometimes just take one screen and you
can copy and paste it a couple times.
Now you got four screens and you can
click on menu items and you can open the
various screens. It's yes, it takes you
a little bit of time, but you should be
able to spin up something like that
within hours and have something that
allows you to actually have the uh the
rudimentary pieces of your application.
Sometimes you can, you know, if you've
got a week or two to do it, like maybe
you've got sometimes you've got a first
sprint that you're working on of two or
three or more weeks, then you can do
stuff like you can actually go through
and think about like your CSS. You can
think about your general headers and
footers and look and feel and some of
those kinds of things, which gets you
into more of a high fidelity. Uh, but
then also that's at the expense of maybe
some of the functionality that you would
want to show. And this is where the
balance is. I think you need to you have
to show something that isn't so
god-awful ugly that they're like running
away, their eyes are bleeding and
they're like, "No, I never want to see
that again." Or that they see it and
they say, "Well, geez, you guys are
completely incompetent because my kid
could do a better app." Because there is
some level of expectation. So, don't
make it just completely hideous. But
that depends if you can have some
functionality that is a proof of concept
or solving a problem that it's that they
don't normally see then you can you know
you can make it less low lower fidelity
less pretty but focus on like look we
are solving your problem. I have seen
that in a couple of cases where I had
something that was not a very good
interface. One that I remember way back
where it was basically it was it was a
interactive way to lay out uh wallpaper
and floor coverings in a building and it
was in three dimensions and people are
like I don't know if that's going to be
any good. But then we had something that
had a very horrible interface around it.
It was basically the picture of the
building and you could rotate it and you
could click on something and you could
select a product and it was a you know a
lot of those pieces were were pretty
ugly and they were very hardcoded but it
gave us a start and then we could go
back and we did have to rewrite pieces
like uh the selector stuff. Yeah, you
had to go back you had to rewrite it so
it actually pulled data from a database
and some things like that but it gave us
a starting point and it gave us
something to fall back on at any point
as well. So if something technically
wasn't working, we could go back and
look at like, oh, okay, at least we had
this thing that was working. Now let's
compare the two. So there is a lot of
value in this that is part of the
implementation to me. It's part of the
implementation and not just the
presenting it to the user. But if you
can put a proof of concept in there, if
you can have something that they're
like, I don't know if this problem can
be solved. you can make that a part of
your clickable demo, then you're really
moving the ball forward because you're
saying, "Look, this problem we we have
shown that it can be done and now you
can have the discussion of how to do it
better or prettier." So,
speaking of better and prettier, let's
see what you can do with that. Where do
you want to go with this one? Well, it's
funny because I I know you kind of poked
a little shade at the whole PowerPoint
thing, which, you know, I like to do at
the initial start to kind of just figure
out what I want to do even for a
clickable demo. Uh cuz I like the
wireframe approach first because it it
kind of helps at least me put together,
okay, what's kind of the uh interface
going to look like? What are because you
kind of have to have a little bit of a
basic understanding of what the
interface is that you're going to be
working with. Is it a mobile app? Is it
a web app? it, you know, what type of
application are you building? And then
you structure around that. Okay, if I'm
building a wireframe, do I need a menu?
Do I need a slider? There's just certain
features you need to think about when
you're just kind of doing some UI work.
But beyond that though, I love the
clickable demo idea because you can,
like you said, get something in front of
them, but you there is a caveat to that
because if you put too much into the
clickable demo, you could potentially be
driving the direction of the application
or the product in a way that may or may
not meet the requirements of the
customer. So, you could build this nice
cookable demo. They're like, great,
that's awesome. Let's go with it. And
then you find out 6 months later that oh
we missed a whole bunch of things
because what you showed us was kind of
gave us a false direction of where we
wanted to go. It's like you get halfway
and it's like oh but we need to really
do something else over here or add this.
So you could miss some things. So, just
be a little careful with what you do
with these clickable demos because they
are very powerful. And in some
situations, you end up going to
production with some clickable demos
because it's like, oh, this is good
enough. Publish it, get it out there,
and then then next thing you know, you
have this very clunky
um, you know, thrown together code
that's now live that you now have to
support. So, there's a lot of good
things to this. Um, more positive than
negative. Just I want to throw out some
of those caveats to just watch out for
if you do start going down this
approach. It could be too successful and
you could be live, which is not
necessarily a bad thing because that
means you won the customer. But the bad
thing is you may have to spend a little
bit more time cleaning up some behind
the scenes stuff very quickly that you
didn't plan for initially.
>> And I think that's part of it is that
like clickable demos can be very
uh rough and and sort of just like
thrown together. I think that if you if
you do it right, you actually have your
own little framework or something like
that or you know your code repository
somewhere where you can pull some of
those pieces in and they're not
completely thrown together. So it's not
I mean you can do them as a one and done
but I think ideally you want your
clickable demo to actually be a demo
that you can build on top of. So be very
careful that you don't just like throw
crap in there and uh and there is going
to be some cleanup. There will probably
be some technical debt at some point of
like oh we've showed them this but now
we want to pull it back out. So those
are some definitely some things to to
keep an eye out for. Now as we go to
part two, the why benefits for every
role. Uh 8 to 10 minutes it says
discussion item the value proposition
for developers. Fewer surprises catching
design flaws and usability issues before
writing a single line of code. Better
communication resolving ambiguities by
physically demonstrating a flow rather
than just describing it. Confidence and
estimation. Understanding the user's
journey helps in breaking down stories
more accurately and identifying
potential complexities. Discussion item.
value proposition for product managers
and designers. Rapid idea validation
quickly testing multiple design concepts
and flows within a large time in without
a large time investment. Effective
stakeholder communication getting buyin
and feedback from nontechnical
stakeholders in a language they
understand. Clicking and interacting
uh discussion item value proposition for
clients and end users. Tangible
feedback. It's easier to say I don't
like how this works after trying it than
just seeing after just seeing a picture.
Early problem identification users can
spot logical flaws or confusing flows
that would have been missed in a static
review. Now
I think is where the where the clickable
demo becomes most valuable is when
you've got people that are watching you
or you know whether it's interactive so
they can do it or they're watching you
go through a clickable demo and you
click on something and you you enter
some data and then you hit a button and
then something happens. It is amazing
how many times, and this is why I love
clickable demo so much. It's amazing how
many times that I've been in front of a
customer and we've sat down and we've
talked through requirements and we said
this is how it goes and they agree and
everybody's awesome and we're all the
same page and we put a clickable demo in
front of them and they say well wait a
minute where did you do that and it's
like well you've never told us what that
is so let's go talk about that. What is
this that that you are missing? And
particularly this is valuable when
you've got a representative of a user
but not an actual user. There have been
many times that we have had a clickable
demo where we invite in you know
frontline workers or people that are
actually going to use this as opposed to
whoever the representative of them is
that maybe doesn't do it as often. And
you will get questions or they'll say
well wait a minute how do I get to from
from to point B from point A because I
never do it that way. I always have a A
B C D and E before I get to there. And
those are the things that are that's
part of the bonus of and the benefit of
uh to me of the clickable demos that it
is going to draw that kind of stuff out.
So from the and it works great for the
clients and users to have that
conversation around it. It's something
they can see they can almost like feel
and touch and say yes this is this makes
sense. Uh but then as developers it
gives you a way to it's sort of it's not
quite the 8020 rule but it's something
along those lines where you can just
sort of put something out there and this
is really helpful particularly when
developers are trying to
provide a better solution for the
customer. They know what the why is.
They know where they want to go and the
customer is focused on a on a certain
solution and as a developer you realize
that you have a potentially better
solution. So you can use a clickable
deno to put something in front of it and
say well what if we did it this way and
sometimes that was going to be able to
turn the key and say yeah this is great
let's actually do the you know solve the
problem in a slightly different approach
which ends up being you know win-win for
everybody. Uh where do you want to go
with this one? So when you were just
talking through some of the bullet
points of this one, the first thing that
came to my mind because again I'm all
test-driven development, you know,
testing first is AB testing. So one of
the best things with this that I love is
the idea of the rapid idea validations
and the effective shareholder
communication. You could quickly throw
up a couple different clickable demos
and put it in front of different uh
users and see how they like it. You
could put it on a website and say,
"Okay, uh, put it on a like a rotator."
So, every time someone comes to the
site, they could get one version or the
other and then get feedback at the end
of the their experience to say, "Okay,
which did you prefer? What did you like
about this? What did you not like about
this?" So this is also a very quick way
to get feedback uh on multiple ways of
solving the problem because one way
might suit one customer base better than
another but the one that it solves it
better for uh may be the larger customer
set. So you want to make sure that your
solution is solid enough to meet most of
the needs of your user base not just
that 1%. You want to make sure that it
covers at least that 80%.
>> And it is a it is a great way to get it
in front of a people people quickly. A
lot of you know a larger uh audience.
And you can do that through like you can
do a demo and you can record it. There's
things like that. I love interactive
clickable demos because the nice thing
about clickable demos if you do them
right is people can click on them all
day and it doesn't actually break
anything. It's very easy to like just
you know reset or something like that.
And that allows people to actually put
it, you know, do it themselves and you
can get some really good feedback. So
practical tips for building demos. This
is a howto 7 to 8 minutes discussion
item. Essential tools for creating
demos. No code lowode tools. Mention
tools like Figma, Sketch, or Adobe XD
and how they make it easy to link
screens. Code-based approach. When to
use simple HTML, CSS or framework like
React with state management to create a
more dynamic demo. Uh discussion on the
process of a demo-driven development
cycle. Uh, step one, wireframe the flow.
Step two, blank screen select. Step
three, test and iterate. Step four,
refine the demo based on feedback.
Discussion item, common pitfalls to
avoid overengineering. Don't spend too
much time on visuals early on. Getting
stuck on a single tool. The tool is less
important than the process. Um, I think
I want to talk a little bit about the
the overengineering because this is
particularly a dangerous thing when you
start if you go low code and no code.
Those typically are are because of what
they are, you just don't have that level
of customization. So, it's it those are
very good tools for
going in and like just getting it done
for lack of a better term. It's like put
something together. I love Figma. It can
look very good. You can I I don't use it
very well. I can but I can take a Figma
uh diagram or series of diagrams and the
controls and I can actually build
something fairly quickly based on that.
And I know people that are very good at
building out uh actually I guess Adobe
XD I've seen a lot of that kind of stuff
where people are just very good at
putting together something that has a
look that you're like oh cool this is
what we want it to look like. Uh when
you get into codebased approach of HTML
and CSS
um this is where do it with caution. I
do like having those HTML wireframes. I
like having the CSS in place. I have
like being able to as we're going
through it thinking about things like
you know these certain styles and these
certain classes and how this is going to
work and how are we going to make these
things look for look you know how the
use look and feel is going to look so
it's not just a picture somebody did but
this is like in real application real
code um and especially if you get into
react and stuff like that where you can
this that's why some of these tools and
some of these technologies are so great
because it's real easy to just like
start tackling stuff on
especially like if you have a front end
build all the front end and then it's
just sitting there waiting for the back
end and then you can slowly like connect
it into the back end. Uh but watch out
because you don't want to get stuck with
the yeah you don't want to be in that
situation where you like just lost two
hours trying to align like two buttons
on a a form or something like that. And
this is actually very important when you
do the demo as well that you find ways
to to lead discussion away from that
stuff. So, if you're sitting there, you
put something in front of this customer,
you're like, "Here's a clickable demo."
And you've got a
a label that's off or, you know, some
buttons that don't look quite right.
It's do everything you can to just like
you can, you know, if it's if it's
horrible, you just say, "Yes, we know
these two buttons are here. Pretend that
they're lined up or something like that,
and then let's move on." And do what you
can to get them to move on. Because
sometimes people are going to get stuck
on that. They're be like, "Wait, what
about that? I don't like that blue." and
like we will change the color blue.
Let's move on please. You or whatever it
is. Find ways to not get caught up in
the details too much. And part of this
goes back to the why. What is it you
really want to demo with your clickable
demo? Are you just trying to show stuff
off and say, "Look, we can do all this
cool stuff." Well, that ends up being
not terribly useful. You're still
selling at that point. You're not really
giving them the solution. You're just
talking in, you know, smoking mirrors
and stuff like that. What you need to do
is have a why and have a focus for that
clickable demo to say okay this is what
we want to show this is the path this is
how it should work this is the kind of
discussions we want and then very that
makes it very easy when a customer
decides to veer from that path you can
either say you know what that's a great
idea we're going to hold off and we want
to talk about that at a different time
or you can go down the rabbit hole and
say you know what that is something
we're going to spend a little bit of
time on but then just make sure that you
have a way back from the rabbit trails
you go down uh thoughts on these
Yeah. So, it h there's so many different
ways, but you touched on quite a few of
them. The biggest thing with this, as
you mentioned, you know, find the tool
that you like and that works for you,
but be careful of the tools that you
don't, like Rob said, get bogged down
trying to align things. Um, especially
if you're OCD like me, you can very
quickly get, okay, that's not lined up.
Well, and you you go down those rabbit
holes that you don't need to waste time
on. The other problem I have seen now
that Figma's gotten really good and
added a lot more tools is you can kind
of overengineer the basic demo, adding
too many bells and whistles um to your
application for the demo. Try to keep it
to the core essentials of what the why
is. Don't go adding all these cool
things that you think are cool that
would look good in an application. Keep
it as barebone as possible, but do make
sure that you add all the correct
features to solve the problem, to
explain the why. Um, and like Rob said,
make sure you quickly handle the
elephant in the room because you don't
want to get into the conversation of
that button should be purple, not blue.
Uh,
it almost always happens in in the init
in some initial clickable demos. you
almost always have that one person that
doesn't like something and you could
easily get sidetracked. So, address it
quickly and move on and just keep to the
demo. Uh, the other thing too is before
you go into your demos, make sure that
everything that clicks works. One of the
other things I've seen with some
clickable demos is people put them
together, but they don't go back through
and make sure that all the clicks that
they entailed uh within their demo for
it to work weren't wired up properly.
So, they get in front of the demo and
things aren't working. So, please test
your clickable demos before you do the
actual demo.
>> Oh, very much. Definitely make sure
whenever you get on any kind of demo
that you are walking through. I will
answer for the from that Spigma side of
it is that yes, you can
you can do some things very easily in
like a Figma or or Adobe or some of
these tools and make it look really
sharp, but then it ends up being a very
complicated thing to get, you know, to
actually code or to implement on the on
the back end. And so be very cautious
with that. uh make sure that you you're
not setting up the implementation team
to fail because suddenly now they've got
something that is really a throwaway
feature that they're spending huge
amounts of time on and they end up
wasting their time on bells and whistles
effectively as opposed to the the
requirements.
One of the requirements I have that is
not a bell and whistle is for you to
shoot us an email. Okay, a requirement
is a strong word. I am I apologize. I
would have backed that one up. a uh
fevered recommendation
or something like that is please send us
an email at info developer.com. We would
love to hear from you. We'd love to get
your feedback and where you'd like to
see us go and what do we do good and
what do we do wrong and how can we
improve because we're building a better
podcast while we're teaching you guys
and ourselves how to become better
developers. You can reach out to us on
Facebook. We have a developer page uh at
xdevelopure. You can check all follow us
there and all of our various posts and
things like that. uh out on YouTube. We
have a developer channel. You may
actually be watching it right now.
Wherever you listen to podcasts, we have
uh building better developers developing
the podcasts and that's all we have
right now. There's not a lot of
merchandising or anything like that. We
haven't gotten into that world, but you
never know when it could happen next.
So, keep an eye out uh on all those
different areas. Obviously, the
developer.com site, you can leave us a
there's contact form there. leave us
feedback on any article or anything that
you're reading and we would love to uh
we'll respond and uh help you out
especially if you have any questions.
Some of this stuff has been around for a
few years. It may have changed a little
bit. So, you know, we have to update a
little bit, but we're more than happy to
uh help you point you in the right
direction so that you're not blocked
because we just haven't updated some of
the older material that's out there.
That being said, once again, I just want
to say how much I appreciate your time
for you giving sharing some of it with
us and go out there and have yourself a
great day, a great week, and we will
talk to you next time. Bonus material.
So, let's start with conclusion and call
to action. Three to four minutes. Recap
the key benefits. Clickable demos reduce
ambiguity, save time, and foster
collaboration by making ideas tangible.
Uh, personal challenge challenge
listeners to try building a click a
quick clickable demo for the next
feature idea and see the difference in
feedback. Call to action what's a
feature you wish you'd built a demo for.
Let us know on Twitter with developer
uh actually on X with developer.
Reminders where to find the podcast and
how to subscribe and then outro music
and a fade out. Um, I want to say that
there have been many times and uh in
many over the many years that I have had
something where we're working on an
application and I have built a clickable
demo that is basically a page and I have
done it in a lot of different ways and a
lot of different tools to get there, but
it's basically just to say like here's
the page we're talking about and here's
what it looks like and here's how it
works. It's not even a whole
application. It's really literally a
demo of a page of a feature of something
like that. Sometimes I take a screenshot
of the existing application and I just
am like pasting some stuff on it and
then find a way to like display that
image. Um, one of the I did that before
where I took an image. I was doing a map
kind of thing and I took a screenshot
and then you could click on the image
and I had another screenshot and it was
very like low tech. It was very quick to
do it but it did allow me to do with a
little bit of markup. exactly uh explain
to the user what was going on so we
could have a good conversation about it.
So don't be afraid to um to whip up a
quick little demo clickable demo for
something that you're working through
this week, next week, you know, things
along that line. Bonus uh bonus material
from you.
>> Yeah. So with this one, you know, given
that we're talking about clickable
demos,
I like the kitchen sync app idea. This
is a great opportunity to take a
clickable demo, maybe pick uh like
something you want to learn, like maybe
build a mobile app and do a clickable
demo for like an iPhone app or do
something in React for like a little
iPhone app and do a clickable demo, but
keep it and put it into your kitchen
sync app because then you have at least
the setup of how to start a mobile
application or an iPhone app or a web
page. But however you build this, put it
into your source control. Again, I like
to say kitchen sync app where you have a
go-to place the next time you want to do
something like this. You have a
template. You have a starting point and
you don't have to start from scratch.
>> And that's that's often what I'm going
to end up doing is I'm going to say
this. It's you you're going to take
something you've done. You've you've got
a repository. You've built maybe some of
that framework before. Maybe it's you've
got uh menus and navigation. Maybe
you've got a screen that does exactly
that or a customer profile or all these
different pages and things you've done.
And sometimes that's the best way is to
just like quickly grab that code, add it
into your new repository, link to that
page, and then you could say, well, it's
sort of like this or just take a
screenshot sometimes and just display
the image as part of the page that
you've you've opened. There are
definitely some low tech ways to get
some of this done very quickly.
As always, back to thanking you for
spending some time with us and wrapping
this one up. It has been a day as we've
been going through this stuff and
cranking out these uh we got a few more
episodes left. Love to hear
recommendations and suggestions. Where
would you like to see us go next for our
next season? Uh we can go back and do
obviously we could go do AI again.
That's actually been pretty fun. Each of
these episodes we have left content on
the table that we could go back to and
we could do other episodes or possibly
even entire seasons on some of these
things that we have talked about in the
past. So, we'll see where we're going to
go next. That being said, you go
wherever you want to go next because
we're you're free. Blast is dismissed.
Go out there, have yourself a great one,
stay safe, and we will see you next time
around.
[Music]