Using a design lab to design strategy & the problem with demonstration projects

Experimenting with Strategy design in a design lab setting

Having been asked to write a strategy I had a bit of a wild idea, rather than write a strategy, we would design a strategy in a design lab environment. Staff were actively involved in the development of the strategy. We rushed through six design lab sessions that were no longer the four hours, per lab session. This wasn’t easy but we worked with the minimum time staff were allowed to be away from their day job to contribute to the digital strategy. No matter what process you are going to run, you will always have constraints.

It wasn’t ideal, it would have been better to have had staff attending lab sessions for a full day and to run more than six sessions, but we took the time we had and worked with that, to our advantage. From service design purists I often here, but what about the process? We should always strive to run a human centred design process or an agile process in its entirety but with the newness of these methodologies and a view that they are just the latest in a long line of tools and methods that have been tried before, we don’t always have that luxury.

Despite the time constraint, people were fully engaged and made the most of the design lab and provided valuable input. Because staff were so engaged with the process, they took ownership of the strategy which was an unforeseen benefit of the design lab process. The group we didn’t manage to fully engage in the design lab process was the management team. A manager signed up to the design lab but despite his best efforts to make the lab sessions, the annual business planning process hit at the same time as the design lab and rightly so, that work took priority.

Was the strategy design lab experiment successful?

I like to think so, although defining success is not always easy, ‘my view of success may be another’s failure’. I do fully believe that designing strategy in a lab environment is worthwhile. So often strategy development is the brain child of a select few which is then rolled out on-mass and can often leave people thinking, oh look another strategy, yawn! I’ve certainly written strategy like that. It’s not because I wanted to but because in a busy policy shop, with multiple priorities you do the best you can with the time you have.

I would encourage people faced with the daunting task of developing a strategy to try the design lab process. Try and get a good cross section of people involved, including managers. Have some objective participants involved that can bring fresh ideas and see a different perspective without investment in the end product. The results will surprise you.

Demonstration Projects — experimentation and failure

In the strategy there are a set of principles that are intended to guide staff in the design of services. The principle ‘enable an environment that is open to fail’ did not sit comfortably with some people, for obvious reasons, people don’t like to talk about failure. Yet we should. Until recently I felt I hadn’t had a mechanism in my work to face what isn’t working, either drop it and move on, or keep iterating with prototypes till you get it right, or close to right, then roll it out. This is the revolutionary piece in service design for me. I have spent too many years in my career working with “good ideas” but really not knowing if they are going to work but rolling with them anyway. There have been mixed results, with some successes but many ideas have missed the mark completely.

So what does this have to do with demonstration projects? We embarked on three demonstration projects with mixed success, or more to the point, mixed failure. I want to focus on one particular demonstration project, the re-design of a registration form. I don’t actually see this project as a failure but, we didn’t succeed in our intent to roll-out a re-designed registration form that was simple, easy to use and met the complex learning needs of the learner. What was successful was the opportunity to take a prototype of the re-designed registration form to a conference to test the form with service users. Often we will consult with concepts of what we want to design in a slide deck. Using a prototype of an actual form allowed a deeper dive into the look, shape and content of the form which gave detailed information that was invaluable for the design of the registration form. Other than input from a UX designer and a service designer, this was all achieved with zero technology costs, limited IT involvement or the need for major development time to build the product.

Here’s where the demonstration project run into difficultly. Currently there are a number of forms that are in PDF, are text heavy and not accessible. People struggled with the concept that we were starting with one form, ‘starting small’, and once we had that right, we would ‘scale up’. People couldn’t understand why we weren’t tackling all the forms.

Demonstration projects are just that, a demonstration, so are not seen as core business so the projects were always a low priority and there was a constant struggle to get buy-in. Although service users were fully engaged in the process.

There had been calls from service users to address the significant barriers to registration for the program, for years. The program is for people with learning disabilities, where English may be their second language so the current registration form actually stopped some people accessing a program they desperately needed. This is where the wheels really started to come off the project. From the user research, one of the significant barriers for people accessing the program are the reporting requirements and the current program eligibility criteria. A number of the questions that are asked in the current registration form are considered by service users, to be intrusive. Organisations administering the program considered a large portion of the form to be useless information, badly worded and with questions duplicated throughout the form.

With the lack of buy-in on the demonstration project the key stakeholders that should have been involved from the start, weren’t. It took months to receive the feedback on the proposed changes and the ‘window of opportunity’ to launch a re-designed registration form, was lost.

This leads to another critical factor as to why this project failed. For a true service design or agile process to be run the key actors need to be in the room, working together right from the start. Currently our structure is units branches, division, clusters etc. which makes it almost impossible, without top down direction, to get policy, program delivery, business and IT, including developers in the room, moving through a process as one team. Currently we have a policy team, a program team an IT team etc. where we all operate separately. This is no fault of the people who worked on this project but a current structure that has worked this way decades. The first step is I think an actual step backwards to think about how we can commission these projects, that sets up a structure that is conducive to a ‘people centered’ way of working. This especially relates to projects coming from grass-roots that have not been mandated from the top, down. This would mean pulling people out of their current team structure to work in a design project team. I would like to think we will get to the stage where the lines between our teams are so blurred that movement of staff and information is fluid and dependent on the work rather than a current structure.

Where to now?

Experimenting seems to have been a common theme over the last year and I don’t think we are done experimenting. The strategy, is in beta version. We have launched into a work plan to achieve the three priorities outlined in the strategy.

Part of the work plan will be to evaluate our progress on the priorities which presents us with a big question, how do we measure our progress? This question has sent us back into experimentation with different approaches to how we evaluate the impact of the strategy. Anecdotally I can say over the last year we have had an impact. People who have not previously used design tools and methodologies are now using them, but has anything changed for the end user? I think we are not even close to seeing any significant impact for the end user. We are in the midst of changing our environment to position ourselves, actively empowering employees, to be ready to boldly enable the change needed to deliver better services for the public.