#openUPD (User Product Design) is a framework which I have had growing in the back of my head for the last few years. It provides a set of general rules which ensure projects are scoped to, and remain focused on delivering outcomes, not outputs.
The steps within this #openUPD ensure projects outcomes are based in researched facts and have a solid business case for a foundation. They also ensure project activities/outputs are continually validated against project outcomes (what your users said they needed.)
The steps below provide an overview – not instruction.
#openUPD does not tell you how to manage your projects, nor is it to be adhered to like a project methodology. It is an approach with a framework to provide guidance.
#openUPD is a framework from which to base your planning at a program level. The steps ensure your supporting projects are based in fact and research with a strong business case that has clear outcomes which can be measured on the release of a final solution.
Stage 1: Research and Analysis
Before you can build, before you can implement, before you can even begin to plan you need to understand what the product or solution is going to achieve or resolve.
Understanding the needs of your users (customers) should provide you with a clear understanding of who they are, what they need and want, and perhaps most importantly: why they are your user.
In addition your research and analysis should identify what your business needs are, how external factors such as government legislation or industry standards may impact your solution, what your technical or business framework limitations are, and potential future needs of both your customer and your business.
Stage 2: Identify Outcomes
Outcomes are the business case for why you do anything, it is the action or activity which arises from your project that can be measured to define if the solution delivers on its intended outcome.
The outcomes must be drawn from your research. The outcomes must not be generic, they should align with a particular business or user problem to be resolved. The outcomes should recommend specifications based on what your business and users said to you during the research stage. This way they are measurable.
The outcomes should take into consideration regulations or standards – this is important, you don’t want to spend a million dollars only to find out your solution is inaccessible to portions of your customer base.
Clear outcomes reduce uncertainty and provide a map to guide the project or solution should it start to drift.
Stage 3: Specify Requirements
The outcomes feed your requirements for the solution. Regardless of whether your project is technical or business or both – the solutions requirements must be mapped. The requirements should spell out how the outcomes will be achieved.
For technical projects this may be as little writing the functional/non-functional specifications. For a business project it might be mapping and identifying the possible impacts the change will have on processes, positions or governance frameworks within an organisation.
The requirements must be detailed, they must provide a clear indication of what has to be done in order to achieve the identified outcome. If you are unable to map your requirements to the potential outcome – go back to your research, or perform a new round of research to validate the outcome with users and business.
If you can not set requirements for your outcome – then your outcome is not an outcome, it is an output which is a requirement.
Stage 4: Create and validate
Use the requirements to plan your project, implement the planning, and validate the solution with your users as you progress. Use any product based development method you want to follow. However, you must integrate user validation into the process.
Your final users should be included as much as possible. Users can validate everything from your interfaces through to the writing style or process which make up particular parts of your solution. The user validation process should be iterative and integrated into your creation process alongside testing or edits.
All validated feedback should integrated into current creation rounds, any additional functionality or requirements should logged for continual enhancement following launch, and any fundamental flaws in the solution should follow a streamlined version of Stages 1-3 for remediation.
As part of the creation and validation process the products produced should be checked off against the outcomes and outcomes requirements to ensure the solution is going to deliver according to the needs of users not the creators.
Stage 5: Beta test and Launch
Beta, trial, market test, what ever you want to call it – validate your solution with users before you release it. Take their suggested feedback and validate it with other users. If that feedback indicates changes are needed, make them.
Validate the solution meets all of the outcome requirements, and that the solution will produce the required outputs to produce the recommended outcomes.
Follow any process you choose to launch the solution.
Stage 6: Validation and Continual Enhancement
On the launch of the solution you will be able to assess if the outcomes requirements have been met. For example, the website functions as it should or people are following a particular process.
After a period of time you can validate the outcomes have been achieved. For example, are more users using the website because it is easier to use? Has the business process improved productivity?
Validating the outcomes with users ensures the solution is achieving its intended purpose, and provides the additional information needed for continual enhancement. The information collected during repeated validation or feedback cycles builds the business case for the solutions enhancement over time.
Users needs evolve over time, along with their expectations based on experiences in other parts of their lives. To ensure the solution continues to meet their needs it must be continually validated.
The tacky bit
This information is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0).
If you would like to argue, change, contribute or encourage me to do something else with my life, leave a comment at the bottom or harass me on twitter @grmsn.