Demo-Driven Development: Build Better Software with Faster Feedback

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. We are back for yet another episode of Building Better Developers, the Developer podcast. I am Rob Broadhead. Rob Banto. Broadhead, maybe. And I am again, one of the founders here and also the founder of RV Consulting and not a founder of foreign language speaking because still working on that stuff. RV Consulting, we essentially we are a 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 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 roadmap, 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 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 growing up in a ball and crying. Good thing, bad thing. The 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 taking up too much time or anything like that. Also, a good thing in that is it has allowed me recently to do some working in my business, 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 mentioned a little bit in recent episodes where we're updating the RV consulting website. Actually, I've even been looking at some stuff on the developer, the developer, Norside, 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, see what you can do to better really, I guess, enforce your brand and things like that. A 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, you 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 board for one page. You've now got an entire marketing campaign that you've created because you're just like 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 McClash. I'm one of the co-founders of DeveloperNerd, 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. Good thing, my birthday is 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. 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 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 the 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 actually failed to mention this right at the beginning, but you guys have been hopefully following us. But we are going back a couple of a couple of seasons, taking episodes, the topics, and we're dumping them into AI and seeing what it spits out. We're doing it in Google Gemini this time. We did chat PPT before, but the last couple of episodes now we're going to check out Gemini. The topic, the title originally was the power of clickable demos in the software development lifecycle. So it says, you know, hosts, your name, the co-host name, opening one in two minutes, intro music, upbeat and energetic. Totally nailed that. Start with the scenario. You're in a meeting showing off a new feature. You've got the mockups and the flow charts, but the client just can't seem to get it. What if you could give them something they could actually click? Introduce the topic, briefly explain 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 defining a clickable demo. 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 low effort way to test high impact ideas, discussion item, the spectrum of fidelity, low fidelity, simple wireframes, gray boxes and basic text. The goal is to test flow and logic, high fidelity, polished UI designs that look and feel like the final product used to test aesthetics and micro interactions. The sweet spot why 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. It's not just static pictures. There is some level of interactivity and it's not just because sometimes I've seen it a clickable demo and technically I guess could be is it's just like a PowerPoint. It's like a slide and then slide and slide and slide. That's okay. And that does sometimes 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 or make it a little more demo maybe and a little more real. But then it also 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. The nice thing about a clickable demo that I found with an application is to actually throw up some screens. It's just get some basic screens up. They don't have to have a lot on them. And sometimes just take one screen and copy and paste it a couple of times. Now you've 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 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, 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. 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 pretty, low foot, 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. I remember way back where it was basically it was, it was a interactive way to lay out wallpaper and floor coverings in a building. And it was in three dimensions and people are like, I don't know if that's gonna 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 hard coded, but they gave us a start. And then we could go back and we did have to rewrite pieces like 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. If 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 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. Because I like the wireframe approach first, because it kind of helps at least me put together. Okay, what's kind of the interface going to look like? What are 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. Cause 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 clickable demo. They're like, great. That's awesome. Let's go with it. And then you find out six 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 in. It's like, Oh, but we need to really do something else over here or at 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 the next thing you know, you have this very clunky, you know, throwing together code that's now live that you now have to support. So there's a lot of good things to this more positive than negative. Just, I wanted 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 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, where you can pull some of those pieces in and they're not completely thrown again. 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 showed them this, but now we want to pull it back out. So those are some, definitely some things that they keep an eye out for. Now, as we go to part two, the why benefits for every role, uh, eight to 10 minutes, it says discussion item, the value proposition for developers. If you were surprised, this 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, the value proposition for product managers and designers, rapid idea about validation, quickly testing multiple design concepts and flows within a large time and without a large time investment, effective stakeholder communication, getting buy-in and feedback from non-technical stakeholders in a language they understand clicking and interacting, uh, discussion item. By proposition for clients and end users, tangible feedback. It's easier to say, I don't like how this works after trying it. And 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. I think is where the, where the clickable demo becomes most valuable is when you've got people that are watching you or whether it's interactive so they can do it, or they're watching you go through a clickable demo, when you look on something and you've, you enter some data and then you in a button and then something happens. It is amazing how many times, and this is why I love clickable demos 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 to requirements and we said, this is how it goes. And they agree and everybody's awesome. And we're all on the same page and we put a clickable demo in front of them. And they said, 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 it 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 who 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 where they'll say, well, wait a minute, how do I get to from the 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 the benefit of, to me, of the clickable demos. And 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 as something they can see, they can almost like feel and touch and say, yes, this is, this makes sense. But then as developers, it gives you a way to, it's sort of, it's not quite the 80-20 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 demo 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. 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 A-B 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 users and see how they like it. You could put it on a website and say, okay, 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 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, maybe 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 the people, people quickly, a lot of, you know, a larger 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 typical 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 reset or something like that. And that allows people to actually put it at, you know, do it themselves and you can get some really good feedback. So practical tips for building demos. This is a how to seven, eight minutes discussion item, essential tools for creating demos. No code slash low code 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. Discussion on the process of a demo driven development cycle. Step one, wireframe the flow. Step two, link screens like step three, test and iterate. Step four, refine the demo based on feedback. Discussion item, common fit falls to avoid. Over engineering. Don't spend too much time on visuals early on getting stuck on a single tool. The tool is less important than the process. I think I want to talk a little bit about the over engineering 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 just going in and like just getting it done for lack of a better term. So I put something together, 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 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 actually, and 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 as a look that you're like, oh, cool. This is what we want it to look like. When you get into code based approach from HTML and CSS, 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, you know, how that use look and feel is really going to look. So it's not just a picture somebody did, but this is like in real application, real code. And especially if you get into React and stuff like that, where you can, that's why some of these tools and some of these technologies are great because it's really easy to just like start tacking 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 backend and then you can slowly like connect it into the backend. 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 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 and put something in front of this customer, you're like, here's the 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 a, do everything you can to just say, 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 what you can to get them to move on, because sometimes people can get stuck on that and be like, well, 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, or 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 and smoking mirrors and stuff like that. What you need to do is have a why and have a focus for that quick, cool 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 to 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 thoughts on these. Yeah. So, uh, there's so many different ways, but you touched on quite a few of them. I, 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, or upside 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 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 figmas gotten really good and added a lot more tools is you can kind of over engineer 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 Y is. Don't go adding all these cool things that you think are cool that would look good in an application. Keep it as bare bone as possible, but do make sure that you add all the correct features to solve the problem, to explain the Y, 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, 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 demos, you are walking through. I will add 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 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 backend. And so be very cautious with that. Uh, make sure that 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 end up wasting their time on. Bells and whistles effectively, as opposed to the requirements. One of the requirements I have that is not a bell and whistle is for you to shoot us an email. Okay. So a requirement is a strong word. I am, I apologize. I would have backed that one up a, uh, fevered recommended something like that. Please send us an email at info development or.com. We would love to hear from you. We'd love to get your feedback and where you'd like to see us go. 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 at X at developer, nor you can check all our policy and all of our various posts and things like that. Uh, on YouTube, we have a developer channel. You may actually be watching it right now. Wherever you listen to podcasts, we have a building better developers, developing or the podcasts. And that's all we have right now. There's not a lot of merchandising. 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 can happen next. So keep an eye out on all those different areas. Obviously the developing word.com site. You can leave us a, there's contact form there, leads 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'm just going to say how much I appreciate your time for you giving it, sharing some of it with us and go out there and have yourself a great day, a great week. We will talk to you next time. Thank you for listening to building better developers, the developer nor podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.