On this page:
- Workflow overview
- 1. Determine use case
- 2. Scope functional requirements
- 3. UX research
- 4. Information architecture (IA)
- 5. UX design
- 6. UX validation
- 7. UI design
- 8. Supply of design assets
- 9. Refine user story - define acceptance criteria and solution direction
- 10. Development
- 11. User acceptance testing
- 12. Quality assurance and acceptance into the distribution
- Workflow examples
All new features developed for Single Digital Presence should of use to many on the platform and not just bespoke features each with a single use case.
This workflow provides a set of stages. All may not apply for every new feature. Some examples of workflows of components of differing complexity are provided below.
|1. Determine use case||✔||✔|
|2. Scope functional requirements||✔||✔|
|3. UX research||✔|
|4. Information architecture||✔|
|5. UX design||✔|
|6. UX validation||✔|
|7. UI design||✔|
|8. Supply of design assets||✔|
|9. Refinement of user story||✔|
|11. User acceptance testing||✔|
|12. Quality assurance and acceptance into the distribution||✔|
1. Determine use case
SDP product manager and client:
- identify the goals and background of the desired feature
- determine fit for the SDP platform
2. Scope functional requirements
Any new component we add needs to:
- have flexibility to suit a range of uses
- be approved by the SDP product manager
SDP product manager and client:
- conduct a gap analysis between the needs of your site and current SDP functionality
- scope what new components are required to meet your needs
- write high-level user stories
- identify the level of work required for each component
3. UX research
All new components must be informed by a clear user need - from the users of your site specifically and Victorian citizens in general. Key findings from this user research can also feed into the SDP knowledge base.
Read our user research beginner's guide
At a minimum, you must:
- identify the users of your site
- define user needs, pain points and tasks
Outputs may include:
- user profiles or personas
- key user tasks
- insights into user behaviour, motivations and needs
4. Information architecture (IA)
The organisation and naming of content on your site is critical to its success. Although this won't impact the design or development stages, we strongly recommend you design and validate your IA. This can then inform your content strategy.
Useful exercises for developing and validating an IA:
- card sorting workshops with users to group and name content
- tree testing with users to validate structure
5. UX design
We recommend you develop and test low-fidelity prototypes (wireframes) before creating the user interface (UI) design. The SDP team will use these to confirm the proposed feature is consistent with the SDP platform and scalable for use by others.
- new functionality designed as wireframes
- interactive prototype created (if needed)
- interaction demonstrates intended functionality
Outputs may include:
6. UX validation
Before we implement any new component or feature in SDP, you need to verify that it peforms well for users. User testing with real is the best way to do this.
Read our digital standards on user testing
- Write testing scenarios that reflect real use cases of the new feature. (Not all components require explicit testing, though it never hurts.)
- Use scenarios to test your prototype with real people representative of your user base.
Outputs may include:
- findings and insights
- feedback to inform iteration
7. UI design
The SDP front end was designed using atomic design .
All new components have to be consistent with this design approach and the overall experience of SDP.
8. Supply of design assets
Design assets need to be provided in enough detail so that the SDP team can incorporate them back into the pattern library (Ripple design )
You must supply:
- a UI design that is congruent with the rest of Ripple
- clear interaction designs, including hovers, animations and transitions
- clear responsive behaviour (based on our existing grid system)
- Sketch files (get the Sketch )
Outputs may also include:
9. Refine user story - define acceptance criteria and solution direction
Each new component must have a user story clearly defining:
- acceptance criteria - what the component needs to do in order to meet requirements
- solution direction - dot points outlining the basic direction to meet the requirements, including information such as existing modules to install, new modules to build, entities to create and the fields within them
This story then becomes the source of truth for updates and changes as the component is developed.
The solution direction can be a set of dot points outlining the basic direction to meet the requirements including information such as existing modules to install, new modules to build, entities to create and the fields within them.
The solution direction on each ticket must be reviewed and accepted by the SDP development team. This ensures the new development utilises and reuses the tools already built into SDP products, which:
- reduces build time for new features
- ensures they’re built in a way that is consistent with other SDP features
This process remains the same for complex new modules or content types or the simple addition of an existing contrib module.
The story should also include testing notes. These test notes help the SDP internal testing before the new feature is absorbed back into the SDP platform.
We user JIRA for user story tickets.
Information on user
The SDP project team requires access to the vendor's project board and tickets for the new component so they can
- collaborate closely on solution design
- manage the project timelines in line with the product development timeline
Code must be developed to our code .
11. User acceptance testing
The SDP team will use the test notes in the refined user story to conduct their internal UAT before the new feature is contributed back to the SDP platform. Test notes will be captured in the user story.
12. Quality assurance and acceptance into the distribution
need something here
Depending on the complexity of a new component or feature, you may not have to undertake the entire workflow. These examples illustrate how different component complexities affect the workflow required.
Complex component: New page template for ‘Publication’
This was scoped as a new template for displaying long-form multi-page content previously
published in PDFs.
This was a substantial development from existing functionality It also required
changes to the editing experience for content editors.
Therefore the full workflow was required, including:
- research to determine the user needs and behaviour around this function
- prototyping to explore a solution
- usability testing to validate the solution worked as expected.
Semi-complex component: A newsletter sign-up module
This was scoped as a basic form that could be embedded on any page.
This was functionality with a very defined and well-understood user need so dedicated user research was not necessary. However, the behaviour and design of the component was still to be established. Therefore the workflow could skip the research phase, but still needed prototyping and usability testing.
Simple component: A customisable background colour in ‘campaign’ block
This was scoped as a cosmetic change to introduce more visual variety into a page. As this had little to no impact on the usability of the website, there was no need to research the user need or validate the new component with usability testing. Therefore the workflow could jump straight from scoping to UI design.
Reviewed 20 June 2022