{"id":1078,"date":"2023-08-23T18:38:34","date_gmt":"2023-08-23T23:38:34","guid":{"rendered":"https:\/\/rb-sns.com\/RB\/blog\/?p=1078"},"modified":"2023-08-23T18:38:36","modified_gmt":"2023-08-23T23:38:36","slug":"clickable-demos-and-wireframes","status":"publish","type":"post","link":"https:\/\/rb-sns.com\/RB\/blog\/clickable-demos-and-wireframes\/","title":{"rendered":"Clickable Demos And Wireframes"},"content":{"rendered":"\n

Creating software requires using tools like clickable demos and wireframes to bring a vision to life. Likewise, these tools provide a canvas upon which to refine that vision. There are many ways to make the most of these tools. Thus, we will start with a definition and then move on to how to make them work for you as a developer or a customer.<\/p>\n\n\n\n

Clickable Demos and Wireframes Defined<\/h2>\n\n\n\n

These two ways to build and demonstrate software are so common it feels almost unnecessary to define them. However, we must be clear on how these tools work so we can make the most of the efforts involved. Along with effort, time is invested in these approaches, and we want them to be used as efficiently as possible. First, a wireframe is a drawing of some form or page of an application. It gives a sense of look-and-feel as well as user experience. A series of wireframes can be used to walk through a user story, much like a child’s picture book.<\/p>\n\n\n\n

Next, we have a clickable demo. This is sort of the next evolution of a wireframe. In this case, we have forms and pages that are “live” enough to click on buttons or links and navigate through to another page. The most significant difference is that wireframes tend to be more UX-focused, while the clickable demo is more about displaying flows and actions. Think of them as form (wireframes) and function (clickable demo).<\/p>\n\n\n\n

Using Them For Better Communication<\/h2>\n\n\n\n

We start with the most critical outcome of these tools. They provide a way to communicate the application being built amongst technical and non-technical team members. We get to see what it will look like or at least closer to it than words on a page. Even drawn images will differ from how they look on a computer screen. These tools take us through the process of building the interface (and potentially navigation) and then provide a way to share it with others. Better yet, we end up with something people can refer to for edits and additions that are more concrete than a few sentences in a document. Those pictures are worth at least a thousand words.<\/p>\n\n\n\n

Try Before You Buy<\/h2>\n\n\n\n

One effect of using clickable demos and wireframes is that users see the result in action. While it is imperfect because performance and similar issues can arise, it still shows details a vision does not. I am amazed at how often these tools lead to minor or even drastic changes to the user experience or features available. The users get a form of “try before you buy” in that they can see it working to some extent. In any case, a greater degree than a document shows.<\/p>\n\n\n\n

User Error and Developer Assumptions<\/h2>\n\n\n\n

The testing portion of application development<\/a> can also take a long time. There are user errors that were never conceived and developer assumptions that show up only once the solution is in use. Even regular product demonstrations can suffer from these afflictions as demos tend to be scripted and controlled. It is not the same as putting it in the hands of users. That is where a clickable demo can provide a ton of value. A user can be asked to “drive” a demo or be allowed to use it on their own time. I highly recommend this as part of any clickable demo strategy. Set it up so users can spend time with it and click around to assess it. You will be amazed by what they uncover and the feedback they provide.<\/p>\n\n\n\n

Follow The Rabbit Trails<\/h2>\n\n\n\n

Happy path testing is the name for testing a system using pristine data and flawless navigation. This has its value but doesn’t do much to uncover bugs. The best testing comes when users try a different approach. Use this to your advantage while showing off a wireframe or clickable demo. You can ask several questions during the demo to chase down those details and potential bugs.<\/p>\n\n\n\n