Category: Building Software

  • Clickable Demos And Wireframes

    Clickable Demos And Wireframes

    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.

    Clickable Demos and Wireframes Defined

    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.

    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).

    Using Them For Better Communication

    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.

    Try Before You Buy

    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.

    User Error and Developer Assumptions

    The testing portion of application development 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.

    Follow The Rabbit Trails

    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.

    • Is there anything missing from this process?
    • How quickly do you expect this action to respond?
    • If this action fails, how would you expect to be notified?
    • What are some ways you can see this action failing?
    • Does this make sense, or would you prefer a different path to trigger the action?
    • Is this an action someone in the room typically does? Or do we need to contact another person to serve as a subject matter expert?
    • Look closely at the data on the screen. Does it provide what you need to perform your job?

    Craft The Story

    While there are many good ways to use these tools, the best is to make your user stories come alive. These present a solution far better than even the prettiest and most detailed user stories. There is nothing wrong with them. It is just that visual examples remove a lot of ambiguity while clarifying communication. Make them a part of validating user stories and designing them in partnership with customers and users. The user stories almost become the script you walk through using the wireframes and clickable demos. If they do not match up or users get confused, you know you have changes to make.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. Every project we work on includes demos and similar discussions regularly. We build clickable demos and use wireframes as applicable to ensure the team has the best tools for discussing the solution and vision. Likewise, those include a release our customers can use to test the features further and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects. 

    Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.

  • Minimum Viable Product (MVP), Proof-of-concept (POC), and Incremental Solutions

    Minimum Viable Product (MVP), Proof-of-concept (POC), and Incremental Solutions

    Modern software development often involves a minimum viable product (MVP), proof-of-concept (POC), or other partial or incremental solutions. These approaches embrace the reality of software being difficult and time-consuming to produce but highly valuable for the users. The tactic is a form of the Pareto principle where the focus is on getting a large amount of functionality delivered quickly. Thus, we must be intentional about building these out so they can benefit us (and our customers) now and in the future. Now, let’s start with a look at some common ways to get a portion of the problem solved and deployed quickly.

    The Minimum Viable Product

    The MVP is as close as we get to the objective of releasing a product in the shortest amount of time. The key to this approach is the word “viable” and how it applies to our product. However, It must be clear that the result of an MVP is a product that can be put in front of customers or users. That includes deployment, training, and documentation as needed. Therefore, we can also consider this a phased or versioned approach to releasing the product.

    You can also think of this as finding the solution with “just enough” functionality to be useful to the customers. Thus, this is the point where the solution is worth the money charged to customers. However, there is often a promise of some sort of follow-up features or releases that will be provided to customers. They are buying the product with an understanding that more features and functions will be coming in the “near” future.

    The Proof-Of-Concept

    A proof-of-concept is an excellent way to see what the solution to specific challenges in a project will look like. These are often functional only and not the “pretty” solution customers will see. A POC is a research project where technology and knowledge are tested to produce a solution to a new or unique problem. However, this approach also can be used to create baseline metrics for a solution. The resulting POC is far from an MPV. At this point, we are only proving that the technology exists or our design is sufficient to solve a specific problem.

    For example, a common POC category is where an integration is required. Even though the desired integration might be fully documented and a public interface, there can be critical issues that arise. A POC is the best tool for tightly defining a result so that it focuses on solving our research goal or unique problem. Thus, when we talk about “why,” the POC is a very tightly defined and specific focus that adds no bells or whistles.

    Agile and Incremental Solutions

    When one is unsure of what they really need or require rapid partial turn-around, agile and similar incremental solutions are the best. These embrace the “satisfy the customer” focus of the Agile manifesto and keep everyone in a high-efficiency mode. The key to this approach is that the team always has an objective that is reasonable. Thus, it is short-term ( a few weeks), and they are held accountable. The design and management of the project are much more active, though.

    The goal in this approach is to continually (every sprint of a few weeks) set up goals that are realistic. Likewise, they must advance the features for the users. The result is a highly flexible approach to solving the problem. The rapid turnaround earns the trust of users by regularly responding quickly. However, it can be overwhelming to the user base. They will work on a product that is regularly adding and improving features, which can be frustrating. On the other hand, this can be an approach that incrementally offers features to users. Thus, the solution is easily trained and learned through this piecemeal approach.

    The Best Approach

    Each of these approaches answers the challenge of getting to a solution quickly. That objective is valuable whether it is customer-facing or not. All of these embrace the Pareto principle that is far too often ignored in software development. Actually, it is ignored too often in many product development efforts. Worse, it is often ignored in problem-solving for businesses. We do not need the highest-end solution for all of our problems. Far too often, the budget solution is perfect for our needs. We can add bells, whistles, and deeper functionality inn the future. Thus, our best approach is a solution that works most of the time sooner rather than a complete solution weeks or months from now.

    Each of these approaches has a different goal. You can use MVP when you know you need to solve the problem sooner rather than later. A POC will answer whether your most significant problems or concerns can be met. Finally, the Agile approach will keep you churning out results regularly while building out a full-featured solution.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. We have experience in each of the approaches above and can help you make the most of them. Every project we work on includes demos and similar discussions regularly. Often every two weeks, including a release our customers can use to test the features further and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects. 

    Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.

  • The Value Of Demos and Walk-Throughs

    The Value Of Demos and Walk-Throughs

    One of the most challenging facets of building software is determining where to spend our time. Demos and walk-throughs are one of those areas that can be overlooked in the chase to save time. However, they are essential in communicating progress and gathering feedback. These require time and attention from everyone on the team, so let’s look at ways to ensure we get the most out of this investment.

    Demos and Walk-Throughs Are Not Optional

    We can start by agreeing that every project requires this activity at least once. While one can build a solution and “throw it over the wall” to the customer, I do not know anyone who accepts that approach. There are too many details, and custom software is too expensive. No one buys a house without a walk-through, and software should not be any different. A big cost equals a big investment. Therefore, we want to review the results before signing off on them. That can be accomplished without a demo, but it can be time-consuming and confusing to jump into a system and try to use it. We need context to help us assess a solution, and that is where demos and walk-throughs fit into the process.

    Your Definition, My Words

    An excellent way to be clear when we are communicating is to have someone say back to us what we told them but in their words. The same exercise can be done through a walk-through of a solution. The project starts with requirements and a solution specification to ensure everyone is on the same page. However, there can be design drift and miscommunicated goals that cause a solution to vary from the specification in subtle yet critical ways. A demo helps us detect drift sooner and possibly avoid these issues. At the very least, this helps us reduce the cost of correcting drift. The implementors explain how the solution works while showing it in action. That provides a perfect starting point for concrete discussions and feedback about the solution.

    Assumptions and Details

    When we describe a process or problem, it is easy to incorporate assumptions and gloss over details. For example, think about explaining how to tie a shoe. Write down the steps you need to take and then follow them explicitly. Most people will fail to tie their shoes. The details and assumptions hidden in the process steps do not become apparent until you test the steps by applying them.

    Modern software is highly complex and detailed. Thus, we need to test the steps and requirements we start with through regular demos and walk-throughs that explicitly follow the implemented solution. This provides us more confidence with each successful journey through a feature while also making it easy to see exactly what is being built. That reduces confusion and invites feedback to correct any drift or misunderstandings. The cost-savings and improvement of the success rate from these activities alone make them essential in any project.

    Trust and Teamwork

    The above reasons should be enough to convince anyone that demos and walk-throughs must be a part of every project. However, many more benefits come out of those meetings. The most valuable of them are trust and teamwork. A demo that includes feedback and discussion is, almost by definition, teamwork. The participants work together toward a common goal. These interactions also build trust and relationships that are essential for a strong team. Projects often hit rough patches and introduce stress into the team dynamic. When we have trust and solid relationships, these bumpy periods are easier to navigate. A lack of trust in any group or relationship will almost always make the hard times harder.

    Transparency

    We get a form of transparency as well as clarity through regular demos. The progress made and how it looks is available to all via these meetings, and that drives dialog which drives understanding. However, these benefits are not a given. Here are some things that need to be a part of the agenda to make the best use of this investment in time.

    • Have an agenda. This seems redundant, but every demo should have a plan. We want to ensure good discussion and avoid too much time spent on distractions or minor features.
    • Include regular set-asides for Q&A. Make it clear that feedback and discussion are a part of the plan and schedule time for it.
    • Provide a reason or story. A good solution will point back to the requirements and the problem definition. Each demo should be a step in the story from the whiteboard to solving the problem as defined at the beginning of the project.
    • Include more action and fewer screenshots in a demo. There should be almost no “talking through” steps and instead show the steps with inputs and outputs. This avoids possible confusion and ensures the resulting solution is a reality rather than smoke and mirrors.
    • Provide for an expanded discussion where needed. Some problems and challenges can take a lot of time to work through. A demo highlighting an issue should not be ignored or discussion constrained. Instead, provide a platform for full discussion and the best decisions to be made.
    • Avoid the firehose approach. Sometimes a lot of progress is made from one demo to the next. That can lead to information overload. Set the pace and volume of a demo so the audience can digest what they are seeing and provide timely feedback. A demo that is overwhelming in scope is more likely to miss details through sheer overwhelm.

    Remember The “Why”

    There are many benefits to these investments of time. However, we need to ensure we keep the reason for them in mind. Our goal is to show off progress and gather feedback. Thus, when we forget to make these a part of each meeting, we fall short of our goal. That limits our ROI and increases our chances for mistakes and even failure. Avoid this misstep and keep the team focused on what is expected of each meeting. The Agile Manifesto says it best when it points to the utmost goal of software should be to satisfy the customer. Use these tools to help ensure that remains the primary goal.

    Next Steps

    Feel free to schedule a time to discuss your next project with us. Every project we work on includes demos and similar discussionns on a regular basis. Often every two weeks and those include a release our customers can use to further test the features and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects. 

    Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.