Behind each of the Labs projects is a team of young people, designers, mental health professionals and voluntary sector organisations.
What unites each partnership is a shared passion and enthusiasm for making apps and websites that improve young people’s mental health. As a result of their journey each team is now much stronger and wiser for their shared experiences. This is especially true for Doc Ready who, by virtue of launching first, have had longer to reflect on their progress than the rest.
Here’s some of Doc Ready’s key learning about what makes for a successful app development team and where that differs from traditional ways of planning mental health projects.
Continuity of Team = More Care and Vision
One of the notable things about Doc Ready is that many of the people involved in its final implementation were present at its birth. During Lab 2 Doc Ready’s group was facilitated by Rupert from NeonTribe and included people from Right Here Brighton and Hove as well as myself. Its subsequent video pitch was presented by me rambling in my ramshackle northern style. In short, three of the five eventual big players in the development of Doc Ready were already stitched into the app’s history.
While this could just seem like a happy coincidence, the success of the app is a good example of what happens when people are able to stick with an idea and invest in its eventual outcome. Too often mental health projects are put into action by people distant from their original genesis. They’re just another job to be executed, rather than something which we feel love and enthusiasm for. They get handed from department to department, from professional to professional, until the idea becomes a photocopy of a photocopy of a photocopy, losing all clarity and purpose.
I feel happy that I’ve been able to stick with Doc Ready throughout its development and I’m even happier that others who’ve been involved in one way or another have been able to stay on board with the process too. Because of them the Doc Ready project has been a succession of well executed technical tasks suffused with a kind of vision and a kind of care. It’s a thing made by people who care, with the help of people who care, to be used by people we’ll never meet but who will be depending on it to work for them.
Mash Up Your Team
One vital ingredient in Doc Ready’s creation was the way in which FutureGov, Enabled by Design, Neontribe and myself were able to divide design and development tasks between us without walling off different bits of the process into their own separate domains. Each of us has been involved at every stage of the process. In this style of working (unlike in many public sector projects) there is a division of labour based on expertise, not hierarchy. The relationships are between people, not different departments. So, rather than the lead partner beavering away to develop the specification for the app which is then sent to the designers, and then on to the web developers, each of us brought our professional specialisms to every stage.
The advantages of this are twofold. Firstly, managing the project and retaining a strong vision of its values and ethos is much easier when all of the people involved in making it have been involved across its gestation. Secondly, and more importantly, it creates a dynamic situation where the makers, the stakeholders and potential end users feed in their ideas, expectations and insights. Being able to make sure that everyone can be clear about direction, practicalities and problems through actually discussing them as they occur creates a continuous development process and a structure built for problem spotting and solving.
In traditional models people are consulted, their feedback collated, processed by someone ‘in the know‘ then sent to the people actually doing the ‘clever stuff’. The people doing the clever stuff look at the already processed feedback, mull it over and then do whatever it seems to them is best in the context of the project and the constraints in which they are working.
What seldom happens is situations where those ‘doing the making’ interact directly with those feeding back the feedback. Vital for Doc Ready was the fact that not only did everyone involved with the building and content of the app work directly with young people; they also brought their own constraints to the discussion. If you are going to let people make suggestions without also providing them with the facts you’re kind of ignoring the possibility of them being real partners in the process of design. At all stages, members of the Doc Ready team discussed ideas while also making those contributing them aware of the constraints of the project.
All projects have constraints. They may be financial, technological, political, or knowledge-based. ‘Blue sky thinking’, that is thinking without taking account of constraints, is brilliant when you’re trying to come up with ideas. It’s bloody awful when you’re trying to solve problems. Doc Ready’s development involved all the people who were making it engaging with all its stakeholders. This meant we were always able to respond directly, in context, to problems, ideas and feedback as it surfaced.
This accelerated problem solving: developers and coders worked directly with those feeding in their ideas. Ideas move quickly in workshops, so having people on the spot to say ‘that idea sounds awesome but it’s double our entire budget’ or ‘I think we might solve that problem this way, do you think that’d work for you?’ made sure that all of the participants in Doc Ready’s development, whether within the core development group or outside of it, were able to stay focused and move quickly towards improving the product together.
If the ‘web design team’ is sitting in an office somewhere waiting for the ‘project management team’ to write up the feedback from the ‘project testing team’ you’ve introduced both the possibility of feedback being wrongly communicated and excluded the possibility of solutions to challenges being developed together. Both make moving quickly and decisively in the right direct slower. And, as anyone used to doing small projects knows, slower equals more expensive.
Keep Your Team on Target!
It’s vital that you always keep your eye on your end goal when developing new products and services. The goal is to produce a thing that works for people. It’s amazingly easy to get drawn off course by well meaning advice or an over developed need to try to incorporate everyone’s suggestions in the finished project.
The development of Doc Ready has been a collaborative process. Young people have been involved throughout. All four of its development partners have benefited hugely from the input, support, intellectual muscles and goodwill of Right Here Brighton and Hove. Various other people have fed in their ideas and our funders have each had ideas about what should happen.
At the centre of this there has been a strong and steely focus and a willingness to take responsibility for decisions, even when they seemed to go against external suggestion. We knew we were going to get this application built and launched as a beta. We knew it was going to work on phones and on computers. We knew that it was meant to help young people and through helping young people help GPs. In other words we were open to all ideas, input, support and help as long as it helped us to meet our goal.
It’s very easy, especially in situations where your innovation is situated between various competing interest groups -as many health or social innovations are – to find yourself being encouraged to draw your vision more in line with someone else’s objectives or to fit better into the position that others define for you. This is especially true where organisation claim to represent the interests of your intended end-users, but don’t belong to that group of people themselves.
Sometimes it’s necessary to politely listen to what someone says, weigh up its relevance and usefulness to your project’s goal and end users, and then discard it. Everyone has an opinion about what your product should be, do or look like. Not all of them are right for your project.
At every stage of Doc Ready’s development we sense checked, stopping to ask whether a new insight or piece of advice made sense both to us and to the apps’ target users. By returning back to those users needs, the people for whom the app is intended, we never lost sight of what we were doing.
If what you’re doing really is innovative, it’s going to tread on some people’s toes. If all the way through development you’ve got inside the skin of the people you’re intending to help, you’ll know what advice is right to listen to.
This is the third and final post on why Doc Ready got to where it is so quickly and what this means for the way we make mental health services. You can read the other posts at Don’t Ask Young People For Solutions and How To Make A Mental Health Service That People Like.
