Tuesday 11 September 2012

Key Factors Customers Will Use to Judge the Value of our Product

The POSivite places tool will have two main sections, the main searchable interface allowing users to examine the current distribution and access to POS and POS amenity for planning and health outcome analysisDemographic information will also be provided in the context of park accessibility (i.e. 5 minute walk, 10 minute walk, etc).


Phase 1:

We anticipate that this main interface will be useful to a variety of customers including the general public, local governments, planning professionals in a variety of environments (i.e. local, private and state offices), and health researchers interested in exploring the impact of POS and park access or amenity on health.

For all of these users the following points are important:

  1. A clear, logical interface allowing a variety of starting points to conduct a search
  2. The ability to explore and display information about POS and parks specifically
  3. To summarise POS and park information by suburb, local government area (LGA) or region 
  4. To understand our concept of 'park' and other POS definitions
  5. To be able to use relevant POS information for research or general interest purposes
To achieve the first, second, and third points, the product needs to provide an intuitive user interface for searching POS, browsing the map, and summarising results.  Search results must be displayed in a clear and concise manner. To achieve the fourth and fifth points, the product needs to ensure that the data is available for download in a common user format, can be easily linked with other georeferenced information, and that adequate metadata is included. The metadata will need to provide origin of input data, details of methodology, and POS definitions.


Phase 2:

The second section of the POSivite Places tool will allow registered users to log in and perform more in depth analysis of POS, including the ability to load a user's own spatial data (i.e. GIS polygon layer representing a health study area) and gather POS summary information specific to their own user defined area.  In addition this portion of the tool will offer the ability to examine the impact of population change on the provision of POS and POS amenity through scenario testing.

For these users they will be need to be able to: 
  1. Upload their own spatial data in an easy to understand process
  2. Perform basic spatial summary (i.e. with own polygon) functions
  3. Output results in a meaningful format for their own research or exploration purposes

Why a POS Tool?

To date, a comprehensive dataset of POS location and POS amenity does not exist across the Perth metropolitan region. The data that does exists is owned predominantly by LGAs (created on their own volition for use in-house) and therefore a consistent POS data set for the entire region is not available. This makes it extremely difficult to conduct regional comparisons of POS distribution or POS accessibility (for areas that span more than one LGA). Furthermore, our data exits as a GIS database, and not all users have access to, and/or the skills required to analysis this type of information. By providing a user friendly web based interface, interaction with our POS data is available to a greater range of potential users.        


Will it work?

We are confident that through feedback from a willing group of testers in both academia, and the public and private sectors we will collect valuable feedback concerning both the usability and functionality of the POS Tool. Whilst there is also potential for wide use by the public, no formal testing of this group will be undertaken.

1 comment:

  1. But who are your main customers (as in who is actually going to be engaged throughout the project), there are lots of potential users listed ("general public, local governments, planning professionals in a variety of environments (i.e. local, private and state offices), and health researchers") are they all represented as *real* people working with the project sprint to sprint to see that it meets their needs? Perhaps, a primary real participating user would help focus this project to help keep scope creep out?

    Some clearer feedback mechanism should be discussed in the project team, are there programmatic tests that are in place (e.g. unit or behaviour driven testing), what is the method for engaging user feedback (e.g. user groups, fortnightly feedback forums). How regular will these tests occur, once at the end or iteratively throughout? The team might want to undertake a SWOT analysis as an activity? Yes this looks good, but a tool without a commonly understand testing process is subject to the 'observers paradox' - who is your critical user who is going to questions the actual product viability for 3rd parties?

    Saying that your phases make sense, I think they just need a little more planning detail in terms of engaging real users to see the features in action.

    Look forward to reading more posts in the future. Good luck :)

    ReplyDelete