Join Together employs an agile software development process. We favour:

• collaborative requirements discovery
• iterative development and delivery
• real user testing and feedback

over:

• exhaustive upfront requirements gathering
• big-bang releases

For every engagement we build, deploy and test a working system as quickly as possible, normally within the first few weeks of the project. We iterate and build on it based on testing and feedback from you, as well as things we learn from real users in moderated usability testing sessions.

Our ability to quickly build and iterate based on feedback using actual working software is one of the reasons we deliver the best online join systems in the business.

A typical Join Together project will break down into the following phases:

1. Discovery, service mapping and question protocols
2. Initial build
3. Iteration cycles based on feedback and usability testing
4. Staged beta releases, leading to a final launch

1. Discovery, service mapping and question protocols

A Join Together project starts with a one-day in-person kick-off workshop bringing together as many key stakeholders as possible. Together, we explore the problem domain from various perspectives, review the existing joining process end-to-end, and establish a shared understanding of the overall aims and objectives for the project.

For the best outcome this workshop should include representatives from every stage of the member joining experience: from the membership team to reps and organisers; from IT to comms and marketing. Each will have their own unique perspective and appreciation for different aspects of the member joining experience that will help enrich and improve the new system design. They will also have their own needs and requirements that the new system should account for.

The service map

The learnings from the kick off workshop are used to develop the project’s first major artefact: a high-level service map. The aim of the service map is to illustrate:

• the full end-to-end user journey for someone joining the union
• a wireframe of the various questions that users need to answer to complete their membership (including any branching for optional questions only required for certain circumstances or scenarios)
• any interactions with other systems, for example the union’s CRM, or data sources and APIs for things like employer lists and subscription rates
• any user journeys for union users, such as membership staff or reps

The question protocol

The service map is supported by a question protocol that is developed alongside it. A question protocol establishes:

• all the questions that need to be asked of a user to become a member
• who within the union needs the answers
• what they use the answers for
• whether the answers are required or optional

The question protocol is an opportunity to reassess and interrogate the data that is currently collected by the union from its members. The aim is to establish the necessity and value of the data being asked for with a view to minimising friction and ensuring a smooth user experience for those trying to join the union. Knowing why each question is asked can also help to better frame each question in a user-friendly and open way.

The service map and question protocol capture the shared understanding between the Union and Join Together, and will continue to evolve as the project progresses. Both are reviewed for accuracy and completeness with relevant union stakeholders before the project moves on to the next phase: Initial build.

2. Initial build

Once the service map and question protocol have been reviewed Join Together starts putting together the first version of the new join system, focusing on the most common scenarios first. We put an end-to-end form online as quickly as possible so that the cycle of testing, feedback and iteration can begin.

3. Iteration cycles based on feedback and usability testing

The key to the creation and deployment of a successful online join form is repeated cycles of testing, feedback, and iteration. Our testing and feedback happens in two forms:

• Testing and feedback from union stakeholders
• Moderated usability testing sessions with real/prospective users

We quickly iterate the form based on what is learned, gradually making updates and improvements whilst adding support for more of the scenarios outlined in the service map.

Testing and feedback from union stakeholders

Appropriate union stakeholders are asked to take the new form through various scenarios and test it for correctness and accuracy:

• Are the questions appropriately phrased?
• Are the right questions asked in various scenarios?
• Is supporting content and hint text accurate?
• Are eligibility rules correctly applied?
• Are membership rates correctly calculated?
• Are the member records being created in the CRM as expected?

Moderated usability testing with real users

Moderated usability testing is where we watch participants try to complete the form whilst asking them to “think aloud” as they go to give us a sense of what they are doing, thinking and feeling.

It is important that participants are recruited from potential union members so that their interactions are realistic and based on their true experience rather than a hypothetical one.

Usability testing helps us:

• confirm users can easily complete the form unaided
• identify any potential usability issues — for example, problems with the language or ways questions are presented
• generate ideas for how to improve the form

4. Staged beta releases and final launch

At some point the form will have been iterated to the point where it is considered feature-complete and is ready for real-world testing. We always recommend carrying out a series of controlled “beta” tests where the new form is slowly introduced and tested with real traffic. This helps to confirm the system is working as expected and identifies any unforeseen edge-cases ahead of the new system permanently replacing the old form.

Once the new form is live we continue to monitor its performance and work with the union to tidy up any remaining snags that are identified.