Explore Scope

With the goal in mind, the team needs to define what to build to make that happen. While the team doesn’t need to detail every requirement up front, they do need to understand enough about the full scope of the solution in order to select and estimate the first release. Teams will also do enough design in order to make key design decisions and ensure they start building on a solid foundation.

Step 1: Define Personas

Defining the application starts with understanding those who will use it. For each type of user, teams should create a persona. The persona not only defines the role this person plays in the application, but also describes a representative profile of the person, including their background, needs and typical work environment. By personalizing the user profile, teams can focus on what end users really need and how they will interact with the application.

The persona could include:

  1. Name and role
  2. Technology familiarity
  3. Devices used
  4. What activities they perform in a typical day
  5. Current pain points       

Resources

Step 2: Review Current State

Given that the new application will change the way stakeholders work, developers need to understand that context well and look for ways to make their job easier. Ideally, this would happen by “walking the floor” with real users performing their jobs. If that’s not possible, an SME could describe it. For each major step in the process, focus on two things:

  1. Why do they perform each activity (ie. what outcome are they trying to create)? 
  2. What are their biggest pain points (ie. what makes this activity hard today)?       

Step 3: Build the Product Backlog

Now, development teams must identify the required functionality for the application. Teams do this using a technique called Story Mapping where they will identify what, exactly, the application will need to do. By distilling the major activities users perform into smaller tasks, teams can show how everything fits together. Each of these requirements will be captured in a User Story which illustrates how the user will interact with the application. By focusing on the interaction and expected application behavior, this avoids constraining the team to a specific design at such an early stage. Finally, all of the stories from the map will be collected into a list of requirements, called the Product Backlog.      

    Step 4: Identify Design Constraints

    In addition to the required application behavior, teams must identify important non-functional requirements of the solution. These include:

    1. The expected usage including total number of users and expected peak concurrent usage
    2. Expected user interface response thresholds 
    3. Expected annual record counts for key entities
    4. Security requirements
    5. Accessibility requirements

    Teams should also perform an environment sizing analysis at this stage in order to forecast infrastructure requirements.

    Step 5: Prototype Ideas 

    For critical design elements, teams create light-weight prototypes. This allows for fast feedback from stakeholders and to ensure the team has a clear understanding of what’s needed. It’s often easier for users to communicate what they need by reacting to something concrete. Light-weight prototypes enable valuable feedback without significant effort.

    Here are typically the important design aspects to prototype during the design phase:

    1. A conceptual model of business objects and their relationships to each other
    2. User and Role management
    3. The screen flow of major use cases
    4. Expected reporting needs 
    5. Integration points with external systems
    6. Document management strategy            

    Resources

    Previous Next
    Related
    Recommended