Contribute a new feature to SDP

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.

Workflow overview

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

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.

Suggested steps:

• new functionality designed as wireframes
• interactive prototype created (if needed)
• interaction demonstrates intended functionality

Outputs may include:

• wireframes (sketched or digital)
• prototypes (paper or digital, eg using software such as Axure or Invision)

Information on wireframing

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 users is the best way to do this.

Read our digital standards on user testing

Suggested steps:

• 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 principles.

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 system)

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 app)

Outputs may also include:

• a Zeplin project
• an Invision project

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 stories

10. Development

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 standards.

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

Workflow examples

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.