Design Principles

Should we build it? How do we decide?

The following questions may help Product Owners to guide the effort of their team. These questions are not meant to be a checklist, rather they are tools to help you think critically about your roadmap and backlog and about the individual stories. These question may also help team members to make certain technical decisions and determine how to handle technical debt.

• Will the feature make the product more useful to a larger audience of users?

• Does the feature help to improve how the users trust the product?

• Will more people choose to use it because of this feature?

• Is the feature doing something that was previously hard work for someone to do in another way?

• Is the planned work avoiding opinionated designs and instead allowing for configurable choice?

  • e.g. BCGov Theme can be selected, but if another province was using our product, could they easily select they own style library to use?

• Does it increase the reputation of the team?

  • how we document

  • how we code

  • how we deploy

  • how we test

  • how we work (agile fluency)

• Is there measurable value aligned to a user problem?

Context

Do you have an understanding of where your component fits? Who is it for?

If you are building something with the intention of it being used as a common component then consider the following:

Select a Delivery Method(s): Hosted Service, Reusable Component, Shared Code, or Tested Instructions

As you consider how users are wanting to consume your product to gain value from it, selecting the right delivery method will help you to maximize the value while limiting overhead.

Understand the Capability Level: Core, Supporting, Service Management, or Service Quality

Core capabilities are the ones that users will ask for. Supporting capabilities are the ones that service providers need to implement for the core ones to work. Service management capabilities are the ones that help you operate the administrative work back stage. Service quality capabilities are the ones that help you have a good reputation because your software is reliable, secure, privacy preserving and high performing. Understanding the capability level will help guide your work to identify user groups and help you determine the scope and boundary of the product you are building.

Ecosystem

What are the other products or services that may be doing what I’m doing? Who can I collaborate with?

Your product or service may operate within many categories of software capabilities. Start with looking at just one of those categories that you think might benefit most from using common components.

High Level Categories

• Discovery of

  • Products

  • Services

  • Careers

  • Procurements

  • Data

  • Subscriptions

• Submission of

  • Enquiries for information: Asking for guidance

  • Requests to create, update or delete something: Asking for coordination

  • Applications for a decision to be made: Asking for support

  • Messaging to provide comments: Feedback elicited and voluntary

• Processing (Operation)

  • Status: recording, tracking and displaying the state of a users submission

  • Comments

  • History

  • Assignment

  • Notification

  • Automation

Analytical Iterative Feedback, measuring the pulse on the three pillars and adjusting as necessary

• internal adjustment based on user centric feedback

• external adjustment based on industry factors