Author: Rob Broadhead

  • Using a Clickable Demo

    Using a Clickable Demo

    One of the challenges with any project is getting everyone on the same page.  Over the years I have found that the best tool to help solve this problem is a clickable demo.  The demo is so useful it is one of the first steps in a new project.  Creating the clickable demo can be simple and straightforward or a big effort in itself.  However, these actions make even a complex system easy to model.

    Go With the Flow

    An important part of a clickable demo is an example of the application flow.  When use cases are properly done, they should be a stepping stone to the application flow.  The use cases will not provide all of the details, but a good demo will address every user story.  The look and feel of the demo are not as important initially as the flow.  It should model how a user will progress through the application while providing a rough approximation of the data they will be presented.  General navigation should be worked in early on as well.

    Look For Important Details

    Some requirements are more important than others.  The requirements that a good clickable demo presents include those around data input and output or reporting.  When a customer is reviewing a clickable demo, they should be able to tie steps into current use cases.  This link is best accomplished by showing details around each step.

    For example, let’s consider an application that includes data entry and search for entered records.  A good clickable demo will show the input fields as close as possible to the end product.  This should be at least eighty percent of the requirements for data entry.  The search, in this case, should allow a search on enough of the data entry fields to be easy to find any given record.  A customer should be given an example of how difficult or easy the interface will be for regular usage.

    Leave Room For Discussion

    The purpose of this demo-based approach is to provide a focus point for customers.  Don’t be afraid to leave a few areas open for interpretation.  Also, avoid getting designed into a corner.  The demo is not production code so spending a lot of time on it may be a wasted effort.  As iterations of the demo are presented there will be areas that become concrete, but early on avoid lock-in where possible.

    The Danger of a Clickable Demo

    I started with a claim of this approach being perfect for any project.  That does not mean it is not without risks.  The most common issue with a demo of this type is that it is “too good.”  In this situation, a customer falls in love with the demo.  The result is not a criticism, but instead something along the lines of “when can we ship it?”  This tricky situation can be avoided by clearly stating smoke and mirrors and lacking functionality during the walk through.  Set the expectations early, and clearly, so there is not an underestimation of the effort required to make the demo fully functional.

    The problem with a vision is that it is not reality.  Thus, everyone is left to their interpretation of the goals.  Try a clickable demo next time to bring a vision into reality early in a project life-cycle.  It will make discussions of the vision much easier and will help avoid misunderstanding of conceptual features.

     

  • Gathering and Defining Requirements

    Gathering and Defining Requirements

    One of the first steps in any projects is gathering and defining requirements.  These are needed to measure whether the features being built are useful.  Requirements also give us a way to map progress and eventual success.  Sometimes there are projects where we will have all the information we need to get started.  However, most projects will require us to gather, define, and refine these details from others.

    Gathering Requirements

    The process of gathering requirements from others can be complicated and time consuming.  Luckily, this is not always the case.  Gathering requirements can be straightforward when you follow the step below.  The order is not as important as performing each of these along the way.

    Find The Focus

    This is the primary reason for the project in the first place.  It is often a problem or group of problems to solve.  There should be a business reason for solving the problem.  Make sure this reason is understood.  Some requirements will be set directly from this focus, but it has a greater value.  That value is to lay a foundation for the requirements.  When a requirement is assessed, the focus of the project determines whether to include or exclude.

    For example, assume the focus of a project is to provide a quick way to enter a shopping list on a mobile device.  A requirement to force the user to enter a login and password each time would be excluded.  That function goes against the focus.  Not every requirement will be that easy to assess.  However, knowing and sticking to the focus can avoid scope creep.

    Define The Foundation

    In this step, the goal is to define some of the base features of the solution.  Over time these sort of features become standard questions for a stake-holder.  These will vary depending on the project.  However, this list is a good start.

    • What are the security considerations? Multiple Users?
    • Will reporting be required?
    • Is auditing or logging going to be required?
    • Does this require an offline/online mode?
    • Is mobile support needed?
    • How will this be used? (Web, Desktop, Mobile, etc.)
    • Do users need to be able to interact with each other? Be grouped?
    • What features will be used often and which used rarely?
    • Will data need to be kept forever? Briefly?
    These questions should be a start to adding your own.  Sometimes you will have the answers immediately.  However, when you can not answer them, pose them to the stake-holders.

    Create a Plan

    Once the requirements are gathered it is time to create a plan.  USe the requirements to build a story of how the solution will be used and how it will work.  This process is important for verifying with stake-holders, but also helps find gaps.  When requirements are viewed as a whole then often gaps will appear.  Think of a story with loose ends.  When requirements are not complete there will be loose ends that need to be addressed.  Thus, more requirements need to be defined.

    Verify Your Assumptions

    Take the plan to the stake-holders.  The plan should provide a complete story that makes sense to them.  This not only provides validation for the requirements that have been gathered, it also ties them together.  This step is often one that sparks stake-holder discussions about process steps and outliers that were missed.  However, It is often not a reflection on the requirements gathering.  Instead, it is a way to prompt for outliers and rare occurrences.

     

  • Native Mobile vs. Mobile-Friendly

    Native Mobile vs. Mobile-Friendly

    Mobile devices are becoming more popular every day.  Thus, it is more important to have a mobile strategy.  If you are delivering a service or product via the Internet, then you need to decide whether to go the native approach deliver a mobile-friendly solution.

    What’s The Difference?

    The first thing to clarify is the difference between a native and mobile-friendly approach.  A native mobile application is installed on the device.  It runs on the mobile device and potentially has access to everything on the device.  This access includes storage, cameras, and sound.  Since the application is on the device, it can run without an Internet connection.

    A mobile friendly solution is a website that works fine with mobile devices.  The application is run in a browser and requires an Internet connection, but otherwise, can look and feel like any other application on the device.

    Why Native?

    Native applications can be advertised and marketed through vendor stores.  This is the Apple App Store and Google Play for some devices.  Thus, getting your solution on the right stores can quickly expose it to millions of potential users.

    A native solution does not need to be connected, so it potentially has a greater use.  Unless a user is in a situation where they always have robust and reliable Internet access, there will be times the application lags or is unavailable.  Native solves that problem and can even sync back up to the Internet when needed.  Think about a painter that goes to provide estimates.  They want to be able to enter data for a job even when there is no connectivity available.

    Native applications also have deeper access to the device.  Thus, they are much more capable of utilizing the screen, camera, and other features.  This includes other applications.  Thus, a native app can take a picture and email it from your email app to someone on your contact list.

    Why Mobile-Friendly?

    To be honest, most of the mobile-friendly arguments center around cost and resources.  A mobile-friendly solution is built for the web and mobile standards.  This means that when Apple or Samsung release a new device the app will still work on them.  There is no need to spend time coding a solution for every device (or family of devices) out there.

    Although the application stores are an excellent way to market a solution, they can be time-consuming to use.  There are also restrictions on application certification for updates after the application is released.  This can put more pressure on developers and testing to be as feature complete as possible for each release.  Thus, it takes longer to get your solution in front of your customers.

    Native applications typically cost more to develop.  There are tools to help target multiple devices with a single codebase, but there are still implementation and testing considerations that make native development more expensive.  This also includes creating the app in a way that it will get accepted into a store.

    A single method of delivery (the web) makes it easier to provide a consistent experience for all users.  Whenever a user goes to the site, they will have all the functionality and not have to worry whether the mobile solution has the same features as the web.

    Which One Should I Choose?

    In general, there is no clear winner with either of these options.  The best path to take requires several considerations.

    • Do my customers need the application even without the Internet?
    • Do my clients have mobile devices or typically use a browser?
    • Can I need to support one (or a small number) device or will many brands need to be addressed?
    • Is time to market a critical factor?
    • Is this an application that app stores will automatically reject?
    • What resources and budget do I have available?
    • Is native a goal I can work towards rather than hit it in version 1.0?
    • What are the key features/functions of the solution?
    • Are the essential functions possible with a web solution?

    These are just a few of the questions and decisions that go into a mobile strategy.  The import of mobile has grown to the point that it is a sound investment to consult with professionals.  The best experts to ask may already be in your company IT department, or there are a lot of good providers available within a wide range of budgets.

    Delivering a mobile solution is big business.  It is also a big decision.  Therefore, it is worth your time and resources to plan out a strategy.  The old days of “lets build a mobile app” as a strategy are long gone.  Set your mobile strategy and move into the future with confidence.