The Power of Clickable Demos in the Software Development Lifecycle

Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing the developer journey this season. We are Developer Noir. We are building better developers. You're here. You are becoming a better developer. Trust me, just go with it. You are becoming a better developer. And honestly, you are. We all are because the more we talk about it, the more we bounce our ideas off each other, the more we get exposure to different ways that people solve these problems or even ways people solve problems that we've solved, but do it in a different context. All of that is a way for us to grow as a developer. My name is Rob Brodhead. I am one of the founders of Developer Noir and also a founder of RB Consulting, where we do boutique consulting basically, and it's about simplification, automation and integration. It's how to take whatever it is that you've got, help you figure out what you've got through like an IT audit or something along those lines, and then help you figure out how to make it better through simplification, automation and integration. I will go ahead and start in the good thing, bad thing kind of stuff. Let's see, which I probably shouldn't put myself on the hot seat right now, but I'm going to. Let's see, good thing. Yeah, this is great. We were talking about this just a second ago before we hit record. Good thing is going along and picked up a new customer this week. The bad thing is sometimes you pick up a new customer that's like short term and it's a lot of hours that you weren't expecting you were supposed to work. You had all these, you had this nice plan of like, this is how my week's going to go. This is what I'm going to get done. These are all the things that are going to have that I'm going to be focused on. And you crumble that up and throw it over your shoulder because now you've got all this other stuff that came out of nowhere. So it's a, it is a blessing and a curse in itself. One person who is always a blessing and never a curse is on the other side of this. And this will be Michael, you can go ahead and introduce yourself. Hey everyone. My name is Michael Milos. I'm one of the co-founders of building better developers, otherwise known as developer founder of Envision QA, where we help you evaluate patient or elevate patient care with customized clinical software. If you're looking to streamline workflows, enhance diagnostics and improve patient outcomes, Envision QA can help. With Envision QA, you can trust that your software meets the highest standards, allowing you to focus on what truly matters your patients. So well-being, imaging, seamless operations, we help you with all of that. So if you need it, give us a call. Good and bad this week. Good. I'm finally getting caught up from the bad, which was a week of madness with my, my wife's, I had a slight injury that we're trying to figure out how to get some care for. Flip side of that, we are starting to make progress, but kind of fell a little behind on things, but getting caught back up and things are starting to at least come together in some shape or form. Right. So this episode, we're sort of still in the, we've talked about psychopaths, we've talked about requirements and all that kind of good stuff. If you wonder about that, go ahead and go back and catch up on those episodes. This episode, we're sort of continuing the talking through some of the major portions of the SDLC. And we're serving that just, it's really the requirements design kind of area. We're going to talk about mockups or clickable demos or sort of like prototyping or proof of concept. There's, there's a lot of different ways that you can essentially move from a design and requirement into a position where you are not just reading something, you know, providing something on a document or something like that, but you're actually showing your user, your customer what's going on. And this is sort of where we got into this was the idea of instead of telling somebody, it is a lot better sometimes to show them. When we talked about gathering requirements, that was one of the things. They can tell you what they do, but it's going to be so much more informative if they show you what they do. This is where you have things like mockups and clickable demos and things of that nature that are going to give you the same kind of value. Instead of writing out like a, you know, you can write flow charts and you can do user stories. There's all these things you can do that are all very useful tools for talking to your customer and getting, essentially getting the vision that you have. This is you maybe as a collective development team or the implementers, the vision that you have of what this is going to be and try to line that up with the vision of what the customer or the end user has of what this should be. There can be a very big disconnect. One of the best ways to start talking about those and bring them together is to put it in front of everybody and go there. That thing right there, I like it. I don't like it. It needs more buttons. It needs less buttons. It needs emojis, whatever it is that it needs. You can talk through that because now you have something that is concrete. It's not some sort of a theoretical thing or a sentence that somebody could read something into. It is a hard piece of development software, something along those lines. That's where the value of, for example, a clickable demo is. Let's talk about what do you want to actually do? What is your focus when you're building something like that? I mentioned that the goal, really the why, is to get everybody on the same page. You may ask, which would be a fair question, which is why we've got this episode and this is the topic, what is it that I need to include in my clickable demo? Just a page and some stuff you can click on doesn't really do it. What should I be looking for? What are some things that I should keep in mind while I'm building out this, whether it's a prototype, a demo, wireframes, things like that? The thing I've found that is the most critical piece of building out a good, particularly early on, a good clickable demo or wireframes is to look at the high risk items. What are the things that are most likely to cause confusion within, say, for example, the requirements and the user stories? By this, I mean there's going to be things like, things where there are going to be assumptions made, things like, hey, a user is going to be on a page. Okay, let's talk about that user a little bit. Let's have a demo that basically says, well, we have to register a user or we have to create a user and then the user logs in and then they navigate to this page. Or it'll be things like the user has a dashboard. See that kind of stuff all the time. The user goes to their home page. What the heck does that look like? You start putting stuff together to say, okay, here's what we envision the home page to look like. Look through your requirements and essentially, particularly if you've built requirements in some sort of an interim phase where you're going through and you're gathering and you've got some back and forth and you've got some questions that have been asked along the way where it wasn't maybe in the first pass, these things aren't obvious. And so you ask some questions and you get an answer. Those are probably going to be some of the areas where there's more likely some sort of disconnect or maybe there's some assumptions made or something like that. If as you're looking through your requirements, you see where there is room for interpretation. This happens all the time and is a great, these are sort of those key words that you're going to look for maybe are things like, you know, I want a professional design or I want something that is functional over pretty or I don't need a lot of bells and whistles. There's these generic types of phrases. And so that's what you want to attack as part of your demo is you want to make sure first and foremost that you're looking at the requirements that you know and that you've got some way to say this is how we're going to progress through the requirements. Now you may even do it on a user story by user story basis. So your clickable demo may actually be a series of clickable demos that is walking through user stories. Those are often, if nothing else, a great wireframe to work from is whatever the steps are, the journey for each user story. If you cover those in your demo, then what you get to do is you get to say here's the steps, which you have that because you have a user story. We all can read these are the steps. But now you get to see those and see what does that look like? What does the screen look like? What are the navigational places that you're going to have? What does it look like to gather that kind of information? And it's sometimes it's going to be things like the user enters profile information and they don't really say what is profile information. And if you ask them, they say, well, you know, typical profile information. Okay, we're going to put the first name, last name, email address, some stuff like that. And just say, okay, this is what it looks like. So high, what I call high risk items, the areas where there is a potential for miscommunication or assumptions are the places you really want to focus on in your clickable demo. And when you do it, that's really where, you know, as you're talking through, as you are demonstrating, as you're presenting the clickable demo, part of that script should call out those kinds of things while you're doing it. So it'd be things like here's the, here we have a user logging in. They are using their email address as their ID and they're using a password. And it may be stuff that is part of this demo that you say, are we going to, you know, are we going to have user, this gets a little bit in requirements and stuff like that. But it's like, is the user ID going to be an email address? Are they guaranteed to have an email address? Should they use a phone number instead? Should they use, do we need to think about multifactor authentication? I know we're back on picking on logins because there's a billion questions related to that. But that goes right into like, I don't know how many times I've gotten stuck on. And then I'm going to, because I'm almost getting stuck on this platform, but I'm going to jump off in a second and give it to Mike. The homepage, the landing page is what happens once you log in. What does that look like? And so a lot of times like that is where you're going to go. And a lot of times, like I said, I've gotten into clickable demos and we did not get past the homepage because we spent so much time talking through all of those pieces. We're like, okay, we're going to schedule a follow-up to actually talk about other features. So hit those kinds of things. The things where there is generic terms and stuff that you know, they've got some vision, but they just can't get something out of their head on paper. Give them now something by saying, here's like, almost like here's a blank slate. Here's a page. What would you like to see here? What I would like to see here is some interaction from Michael and see what are your thoughts on this and, or taking it a different direction. If there's something else you wanted to tackle on the, on this front. Sure. So you've done a really good job of explaining what a clickable demo is and walking through the requirements and trying to present something to the end user to give them an idea of what this is going to look like. This is either going to be a new application, a rebuild of an existing application, something brand new, anything could even be a new feature added to the existing system. What you didn't touch on, and I wanted to expand into this a little bit is for those of you that maybe this may be a new concept to you building mockups, wireframes, yes, clickable demos doesn't necessarily mean that you have to jump right in and start writing code. One of the fastest ways to build a clickable demo is to throw something into PowerPoint, do a bunch of screenshots of existing systems, cut and paste everywhere and set it up in such a way where if you have to click a button that essentially takes you to the next screen or the pop-up of what it is you're doing, there's absolutely no code behind the scenes. It's literally a bunch of screen mockups for most of the application. Typically, depending upon how advanced you go with the essential mockup design, don't get too far in the weeds on branding initially. The main focus of these clickable demos is to get it in front of the users to see how the application would function, how this feature works. Now, that may include branding, but branding should be at this stage very low on your to-do list. You're mainly looking to get what is going to be on the screen, essentially a wireframe, kind of mock up your input fields, buttons that need to be clicked, menu options, and you literally, if you're using PowerPoint, it's literally copy paste, create a new screen, do some mockups. Literally, unless you have a massive application, this should only take you a couple hours. So you literally could throw something together in a very short period of time to get in front of your customers and get immediate feedback. That's one of the beauties of this. Now, if you need something a little more in depth, and PowerPoint really isn't the direction you want to go, there are things out there like Miro and Figma where you can actually go build designs that are a little more elaborate. You can actually add some scripting to it. They've got more wire mockups for mobile, for web applications, for desktop applications. So there's a little more predefined there for these types of wireframes and mockups. In addition to that, there are other tools like Just In Mind that actually give you even more features where you can actually deploy these in an environment like Expo to a remote user. You can put it together, send it out, and let them play with it and then get their feedback. In addition to that, so now you kind of have all these tools to just get you there without writing code. The nice thing about those last few features is at that point, you can actually start polishing it a little bit. Given that a lot of these tools have custom models that you can drop in, oh, you need a login page. Okay, here's what the page looks like. Drag over some icons. You can almost make it look like a live application. Downside to that, if it goes off so well, they may want it like, oh, it's done. Give it to me tomorrow. No, this is just a mockup. It's a prototype. If you do want to jump into the full demo, actually writing like a kitchen sink mockup application, sometimes you need to go that direction. Sometimes you're building something that is either so cutting edge, bleeding edge, or just hasn't been done before. You kind of have to see if it will even work. Sometimes you kind of have to do a proof of concept in the process of doing a mockup or wireframe because you're not entirely sure that what you're proposing can actually be done. You might accidentally be saying, yes, we can do this, and then you find out that technology-wise or platform-wise, it's not a feature that can actually be implemented. You're going to avoid the headache of committing to do something that you just can't do or that the platform or features can't do. In that case, then you can pivot quickly before you even get into the full design implementation. That's a little bit going from the wire mockups to the actual design. The flip side of that, I will say, is if you're building any type of wireframe or mockup, we've talked about doing get repositories, doing source code repositories, kitchen sink apps in the past episodes. This is a cool and critical area that if you start doing lots of clickable demos, lots of wireframes, lots of mockups, take a lot of those components and drop them into your kitchen sink app or into your GitHub libraries so that you have this library of tools that you can use to quickly build mockups going forward for future customers or even hand it off to a development team and say, here, this is what it looks like. Build it. These are some very cool and very key areas to take you from that requirements section to getting something in front of the end user that will give you more feedback, get the conversation going more, but also tell you if you're on the right track. If you're not, where do you need to pivot and where do you need to correct course? So I guess there's a couple of things that, yeah, that those are all great points. And I think a couple of things that to sort of follow up to keep in mind as you're doing this is initially one of the first things Michael mentioned was you don't need code. There's a lot of ways to go through this, which is I'm glad he brought that up because I didn't. I didn't mention it at all. And those are great ways to quickly go through some sort of a mockup or clickable demo. Now, one of the things with these, when you're doing something like this, you actually want to put as minimal amount of code as possible into it because the whole idea is it may change dramatically. So while you may want to be going through and doing all this really nice, cool stuff and building out CSS libraries and all these react controls and crap like that, don't resist the urge because it may be totally not used. It may be something that you put something together and it gets thrown out completely. Now, if you have to build, particularly in a proof of concept kind of thing, if there's a solution that you need to build to a problem because you're trying to prove that the problem is solvable effectively, then you do want to have some way to take that code. It may be one and done or throw away code, but you also want to be able to have it, to build it in a way that will allow you to then take that and translate that into whatever the actual, you know, the actual thing is that you're going to be building down the road. Now, one other thing I'd like to bring up as part of this is while code is not very useful in a general sense in this case, one of the things that can be useful is the data that you use. Now, like, for example, Michael mentioned you can take screenshots and you can just throw some stuff in, things like that. If you can take screenshots that include data that is valid or relatable to the customer, that makes a huge difference. The kinds of things, now, sometimes you're like, oh, it's, if it's like a CRM, it's a customer relationship management kind of app, then it's just, you know, you can do Joe customer and 123 Main Street or something like that. And that sometimes works. But if you're in a specialty kind of thing, for example, if you're doing like a financial application or you're doing an EMR or you're doing an insurance or real estate or something where there is a specialty in there where it's some sort of a, I don't want to say it's quite niche because things like real estate are huge, but they have their own language where there are professionals that you get in there and there is a, I'll call it a mindset as well as a language or terms that they use, then you want to make sure that what they see in the demo makes sense to them. So if you see it, like I have been in situations like you have like the equivalent, let's say like you have an EMR and you're just showing a, it's just a clickable demo and it's a mocked up patient record and you suddenly, and you have like values that like the blood pressure was completely jacked up. I've had conversations, I've had stuff where it gets off the rails because they're like, that person's dead. You would never have that patient. It's like, I know, pretend it's a different value. You know, it's that kind of stuff. So make sure that you don't have your presentation, the details of the presentation override the demo side of it, because there is, remember this goes back to what is it you're trying to get out of them and trying to get them from them, some specifics, but really more a general, are we on the right track? And there's going to be, like I said, there's going to be sort of those risk items and you want to make sure that you get what you need about those risk items. If you allow it to, if you do it in a way that confuses them or distracts them from the things that you want to want them to focus on, then that can cause a lot of problems. Now the I sort of, I guess I'll wrap my wrapping thought on that is that Michael talked about design. There is, I personally go back and forth on this all the time. There is the part of me that would argue black and white, simple, like just squares and just nothing pretty. But, and sometimes that's very useful. That's really good. But I've also had situations where people are so lost because they have that completed thing in their head. Seeing the, we'll call it the very ugly because that's lack of, it's good as you can describe it, the very ugly presentation of just pure functional throws them off. I've had situations where it's just like, they're like, well, how much you get, can we use this color? Can we change this? Can we put an icon here? And they get into the design and it just becomes, you know, it becomes one of these things that it's like the, you're lost in another area. So parting thoughts on that. Yeah. So one of the biggest problems with doing wireframes and mock-up Rob really touched on is scope creep or feature creep. Cause as you're, as I was trying to walk through using the tools, you want to avoid like the styling. Keep that out. Black and white is great. I'm glad you mentioned that. The other thing too is sometimes like if you have an iPad or a tablet with paint, Microsoft paint on it, that you can just quickly sit there and just draw what it may look like to, in front of the user. Say here's an idea of what I've had. There's more times than I can remember that I just flip open my iPad, open up my draw tool and I just start drawing what I think it's going to look like. Now my drawing skills suck there. I'm nowhere near as good as my daughter. And I think if your daughter still draws, she, she could like, but it's all to shame, but sometimes even the worst oblong looking door for a box is more than enough detail to get your point across to the user. The point here in this topic that we're talking about is speed. You want to get this concept in front of the users as fast as possible because it's going to change a lot, a lot of rapid fire communication back and forth through this period will save you a lot of time, headaches and energy later when you start actually getting to the design and actually writing the code. That being said, I think it's time to wrap this one up as we, we have I think given you enough of a clickable demo of an episode that maybe we've given you some ideas, hopefully some things to think about the next time you're getting into whether it is a full blown clickable demo, or whether it's something where you're just like on a, you could even be on a sprint and you need to present something and it's just the words, words are not enough. It's a picture's worth a thousand words. So hopefully you've got something that you can think about next time through to really help you even on a small scale, do a demo proof of concept or something of that nature. One of the things you can always do is you can send us an email at info at develop a new or.com. You can contact us on our contact form at develop a new or.com. You can leave comments. You can have, there's so many different ways we're on X we are, you can subscribe to us on YouTube, on the podcast, wherever you get podcasts, leave us comments there, recommendations, suggestions, and everything else you have, because while we are moving into a new season very soon, and we sort of already have an overarching, overarching topic and epic that we're going to go through during that season, we're always looking for more feedback and where you want us to go and maybe some specific things that we can cover that we'll be able to work in along that way. That being said, we will wrap this one up. We'll let you get back to it. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers, the develop a new or 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.