People first: managers are users too!

I thought I would share some learning from the Income Collection Service transformation project which seeks to build a new service to improve how Hackney collects arrears owed.

What did we learn this week?
In our most recent project review (retrospective), the project team took a moment to ask how we were doing against the HACKIT Manifesto . We decided we weren’t doing enough to engage the ‘wider team’ (i.e. including our stakeholders). As it turned out, the Income Collection Team Managers agreed.

[Warning: jargon] Experienced lean UX-ers and agil-ers only
When we are experienced at working in modern agile teams, its easy to brush over how quickly our colleagues can learn our process. Despite how many times we may explain it, it only becomes alive when someone participates and feels the benefit. It’s easy to forget to bring people along with your work when you are under a lot of time pressure to get things done. As it turned out, despite being through a 4-week DISCOVERY that was faithful to our process, the feedback was that we had not done enough to engage the Income Collection Team Managers. They didn’t yet trust us or our approach! {Shock}.

Single-minded focus on users
During DISCOVERY there is a lot we need to learn and do in a short period of time. As with most user-centred design approaches, the team was focused on understanding our users as quickly as possible. However, this meant we prioritised talking to income collection caseworkers and residents over team managers in the first 4 weeks of our project. While user-centred service design is crucial to our success, we had mistakenly de-prioritised our engagement with the managers of case workers who we realised later were a group of users in their own right.

Smell of success
The hallmark of success (and central to our manifesto) is recognising our failure quickly and doing something to correct our course. What we were most glad about was that our stakeholders were sufficiently enough engaged to actually tell us they were not happy.

A little less talk, a little more action…satisfaction guaranteed…
As though perfectly on cue, the same week we recognised the oversight, we started to work on paper design prototypes of the new service screens. Whereas we may have previously focused on workshopping those prototypes directly with caseworkers, the team agreed we should immediately validate the prototypes with Income Collection Managers, as well. As soon as they saw what we were planning (what was in our collective heads), our relationship completely changed. Within a day and with a small pivot, we had changed the culture of the project.

Show-and-tells are not enough
We have now agreed with Income Collection Managers to reserve an open weekly ‘working session’ for an hour around the HSC 4th floor ICT standing tables. This helps us optimise our time together and we can use the session for anything from user testing to workshopping the arrears prediction algorithm to demonstrating what we are currently building for immediate feedback. The Income Collection Team Managers are also happy they have a weekly touch point with us outside the show-and-tell.

We have also agreed with the Income Collection Managers on a nominated group of case-workers who they can keep in touch with and who we can engage in the regular weekly session. This was so crucial to us because we know user testing is vital to ensure we are building the ‘right thing’.

The manifesto is alive!
We have immediately felt the benefit of holding ourselves accountable to the HACKIT Manifesto with a practical check-in during our retrospective. Maybe it was a little hard to admit we weren’t putting a key group of stakeholders the centre of our process (people first!), but we have definitely felt the benefit of making changes so we do.


Standing on the shoulders of giants

Hackney Council is prototyping an API-centric digital architecture.  The HackIT manifesto tells us to ‘learn more’ by  it was important for us to learn from experts who has successfully implemented a WebAPI in a government environment on a larger scale.  So HMRC was the best candidate to visit and provide our developers with a unique opportunity to learn from the experts.

The visit to the HMRC office, based at Shipley was really useful and gave us a deep understanding of how they implemented and maintain their API platform.  The team took us through their development journey for their API platform and provided us with insightful information to support us on our journey.

The journey of the API-centric development at HMRC has started in January 2015 with the involvement of 3 teams initially.  After 4 months of recruiting people with the right skills, they have started their API development, taking 2 years to publish the first public APIs. The most requested API was from taxpayers for self-assessment module. The team had SMEs and contract developers to deliver the first set of APIs and gradually the team expanded based on user needs.

Key things learned from this visit:

  1.     Overall Technical Architecture: HMRC has an in-house developed application which monitors the ongoing management of subscription, authentication, authorization and metrics processing for requests coming via client requests. In retrospect, they mentioned that it would have been better to go with the external vendor instead of building the in-house application which resulted in additional efforts to support it. However, they also explained the reason for using this approach to avoid vendor lock-in. Adopting a similar strategy would be very beneficial for Hackney to be able to monitor and maintain the WebAPI efficiently.  They also use multiple level of abstractions in their infrastructure, such as proxy servers, gateways etc in order to make the API secure.Most of their infrastructure is hosted on AWS.

This inspires us to revisit our API architecture and create layers of abstraction before deploying our API public so that it is not subjected to vulnerabilities.  It also prompts us to begin thinking about how we can host our API platform in the cloud. There will be some challenges around connectivity to our back-office systems, but products such as Direct Connect offered by AWS do give evidence that this hybrid platform is a viable solution.

It is also noted that they follow the DevOps approach for service delivery whereby one or two infrastructure staff are included in development teams for API delivery. This is a brilliant concept of having a platform team heavily involved in the Continuous integration of the WebAPI.

  1.     Product management and understanding user needs:

Even though they develop APIs, they still follow a user-centered approach for development, where the client developers are considered to be their users.  This extends their API-First approach where the endpoints are developed to meet user needs and not around the workings of back-office systems.

This approach makes us think “are we going in  the right direction when it comes to WebAPI?”. We believe, adopting a similar “API First” approach where we develop our end-points to the users (developers) would be beneficial to create a flexible, standardized WebAPI.

They have design clinics every month for introducing and discussing design principles and they often hold Hackathons, inviting external developers to work with their API as part of their user research. This is something we are currently doing as part of Show and Tells however we can expand this on a wider scale by inviting external agencies who are interested in our Web API.

  1.     Skills and Capabilities: Any skills not available internally are outsourced.  These skills are then introduced and shared within and among teams; this way skills are retained. As mentioned earlier there was a sense of having clear standards set up and it was embedded within the team by having the same taxonomy followed throughout.  We have adopted a similar approach of working with external companies but could do more around the transfer of knowledge and skills, possibly by highlighting key new skills in project retrospectives.
  2.     API Service Standards: They also mentioned that they are building their own API standards which based on GDS standards. The standards have been gone through a well-thought process with a lot of scrutiny in place and consultation with various teams including Technical architects and Enterprise architects. There is a separate team for API Standards and Assurance who is responsible to review the changes in the API and also make sure it follows the standards they have set in. This well embedded process itself is something we are lacking on. We are currently working on our own Hackney Development Standards which will ensure that same taxonomy is followed throughout our API and new developers coming on board can easily understand it.

In all, it was truly a well-spent day with HMRC API team with so much to take on board since they have a massive API implementation. We did realize that it would have added even more value if we were to invite our platform colleagues along with us to get more information on their infrastructure; maybe next time.


Assessing a service against the Standard

We’ve just launched a private beta of a new service with a small pilot team. The service will enable our neighbourhood housing officers to work in a more mobile way. So now seemed a good time to do an internal assessment of how well our design and development of the service measured up against the local government digital service standard.

To do this we worked in groups of 3 or 4 with a mixture of roles: UX researchers and designers, developers, and project management roles. Some were involved in the development of the new service and others were not. Each group assessed different points of the standard and then we came together with the Head of Digital to share our assessment.

What we found

Working as an Agile multidisciplinary team with a product owner who’s able to make decisions and prioritise user stories, has enabled us to iteratively improve the product based on user needs from our user research and feedback from testing with users.

Rotating ‘show and tells’ at the users’ local offices has helped build the profile of the product and contributed to users understanding of it before the launch of private beta with a pilot team. This has contributed to the building of a simple and intuitive product and reduced training time to use it. User feedback suggests it is a clear improvement on their previous mobile working tools and the pilot team are engaged and eager to use it.

Our developers have a clear understanding of the tools and systems they use, they’ve reused existing components where possible and made code available for others through Github as well as meeting internal standards on data management.

The new product provides improved data capturing, more monitoring capability and improvements on data security than previously.

However, we need to show greater clarity on how the the product has been iterated based on user research findings and no specific research has been done on assisted digital user needs.

On project management, risks need to be identified and reported more clearly and user stories need to have defined acceptance criteria that can assist the product owner in signing off the product.

Some constraints with the technology platform have been found which are hindering providing the experience that the users might expect. While security meets acceptable standards more rigorous testing needs to be done. In addition, more automated testing tools could be used to ensure the product works well in different environments.

Our next steps

We will continue to review where we are against the standard and where we need to improve our working practices. We also need to do an accessibility review, a privacy impact assessment and ensure good standards are part of future developments.

We need to plan for ongoing user research to continue to improve the product, develop performance indicators and monitor user uptake and satisfaction with the product.

We also need to share findings about the technical platform used and create design patterns that could be reused.

Our business continuity and communications plans need to be developed and use made of the Council’s existing process if the product is unavailable. We also need to find a way to involve our Council Members in the work that’s been done.

Doing an internal assessment now has provided us with additional guidance in designing and developing a user-centred service.


Holding a great show and tell

We’ve been running show and tells for nearly a year, and in that time we’ve run 57 by my count, across 7 different services. That’s enough to have a model about what makes a great show and tell. Here’s what we’ve learnt:

1. Names don’t matter
Some people read ‘show and tell’ in their diary and don’t know what it is and assume it can’t be important. We put people first, so if ‘show and tell’ doesn’t work, we can call it ‘project update’ or ‘workshop’, ‘knowledge share’ or even ‘project board’.

2. Timing does
The optimal show and tell lasts half an hour. If attendees want it to last longer, it can continue. But we should prepare about 15 minutes content.

3. Venue
Make it easy for people to get there. Ideally, allow people to find out about it as it starts. Make it inclusive. Show and tells in meeting rooms don’t get noticed.

4. How to begin
The beginning of the event needs four things:
A welcome – it’s just polite
Thank you for coming – a show and tell is only valuable if people turn-up
The vision for the project – show and tells grow so often people are hearing it for the first time. Remind people what we’re trying to achieve.
The purpose of the event – a good show and tell will repeat back to people what they already know. You need to explain that’s for them to check we’ve listened and learnt, and identify any outliers or gaps.

5. The structure
There are two main parts to a show and tell: what we’ve done, what we will do. For some groups, we will need to create a third for their questions – but ideally the feedback has already started.

6. The presentation
Everyone has a role. A good show and tell is a team presenting its work. Everyone should have a role in explaining part of the story.

Show the product, don’t talk about the process.

Less jargon. Do people really need to hear ‘sprint’ rather than ‘fortnight’?

Remember to talk about us, our, we and team. Colleagues aren’t ‘them’, ‘the users’ or ‘officers’.

7. The message
Most listeners will remember 2-3 key points, and little more. Know what you want to say before you write a word on a slide. Have prompts ready to stimulate discussion, should you not get much feedback.

8. The deck
A slide deck is useful for people who couldn’t attend, and starts to collect valuable assets for your Service Standard assessments (screen grabs, personas).

Most rooms have a screen big enough for 10 words or part of a screen. Prepare lots of slides rather than one slide with lots of content.

9. Preparation
A show and tell is an important presentation, often to senior leaders. Practice – at least once, preferably as a team. Get a second pair of eyes on your presentation. Know how the projector works.

Prepare your attendees. Email them to remind them that you’re looking forward to seeing them. Explain that you’ll start on time because there’s a lot to cover. Remind them their input is important. Tell them biscuits (fruit?) will be provided

10. Plan B
Presentations go wrong. Plan B might be huddling around an iPad. Maybe the attendees get out their phones and open a URL. Don’t spend their time waiting for you to make the computer work.

11. Feedback
Capture feedback – ideally visibly. Write it on a post-it and put it on the wall. Don’t just nod. Get people to write their own thoughts – for example, annotate drawings. Feedback matters – so show it.

12. Thank you
Thank people for coming. Remind them that their input will make a better product. Remind them you’ll be back in a fortnight.

13. Learn
Retrospectives are for another blogpost, but should always happen after a show and tell. Reflect on what you’ve done and what you’ve learnt. Re-plan what needs to happen next. If the next fortnight looks as you anticipated the previous fortnight, you haven’t learnt enough.

By the end the year we’ll have passed 100 show and tells, and will have a more developed model. But in the meantime, if you follow this, you’ll learn more.

Working with suppliers to develop better digital services

Some of the best work we’ve done in the last year has been in partnership with our suppliers. In Hackney we’re particularly fortunate to have some of the world’s best digital agencies on our doorstep, many of whom have been helping us explore opportunities to redesign the Council’s services.

Whilst there’s an expectation that suppliers will work hard to fit in with our needs, we can produce better work at lower cost if we’re good to work with. We’ve been advertising tenders for individual pieces of work on the government’s Digital Marketplace which is a transparent and fair process, through which it now takes a couple of weeks to purchase a service, rather than traditional procurement exercises that run for months.

We invited a group, comprising leaders of agencies with which we’ve worked, to help us explore five questions. How might we:

  • Reveal our core challenges / opportunities and digital pipeline so that agencies can identify emerging opportunities to do business with Hackney?
  • Procure for user needs whilst enabling suppliers to build capacity to support us and plan resourcing?
  • Work in collaboration with agencies to get the most out of the skills they have to offer?
  • Ensure we develop long term expertise amongst colleagues, whilst remain focused on immediate delivery?
  • Identify emerging opportunities that we don’t yet know we need?

We learned four key things that can help us work better:

Think aloud

It’s important for us to think aloud, at an early stage of our thought process, so that suppliers can understand the aims for a Council service, and therefore how an individual piece of work contributes to those aims. Thinking aloud is more transparent and efficient for all (avoiding lots of individual conversations) but it also offers the prospect to approach something differently – whether in partnership with others or building on other work.

Planning ahead

We’ve been purchasing in an ‘Agile’ way. We advertise an opportunity as soon as we’re ready to start (ie once we have the need, people and budget aligned) and aim to complete the buying process in a couple of weeks for a job that is likely to take less than three months. Agencies find out about the opportunity when it’s posted. But running any profitable client services business means staff will be deployed on fee-paying work around 85% of the time. So whether or not an agency has the capacity immediately to Hackney, or put its best team on the job, is down to chance. We need to signpost earlier, without losing our agility.

Categorising opportunities

One of the key things suppliers want to know, is why we’re looking for support. Is it a non-core job that we want to get out of the way, something of strategic significance, or a small but innovative exploration? And it would also be useful for them to know how confident we are in the work. Have we set our technology direction, or are we open to new ideas? Are the people they’ll be working with seasoned digital practitioners, or are they still learning how to work in new ways? This will help them understand what resources to invest and what we’re trying to achieve.

Sizing jobs

We’ve been advertising for individual phases of work (typically, discovery, building a prototype, expanding into beta, then building a live service). These jobs are relatively small, especially at the discovery and prototype stages, and the costs of bidding are relatively high. Stuff that’s been working in the initial stages then has to stop mid-flight for procurement. We need to look at how we might tender for bigger opportunities so that we get a more seamless delivery, but we also need to make sure that we don’t make our projects so big they exclude smaller vendors or lose the ability to ‘fail fast’ where that’s the right thing to do.


Our goal is to work with high quality suppliers through which we support local businesses and residents in employment, to build better services for residents. We’ve made a good start, and listening to our suppliers’ perspectives has helped to give us a clear focus for where we should focus to improve further. Over the next couple of months we’ll be experimenting with different approaches to address these issues and then making the ideas that work, core to our approach.

Friday 1st December episode 7: We’re on the sprint home straight!

Team Catch Ups: Any thoughts of demoralisation are gone, the prototypes are in fact really good and innovative. The prototypes are very important and fully underpin the event but not the main outcome. Everyone is now considering the prototypes in the context of the project brief which is to provide the following outcomes:

Three service design patterns (apply, view, comment) showing the preferred customer journey and user experiences for a digital planning service
Evidence and validation that the service design patterns meet user needs
Commitment from suppliers to build these into their roadmaps over the next 6-12 months

All back on track. Some quite major changes now required for the viewing and commenting prototype. These are mainly structural to ensure everyone understands it’s the same web module we’re demonstrating irrespective of the was it’s initiated i.e. it the same if you launch it in a library, supermarket, at home, or just passing a Planning Notification and using a smartphone. The original demo made it look like there was only a phone app and nothing else had been considered.
The submission prototype now named PAM had more than just validated the Southwark work, the extra effort the team put in on Thursday really paid off. There was still a lot to do this morning, they were busy and timings looked tight. The timetable changed slightly to accommodate their extra design time in the morning with some early afternoon interview testing lined up.

Beavering away. Both teams were off finalising their designs. So I took the opportunity to discuss the View &~ Comment prototype with Dennis from Southwark. We are on the right path with this as Community Engagement is still very low for the younger demographic i.e. people aged less than 35. It turns out a lot of comments actually come from a people representing a group of people basically several people will discuss an application with a group of friends down the pub, or at community event or in a Facebook group set up to discuss all concerns on their street! The main thing we agreed on was to take this forward was to get a critical mass of like minded Local Authorities (Planners and Digital reps) with enough impetus and resource to club together and take this forward. Pretty much what the Evening show & tell is on Monday 11th

More Interview Testing. The PAM team held their interview testing sessions and had really good feedback. The feedback at this late stage gave the team more food for thought and the extra work needed to consider and update the prototype with time already short. Watching them you physically see the pressure they were under, but there was no procrastinating, decision, decison, decision then deigning again. A slightly shorter lunch to give us all time to prepare for more the prototypes and presentations. The seaweed looking pickled kale was okay, but I’m going to miss that quiche!

Although the submissions team were slightly behind schedule and the view \ comment , you could see both designers working full on. Presentations were now taking shape. Except hands up for volunteers a deftly silence!

Presentations: The presentations looked like starting later and later. The pressure on everyone to be ready on time was intense. I’m really glad the show & tell event was moved to the 11th, Imagine having to now present straight to the large crowd of important people this early! At the final moment we were all ready for aout short presentations and prototype demonstrations – it all came together. The prototypes looked good, the presentations got their points across and they finished spot on 5pm. There were hardly any questions at the end, I’m unsure if it’s because we’ve had so many reviews, improvement iterations and basically most have already seen them to some extend. Or could it be the next point on the agenda was the pub!

Finding the Pub. After saying some thank-yous and goodbyes, we took a scenic route to the pub, we were slightly lost and started asking for directions – we may have come across a little desperate for a drink! We all sat down with a happy sigh of relief All knowing we can have a rest for now….

Next week, presentations to finalise for the big event!

Friday 1st December
Goal for the day: Expert review and preparation of final presentation

9:00 Before final day starts proper:
Amends to prototypes as needed
FCC people only
Recap and plan for the day
Start for external members of core team
10:30 Finalising prototypes together
FCC people to present their amends made earlier
Collaboratively do finishing touches
Discuss work and process
11-11:45 Testing 1 – Dennis / Southwark
12:00 Lunch
13:00-13:45 Testing 2 – FCC person
14:00-14:45 Testing 3 – Matt / Hackney
14:30 Coffee break
14:45 Create presentation for Monday 11th
Create presentation outlining process and final concept
Finalise wireframes
Decide who is presenting
1 hour presentation
Divide and conquer…!
16.30 Final retrospective
Ask for group feedback on week process and outcome
16.45 Pub?

Thursday 30th episode 6: We have a prototype to present

Sticky Tabs Consolidation – Another lovely start to the day many many more sticky tabs to review in yet another iteration for improvements. As well as many of the functional and cosmetic changes, the biggest area of feedback could all be resolved by showing the prototype in context. The prototype starts at the point the user has identified a building with Planning permissions. Therefore any time it’s shown we need to be emphasising the input points to this process i.e. walking past a site and pointing a smartphone, a link from the Local Authority website, a link from council correspondence, possibly a scanned QR code (don’t shoot me for this) or even a display in a high footfall area such as a library, school, hospitals supermarkets etc.

Changing my Focus to Project X (temporarily). The design team were on a roll with the changes so I had a chance to catch up with the Planning Policy Manager at Southwark as they’re really trying to progress the digital programme for Planning with their Project X. They’ve done an awful lot of document digitalisation and have all the buildings in the borough 3d imaged. Any larger developments submitted to Southwark must now comply with their new digital 3d standard and the 3d components need to be available as part of the Planning process. In fact the developments are reviewed in Augmented reality in the Southwark Planning Committee meetings, heads sets and all, so it’s essential!

Are the prototypes coming up to scratch? As we know coming into this sprint process there’s a huge amount of work already done in this area. However, it’s been completely at different levels across the board and quite different depending on which back end Planning supplier has been involved. Also as we know the pace has been very slow and the Planning Portal doesn’t appear to have taken these popular requirements into consideration or at least delivered them yet. The sprint teams have now been questioning their work and comparing against the work previously done separately in Camden and Southwark. The conclusion is there’s a major overlap on the submission prototype. The plan is for them to now take the next step forward based on their current work.

Back to the testing. The technology was a little rough and ready but enabled us to watch and listen to the tester giving the prototype a runthrough from a different room and take even more notes! Fortunately the second tester had a major overlap with the first but still raising a significant amount questions and good suggestions. The third and finals tester found several more items to which we could note, by this time it was quite noticeable the amount of repeated comments. Surprisingly some comments from testers were quite contradictory surprising, but at the end of each testing session we had the opportunity to ask the tester some questions so we could clarify any misunderstandings. The 101 sticky tabs way of working is good but some times the context of the comment was lost hence extra questions.

Trivial naming of each prototype actually caused quite a bit of confusion, we had chosen PAM (Planning Application Mentor), this was a mistake as we originally intended the ‘M’ to be Monitor but in the hustle and bustle of the day we forgot.

PAM unsurprisingly led them to believe the Community Engagement module would guide them through the process, which wasn’t good for the viewing and commenting prototype but excellent for the submission prototype. The other team then liberated the name from us! PAM was supposed to be the avatar for any bots we wanted to use or voice control equivalent of Siri and Alexa but for Planning Applications. If we make it to market with the prototype we’d no doubt only want a single Avatar for the whole system rather than a name for each of the prototypes \ modules. In fact we could have a family of avatars for each council service!

We finished the day a little later than expected but broke the back of the notes consolidation to give us a good start on the prototype in the morning.

Nobody likes to rock the boat. With the focus solely on the prototype some of the team are understandably now questioning the quality and how innovative the prototype actually is, especially when compared to the high standards set for normal work they’d intend to present for business as usual work. Somewhat losing focus of the brief has started demotivating some of the group. Nevermind that what we’ve achieved in a few days is an achievement in itself and even more so by validating the previous work carried out. Where the team have got to now, is much less significant than:
A) The value derived from the analysis of the challenge and
B) The fact that we’ve built a common understanding and impetus around what needs to change.

We’re planning to discuss this tomorrow….

Thursday 30th November – Testing with real users
Goal for the day: Reiterating and testing of the prototypes with real users
Agenda Item
09.30 Continue with wireframes
12.30 Lunch
13:30 Active testing session 1
13:30 – 14:15 Citizen planner (confirmed) – Active tester
14:15-14:30 Group discussion
Aisling to stay in room to watch live stream with core team, Anja to carry out active testing in separate room
14:30 Active testing session 2
14.30 -15:15 Planner (not part of the core team)
15:15 -15:30 Group discussion
Aisling to stay in room to watch live stream with core team, Anja to carry out active testing in separate room
15.30 Active testing session 3
15.30 -16:15 Planner (not part of the core team)
16:15 -16:30 Group discussion
Aisling to stay in room to watch live stream with core team, Anja to carry out active testing in separate room
Discussion of testing results
Working session with coffee and biscuits
17:15 Thursday session close

Day 3: Building a prototype

10am is a nice leisurely start, being an early bird it’s giving me the time to keep the business as usual activities ticking over and stop the emails from getting out of hand. It’s also good to start the day with a recap of the previous, especially the HMWs (how might we). This time we started discussing the personas most relevant to our chosen process and how they would really like to interact.

Wireframing was a good discussion and the jotting down of more even notes on the way to drawing some actual picture of what the the prototype should start to look like. This stage was really about iterating each step until we all reached a consensus. Once we had some consensus the wireframe sketches were started. After more and more discussion and re-iterations the mock up sketches were sufficiently detailed and ready for the designer and tech expert to run with.

Balsamiq was the prototyping tool of choice for our team working on our prototype. The designers went off on their way, but as a team of four, two of us started work on Friday’s presentation, the precursor to the Big Show & Tell session on Monday 11th December.

The pace of work is intense everyone is fully concentrating on each task and at intervals we re-convened to clarify any inconsistencies and unclear points. I have no idea what tool the other team chose, I think it was due to Vanessa (UI \ UX designer) using the existing Camden tools.

A quick run through and we were ready for a live prototype demonstration with FCC experts whom hadn’t been involved to date. With their fresh views there were again many more comments to take into consideration. We did find out that QR codes are like Marmite, they really divide opinion. Technically they’re great for linking information (massive in China) but on the other hand as they need an app to be used, nowadays hardly anyone uses them.This time the feedback was more than influencing the content but being specific about what worked and what didn’t and apparently a lot didn’t. Our prototype demo had to start somewhere and we chose someone using a smartphone and viewing a Planning site as they walked past. This didn’t set the context correctly and therefore raised many questions about it being on a phone and what about other options i.e the QR codes, links from correspondence and all other initiation routes which we had considered. The demonstration was also in front of the whole core team (anyone not involved in wireframing) therefore this time round there were many many more sticky tabs to review in yet another iteration for tomorrow!

Wednesday 29th November – Wireframing and prototyping

Goal for the day: Reminding ourselves who we are designing for, start of wireframing/prototyping session


Agenda Item

Additional notes


Coffees and networking


Presentation/plan for the day

•Recap, especially the HMW


Recap personas

•Teams to look again at the persona they are designing the idea for

•What experience do participants want to create for the personas – Template


Wireframing session

•Teams to start creating wireframes, starting with quick sketches but potentially moving into a prototyping tool




Prototyping – Animating the wireframes 1

•Pick the right tools

•Divide and Conquer if necessary

•Stitch together

•Trial Run




Prototyping – Animating the wireframes 2

•Pick the right tools

•Divide and Conquer if necessary

•Stitch together

•Trial Run


Sharing / feedback session

•FCC team to feedback to core sprint team

•Everyone who didn’t participate in wireframing to feedback

Maybe second developer / tech person to drop in? TBD?


Retrospective: what do we know, what more do we need to know, what do we prioritise tomorrow?


Wednesday session close

Day 2: Consolidating ideas – with a way to go!

A leisurely 10am start or it would have been if I didn’t have to have two long calls explaining to interested parties, about how they’ve missed the boat for this week but can still be involved in taking this forward – not that we have a real plan as yet but just a very lot of interest. A couple of the team had last minute problems and sent a substitute, this may have been a problem but in fact turned out for the better giving a wider view. Some of the focus now on Policy with a little more movement towards the consultation and general user inclusivity was good to see. This balanced against the Development Management planners whom naturally tended to focus a little more on their case management and getting the application through the process.

The Four-Step Sketch. Now this was a strange one, an ideation session starting with:

Step one: Notes – a review of the yesterday’s work. We spent a good amount of time to reviewing in detail all the components and took note of the best bits we liked, those we thought we should pursue and those which could be expanded upon. Once we’d finished reviewing the the process map with all the sticky tabs and the consolidation of ‘How Might We’ ideas and the lighting demos we had a consolidated set of notes to build our sketches upon.

Step two: Ideas – was a private summarisation of the notes into coherent sentences with a few rough sketches done in silence for another twenty minutes.

Step three: Crazy 8s – The Crazy Eight process, crazy due to the time restriction. Only 8 minutes to write down eight of your best ideas with a mix of words and sketching. Then another 8 minutes to elaborate on our favourite idea.

Step four: Solution Sketch – the three stages of the favoured process were sketched out with corresponding plain english explanations.

Working in isolation is to ensure the the stronger characters and senior leaders don’t steamroller their ideas through. The whole process was like being back at school doing a test under pressure, no doubt compounded by the tight deadlines for each stage and handing in our papers at the end.

Critique time.

Returning from a quick break, our sketches were artistically lined up gallery style. At this point they were still anonymous, we then took 10 sticky spots and went round putting them against the part of the sketch we liked or against the title if it was generally good. Once all the sticker were gone we in effect had a heat map of good ideas. The Scrum Master gave a quick synopsis (speed critique) of each and gave the artist had chance to explain their view. We then put our big sticky spot against our most favourite single aspect a further emphasis on the heat map. The good ideas were consolidated into themes \ options to focus our prototype upon. The lesser ideas were sidelined and the main ideas consolidated.

Decisions Decisions. All the notes, demos, and sketches, pretty much a day and a halfs work was whittled down into a few key themed ideas to take forward to the prototype stage. Data, policy and tracking seemed to be cross cutting, so two lead ideas came to the forefront: Community Engagement and Submissions and Processing. We the split into two balanced groups to take these ideas into a form that could be presented – basically a magazine front page later to be used to ‘sell’ our Idea the the other team, some decision makers and some experts not involved in the day to day sprint.

First show & tell. After the idea was presented, each group would critique the others work also in attendance were some external experts @realnickperry our Hackney Planning Forum representative and @daviddurrant a Business Analyst from the GLA. as part of the feedback process we received a whole whiteboard of feedback which included what they liked, disliked and other considerations we might like to take on board. The prototypes decided by the iterative cycles and collaboration further matched the process we set out to improve i.e. Submission, Viewing and commenting. Finally a quick retrospective and run through the plan for Wednesday. And time to break for the day.

Coming next: Wed 28th episode 4: It’s actually happening – Wednesday


Detail schedule for day 2 (Tuesday)

Tuesday 28th November – Ideation and initial sketching

Goal for the day: Allow for individual ideation and sketching, deciding on the ideas that will be executed


Agenda Item



Coffees and networking


Presentation/plan for the day

•Recap, especially the HMW


The Four-Step Sketch.

•Explanation of the exercise


Group critique and unpicking through 4 approaches:

•Art museum

•Heat map

•Speed critique

•Straw poll

•Maybe later vs. winners




Decision time

•Discussion about how many ideas we want to elaborate on

•Formation of groups

Ideally this will not take the full time – but just in case…


Headlines and key info needed to convey ideas

•Planning Mag exercise for the selected projects (teamwork with UX/Service Designer)


Show & tell for the extended team

•Sharing / feedback session invite experts to critique

Opportunity for external people to drop in (remote not possible)


Retrospective: what do we know, what more do we need to know, what do we prioritise tomorrow?


Tuesday session close

Planning Design Sprint: Day 1

A commute gone wrong gave me more time to contemplate more than just the desired outcomes. There’s a real chance here to to leave a lasting legacy. As the days have progressed I’m finding more and more interest from the wider community. I’m particularly interested in how this sprint could be a new start to better ways of working for Local Authorities i.e. wider than just Planning. Could this be a seed to a better way for Local Authorities to collaborate in agile working partnerships or the standardisation of terminology and underlying data sets or finally as per normal just a good piece of work that provides the desired outcomes?

A seriously cold morning and we’ve all just about made it into the Innovation centre only to find the heatings out. Wow, we’re all seriously impressed by the layout of the sprint room, purposely designed and fitted out with the necessary tools. There’s a huge Planning process map on the wall ready and waiting for us focus our thoughts upon, narrow down the main areas to attack and most importantly to stick our stickies upon. Also don’t forget the refreshments, tea and coffee to warm up our hands, but with the cold and caffeine nobody’s falling asleep today! To lighten the mood a couple of the team were firmly reminded of the no tech during sessions i.e phone, tablets and laptops all put aside until the break.

Let’s get going. After the traditional round table introductions @Euanmills gave us a quick talk on the FCC wider objectives. We split up into teams and went through the process of reading the prepared personas all with a backstory to ensure they were representative. After presenting our personas (and a quick break) we had an in depth walkthrough of the Planning process on the wall to ensure it was as we all saw it. We all then had the chance to put the colour coded stickies onto the process map where we thought it was either missing steps, had mistakes or challenges. The session ended with another one of Anja’s honks on the bicycle horn leaving the process map looking like this:

After a nice healthy lunch and some time to deliberate over the morning’s progress it was straight back down to work. A general review of the of the now layered process map then onto the task of turning the negative issues into the more positive ‘How Might We’ statements. It did actually feel better trying to think of ways to make things better, rather than the negative trying to fix broken things. The many pain points highlighted in the morning were then categorised into themes such as; consultations, case management, guidance, submissions and document management. The lesser pain points and those deemed out of scope were dismissed and moved to the relegation zone.

A long afternoon of toil awaits. The morning and post lunch session were quite tiring and brain draining and so would have the afternoon if it weren’t for some excellent Lightning Demos – basically four demonstrations fitted into only three minutes each, of what can only be described and excellent practice rather than just best practice.

  • Consultations based upon theatrical forums, attendees attending a forum didn’t necessarily know they’ be playing a part in a consultation play!
  • The ESRI GIS package provides the ability to pick up an object (building) and drag it across the map or change its dimensions in situ and see the effect on the environment and associated linked data.
  • The FutureGov ‘Foster Carer Recruitment’ application form has been designed to be effective on the parts of the process that need data collected and isn’t trying to digitally trying to solve the whole problem
  • Better use of PDF’s and data stored within naturally feels like something we should be moving away from. However it was demonstrated as quick achievable step in the right direction worth considering as opposed to the option of waiting for a final product

A special treat: The finale of the day was for us to test ride the Virtual Reality and Augmented reality setups at the FCC. Selfishly I volunteered to go first, taking a deep breath I tried to totally immerse myself in the VR. At first taking steps was quite weird, but with the teleporting device moved easily around the top floor of the ArcelorMittal Orbit, moving from exhibit to exhibit. Each table gave view to a 3d map of the park with over a few seconds gradually built up several 3d layers of roads, street furniture, bus routes even the detail on the bus stop sign. Having a good view of the Olympic Stadium from 200ft up I sheepishly took a step of the edge – very very unnerving. Turning around to take a step back onto terra firma was even more difficult, I nearly fell as I ducked under a virtual barrier! Albeit in aid of improving the Planning process, the VR we saw could be used extensively across Public Realm if not the full council, however it will be another matter to develop and implement!

 The augmented Reality however looked considerably more achievable and had many practical application, selecting a building, verbally removing a component such as a roof to expose further detail. The roof object then became selectable, and you could verbally ask about all the detail was also the asset details, i.e. how old is it, how much did it cost etc. Even more likely to be with us very soon was the 3d Web VR in a browser.

Professional hosts. We’ve been fortunate to have Future Cities Catapult hosting the event especially with Anja and the sprint team putting a considerable amount of time into the preparation for the week, really setting the week onto a good path and keeping it all moving succinctly.

Monday’s Schedule :

Monday 27th November – Research and Inspiration
Goal for the day: Verify personas and planning journey, so that we are starting from the same base knowledge, inspiration for the ideation session on Tuesday
Schedule Agenda Item Notes
09.00 Coffees & Networking
9:30 General intro, what is a sprint, roles, tasks etc.

  • Introduction of participants (only those who haven’t met the group yet)
  • General introduction to the project (Euan)
  • Introduction to the sprint
Euan to introduce project

Anja to take everyone through the presentation

10.00 Presentation of personas

  • Team work in groups to explore the personas we created and verify them
  • Presentation of personas
Aisling to take participants through research

Verification through all participants

11.00 Coffee break In the same room
11:15 Presentation of planning journey – part 1

  • Presentation of the planning journey
  • Individual work: Identify missing steps, mistakes and challenges
  • Discussion
Aisling to take participants through research

Verification through all participants

13:15 Lunch
14:15 Presentation of planning journey – part 2

  • Discussion
Aisling to facilitate
14:45 Identification of pain points and creation of How Might We (HMW)

  • Identifying further pain points within the planning journey
  • Creation of HMW
  • Organise the HMWs by theme
  • Decision on which/ ones to focus on
16:15 Lightning Demos; Great solutions from a range of companies

  • Each participant to do a 3 minutes demo
  • Capture good big ideas and draw on the whiteboard
Set homework for participants from councils to come up with demos / inspirations to present
17:00 Retrospective: what do we know, what more do we need to know, what do we prioritise tomorrow? Anja
17:15 Session close