❓FAQ page
This page is intended to provide a bit more about the use case and background behind the playbook.
What was the ethos behind the approach?
This guidance is intended to be focused on outcomes rather than discreet tasks. We wanted to create something that provided clear guidance, whilst also allowing project teams the autonomy to make their own decisions.
We recognised that there was a lot of good content on the intranet but it was very discipline-specific. We saw an opportunity to bring all of that knowledge together in a more central place which reinforces multi-disciplinary collaboration.
Who has contributed?
Over 30+ contributors from all disciplines from within the Product Design and Build (PDB) team at Torchbox have contributed.
How is it intended to be used?
Our aim is that it will be a helpful guide for individuals and project teams. We hope that it will help to ensure we consistently deliver to the same standard and continue to deliver the best possible outcomes for our clients.
It should be seen as a useful resource to cross-reference your approach against and to help identify any blind spots. It's not intended to be an exhaustive list of things to consider in a project, or by any means a checklist.
Who is the intended audience?
Everyone within the Product Design and Build (PDB) proposition at Torchbox. We know some people will be more familiar and comfortable with our ways of working than others are. We hope this will be particularly useful for new starters or newly formed project teams to help clarify roles and responsibilities, expectations and inform project approach.
We also hope that by making this guidance open-sourced other organisations can also benefit from our years of experience.
What type of project is this based on?
We wrote this guidance with Wagtail re-platforms in mind, rather than bespoke builds. However, we think there will be useful content here for a wide range of projects. Over time we aim to build this out to provide guidance for different types of partnerships and engagements.
How strictly do I need to follow it?
We know all projects are different and sometimes certain outcomes aren’t needed. We’ve labelled each outcome as either mandatory or recommended as a guide, but we ultimately trust our project teams to make the right decisions.
We'd recommend that teams have a discussion and agree on the things they don't think apply to the project they're working on before work begins.
How can I provide feedback on it?
Please speak to the relevant working group lead or Holly Davis as playbook lead.
Delivery Management - Anna Pellicci
Product Director - Ellie Ashman
UI Designer - Ben Tuckwell
Tech - Tomasz Knapik
Content Strategist - Miles Taylor
Service Design - Maitreyee Kshirsagar
User Researcher - Cassandra Cardiff
Content Design - Stephanie Brown
Information Architect - Johnny Peacock
QA Lead - Chris Harris
Systems Engineer - Neal Todd
How are we going to measure its effectiveness?
We'll be reviewing how people are using the playbook and refining it based on feedback.
This isn’t a process document, it’s a place of shared understanding, and a toolkit for co-owners to collaborate, raise standards, evolve and ultimately deliver the best possible outcomes for our clients.
It will never be finished and it'll continue to evolve in response to feedback from our team and clients.
What if this doesn’t cover the type of project I’m working on?
Take what you can from the guidance and use it as a starting point.
If it's not useful for your project, think about how you might be able to adapt it to create new guidance for others working on similar projects in the future. This playbook is all of ours and we'd love to see new guidance being written and submitted over time.
Last updated