My name’s Katherine, and I started work in the Intelligence bit of the Public Health Team in 2014. One of my first jobs that summer was to look into commissioning a website for information on local health and wellbeing needs.
Over the next two years, I wrote a lot of business cases, learned a lot about procurement processes, and missed a lot of deadlines. The one thing I didn’t do was test anything out. We’d already consulted with stakeholders in 2014 – why would we need to talk to them again before we’d commissioned a website for them to test?
Then, at the start of 2017, we met with Matthew. Great, he said, I like your idea – now try it.
The Intelligence bit of the Public Health Team has four members. We don’t build websites. We can whip you up a lovely infographic about vaccinations (good) or smoking (not good), and if you stand still near us long enough we’ll probably explain some statistics to you, but we don’t build websites.
We built a website.
We decided on the least possible amount of content we could put on the website to make it worth testing. We decided on the most important basic things that the website needed to do in order to be worth having. And then, using free online tools and a couple of half hour tutorials in Matthew’s office, we put it together.
In two weeks of building this simple, quick, bare bones prototype, we learned more about our idea than we had in two years of talking it through. We refined it down, discarded the bits that didn’t work, and realised that we’d been making life needlessly complicated. We can now use free tools for things we thought we’d have to spend half our budget on.
Over the next few weeks, we tested it out with actual humans. We asked them to do things on the website, and got them to talk us through the process. Pretty quickly, we learned a second thing: What people want out of this kind of website is several simple ways to search for content, not one super whizzy way.
From this, we learned the difference between what stakeholders may say they want and what they actually want. We understood better how people will use our website, and what will make them abandon it. We now have a clear idea of what we want the site to look like and do – which will save us time and money when we bring in an external designer.
At Hackney we are constantly working to improve the way we support our colleagues. Over the last couple of years we’ve been changing the way our users contact us and now the majority of calls are logged online, rather than over the phone.
This has provided our support teams with the opportunity to innovate and look at new ways that we can interact with our users – making our support more personal and responsive. We started this with drop-in support workshops, where users could speak with people from across ICT and get advice and support. And we’ve now extended on that, holding regular ‘pop up’ clinics at buildings across the Council’s campus on a weekly basis, providing support and advice as well as quickly swapping out basic equipment which users might not have had time to report to us as faulty. In the last few weeks we’ve also started to offer bookable appointments, making it possible for users to book a 15 minute slot to speak with one of our team to get help with issues they’re having or to ask for general advice on the systems they use.
These changes have proven to be very popular with our users and we’re now looking to expand these services to include more specialised advice and support from other support teams across the ICT team.
We have found that this more personal approach not only benefits our users but also gives our staff a better understanding of the daily challenges faced by users across the Council’s services. Another benefit is giving more variety to the work our support teams do and regular face-to-face contact which helps broadens their knowledge and experience.
We are continuing to look for interesting ways that we can further improve the support we provide for our colleagues, and are now looking at introducing web chat and mobile-friendly access to our service as our next developments. We’d love to hear from support teams elsewhere to hear your ideas and see whether we could look to include those in our future changes. Do please get in touch!
Hi, I’m David Swainston from the Business Solutions team and I wanted to give a following up on the work we did over the last month to create a prototype for a digital end to end service for Housing.
Here’s what we learnt over the 2 fortnightly ‘sprints’ in which we built Housing Helper – a chatbot for tenants and leaseholders.
Be guided by the needs of the end user first: as part of the Agile methodology, this was an opportunity to let our end user needs from the discovery phase inform the basis of our requirements. Traditionally, we would gather a whole raft of requirements from the service area to build a large product that isn’t necessarily tailored towards the needs of the user. It was really interesting to see the relative level of simplicity of end user requirements for a service (i.e. only what users really need), compared to the larger scope and scale of requirements we usually gather and work to. Obviously this can be dependent on the type of service/project being worked on – but we felt this is particularly relevant when it comes to designing public facing digital services
Look at existing products and services for design inspiration: as part of the design we looked at various existing consumer based digital services and products currently out there and widely used. These included Banking apps, Messenger interfaces, web chat interfaces and SMS to name a few. We considered the strengths of what these services offered in terms of functionality and user experience and fed this into the design of our prototype
Test with end users and let assumptions be challenged: ensure that the service you are prototyping is put in the hands of the users who will be using it. Get their perspective on things such as functionality, design, user experience and also additional user needs that may be identified and incorporated as requirements for future release sprints. Although our brief was to design a service for Housing, we learned from speaking to tenants that the service could be expanded to offer services across the organisation. We gained useful feedback on the certain design aspects, for example allowing spelling mistakes and slang to be recognised within the chatbot prototype and that the interface was easy to use
Having the right blend of technical expertise: this was really important when it came to us exploring different platforms that could support the development of the prototype. We benefited from having developers within our team who could identify and configure the cloud platform, the various API’s between different components and coding the chat bot framework. We also had a technical architect who brought the whole platform together and summarised this in a solution design canvas that enabled other members of the team and observers to understand the different components that supported the platform
Having a leader in the team/Scrum master: whilst Agile is a methodology to enable quick iteration and change, we soon found out that it is still very much a disciplined approach when it came to working through the design and release phase. It was useful to have a good leader to ensure that everybody within the team is aware of the role they have, and that release sprints are delivered in time to allow for the next iteration to begin. This is something that we can still tighten up on when applying Agile and its various forms for real projects, but as a first attempt away from the traditional Waterfall approach we didn’t do too badly!
Here’s a link to the Google Ventures channel on Youtube. We adopted the sprint methods described by GV in their videos, and the team found it really useful as a framework for our exercise to come up with the final prototype.
If there’s any questions you’d like to ask about the approach or the prototype itself, please drop me an email.
My team, Employment & Skills has been working with ICT to design a new digital service for employment and opportunities. We’d been asking for a microsite to advertise training and job opportunities and got stuck in a debate about branding. So we were intrigued when colleagues in ICT suggested taking a different approach.
We began by taking part in a collaborative workshop where we mapped the users of the service, sketched some personas and developed a vision statement for the project. We then dived into interviewing users to find out what they wanted from the service, and what they get from a large range of existing providers.
I particularly enjoyed mapping the customer journey. The ICT team gave us a template, and we found Smaply, an online tool that produced some beautiful maps. It was so much easier than working with Visio – and produced a common tool that we could all understand.
The project has moved at pace, working in fortnightly cycles. They team has been brilliant in helping us make sure the development of the website prioritises users’ needs: maximising the efficiency of the service, without overlooking or undermining the person-centred approach of which the Ways into Work team are extremely proud.
We’ve learnt the importance of prioritising what users need, understanding where technology can help us improve service delivery, whilst also enhancing our ‘individualised support’. For example, we are now looking at what parts of the service can be automated to free up Employment Advisers’ capacity for clients who might require more intense, face-to-face, support.
At our last meeting, the digital team were proud to show-off the prototype, which we are eager to test and build upon together.
This is a different way of working for all of us. We’ve spent time getting the ICT team up to speed with the service, but enjoyed working together as a team to understand what users need and how we’re going to develop the service. And it’s much more rewarding than sitting in meetings discussing the merits of a microsite.
No one likes to fail. Many do, but few set out to. Failure is particularly problematic in the public sector, because it can lead to fears that hardworking taxpayers’ money is being wasted.
Despite knowing all that, I set a small team up to fail this week. Their brief is to spend a month creating a prototype. The team will succeed if:
The service is digital end to end and delivers a viable business process
The service is so good that people prefer to use it
The service supports our other projects, but is distinct from it
The service, if developed further, would reduce dependence on our existing systems
We learn more about what our customers need from a CRM and customer portal and the time it takes us to build a service
That’s a big ask from a small team, and with just a month to do it. That’s important. We can’t set up a whole service to fail – that would be irresponsible. But a small team working for just a month can learn, and then teach, much more than a larger team working for longer. And at lower cost and lower risk.
I told the team I expected them not to achieve all of those things. They asked if I was managing expectations. I wasn’t. In fact, it’s particularly important to me that they don’t get it all right first time. I want the team to be bold. They need to aim high and make mistakes. It’s only by learning what’s wrong, that they’ll find what’s right.
The team asked me what we’ll do with the prototype. I said we’d likely put it in the bin. Whilst my fee as a motivational speaker may have fallen significantly, it was another risk worth taking. The team has spent years working to produce ‘finished products’. We previously had a simple choice between meeting deadlines and suggesting it was good enough or missing them and waiting until the product was ‘done’. That is precisely the approach that we need to change if we are to be better able to meet the needs of our residents and the aspirations of our colleagues.
The team will be able to draw on the tactics manual that we’ve pulled together, based on the experiences of Government Digital Service, 18F and Google Ventures, amongst others. And it’s work will help us understand a user-centred, Agile methodology. So the act of doing the work will be successful, regardless of the product we create, and will teach us far more in the long run than training courses. In fact, we will win whatever the outcome. So whilst I’ll be willing them on, mostly I’m crossing my fingers and giving them the space to try their best, be bold enough to get things wrong and brave enough to learn that, done right, an Agile approach can deliver enough failures to produce a more successful outcome.
Hi my name’s Cem Bulgan (pronounced Gem), I am the ICT Training officer for Hackney Council and have worked here for nearly 4 years. I started as an apprentice within HR and worked on the delivery of our elearning site, the Hackney Learning Hub. I also provided Council wide familiarisation training for the myoffice switch over from the outdated Windows XP operating system.
This is hopefully my first of many posts. The aim here is to help you better understand the tools that are either currently being used or are available to staff which will help you improve your day to day productivity.
The first one I would like to share with you is an online tool called Trello. What is Trello you ask? – Well Trello is an awesome project management tool that makes collaboration easy and even fun! “Fun” I hear you say…. stay with me on that one. It’s also a newish concept to me but has already helped me manage ‘To do’ lists and projects I’m working on.
Have you found that you create a project plan that no one references? How about that moment just before a meeting when everyone tried to update the plan at the same time? Well Trello solves these problems – and more. Here’s how.
Each project you’re working on is represented by what Trello calls a ‘Board’. A Trello board is basically a web page containing lists laid out horizontally on the page so you can get a bird’s eye view of your project. Items within the lists, can be dragged and dropped onto other lists or reordered within the lists. It’s simply a collection of work activities known as ‘cards’ that are organised into a set of different stages, called ‘lists’.
Individual cards can contain checklists, images, attachments, deadline dates, coloured labels, and discussion notes from others who share the board. You can create as many boards as you want – one for “projects”, one for “team management” and individually manage who has access to them.
You can probably see how this can come in handy. Trello cards are like sticky notes you arrange on a cork board – that is, digital sticky notes that are searchable, shareable, and come with reminders. You can also create cards via email.
Check out this short video giving a quick overview of Trello:
Using Trello in combination with other tools for super productivity
Trello also allows you to integrate information on the cards with other applications, which allows teams of people to work very efficiently. Some of these tools are Wunderlist (a task management tool) and Ganttify (a project management Gantt tool).
Good practice in this area has been achieved in social care where the original activities are prepared on Trello cards and then represented spatially as a Gantt.
Creating new Trello Cards can also automatically create new Wunderlist tasks which the team all work to and share.
Now that you have seen what Trello can do, here are a few words from Jeremy Tuck (project manager for social care) explaining how much Trello has helped him and his colleagues within Hackney.
Q1: Jeremy could you please tell me how you found out about Trello?
“The main problem I was trying to solve is trying to get the entire project team to interact with tasks in a more enjoyable, open and in a current way. Trello and Ganttify had some of the team turn into project leads in no time and (more importantly) made everyone more aware of timelines and scheduling conflicts…. which are usually the dry domain of project managers alone.”
Q2: How long have you been using Trello for your work within Hackney Council?
“For the last year. We decided to work with all these new tools. I have been working with Wunderlist (beautiful) for several years now.”
Q3: How often do you use Trello on a daily basis?
“Often when when plans need to be revised. Wunderlist is the more daily used tool.”
Q4: What single feature on Trello do you find necessary now for your day to day work?
“Dates, prioritisation and grouping of tasks – and for the entire team to see.”
Q5: What are the advantages over other project management tools?
“These tools are quick and easy. Therefore you use them for everything and don’t forget anything.”
Q6: How does it differ to more traditional project management tools?
“They are mobile, cloud-based and focused”
Q7: Did your team embrace using it? And how
“Our team meetings are run solely using Wunderlist and there’s no need for action minutes, because we update them then and there and they’re immediately updated.”
Q8: Main advantages over using something like Trello?
“Visual, especially when working with Ganttify, which means its owned more widely and not seen solely as something project managers do.”
Q9: Did you need training on it, was it intuitive?
“Very intuitive, but you need to spend time to get the best out of it, but once you do that it’s brilliant.”
Q10: Are there any other apps that link into it?
“The marriage of Trello, Wunderlist and Ganttify is a beautiful thing.”
Q11: How intuitive have you found using Trello on your mobile device?
Now you have heard the benefits of using Trello and how it can assist in your work within Hackney council, I invite you to sign up and begin to use this tool. Follow these simple steps below on how to do this.
Once you start creating boards you can add members via their emails, whether the board is private, public or for just your team. You can also invite people using a special link for each individual board.
As you heard from Jeremy Trello is also mobile compatible and can be downloaded on iOS and android devices, allowing you to update your boards on the fly.
Jeremy also mentioned some other tools called Ganttify and Wunderlist, these are also free productivity tools that work great in conjunction with Trello. I will dive into these in more detail in my next blog just to not overwhelm you all. But feel free to check them out if you like, they’re great.
Please feel free to comment below if you are already using Trello, would like to share your experience with this great free tool, or if you would like more blogs like this.
I hope you found this blog useful and informative.
Hi. I’m Seranna Ramlochan and I wanted to share with you some activity we have been undertaking this week to involve residents in the design of a new digital service that will enable our tenants and leaseholders to view their rent and service charge account details online.
Brief background: what we have done so far
We had already engaged with the relevant service areas (in this case, Leasehold Services and Rent Income & Accounting Services) to draw up a list of features that the new service will bring to residents.
We had identified the following features of the online service to be important to our tenant and leasehold residents:
• View rent/service charge account balance
• View rent/service account transactions
• Receive important account notifications
• Download account transactions statements, invoices and breakdowns
• Make a payment
We had also created some prototypes so that we could visualise the online service and its features initially to the service areas involved.
The resident workshops
What we then wanted to do was get our residents involved to have a look at the prototypes and the features of the online service. So this week we invited a number of tenants and leaseholders to resident workshops with the aim of getting an insight into whether the service and its features actually meets their needs, and discover any alternative/additional design and functional aspects of the service that could help further meet those needs based on the feedback received.
We did this by first showcasing the prototypes. Residents were guided through these by being shown the various elements of the interface’s layout; its menu’s, button placement, expansion of information boxes along with scrolling through and switching between different screens within the service. We also explained the accompanying features provided; the ability to view their current balance, recent transactions, make a payment along with downloading statements and receiving account notifications.
We then interviewed the residents to gain some background on how they typically use Council services, what are the particular barriers to using certain services and getting an understanding of their awareness and perception of the Council’s One Account. The exercise not only provided a way of validating what we had done so far, but also provided some good insight into how the service could be designed more around user-centred needs. We also got some useful suggestions on how we can support residents in using digital services going forward.
What have the resident workshops told us?
Overall feedback was positive. We learned that the service would be very useful for residents who do not wish to contact the Council for something as simple as checking their balance or most recent transactions. Leaseholders also fed back that it would provide convenience in being able to download a breakdown of works carried out to their block and estate, rather than having to contact the council to request these to be sent to them. Account notifications were also positively received, as this was thought to be useful in helping residents manage their accounts more effectively.
Other aspects of feedback included:
• Keep it plain and simple – avoid using themed backgrounds and distracting images, with a plain user interface being preferred
• Accessibility features where important – develop an interface that included resizing or zoom in/out options to help people with partial sight
• Ensure that it is secure – the One Account provides two level authentication
Residents were also keen to stress that there needs to be a commitment from the council to help residents use digital services. Suggestions included drop-in events where residents could bring their personal devices and be shown how to use the service on a 1-2-1 basis.
Residents also wanted assurance that digital channels would not be outright replacing existing customer service channels, citing restricted access to the internet for certain resident groups. So this is something we need to think about in terms of how we manage the channel shift of residents and how digital inclusion initiatives can help with this.
We will use the feedback to enhance the proposed service to meet resident needs – changes around accessibility and a plain, simple and intuitive interface will be a design principle that will be applied to the service based on the useful feedback we’ve gained from involving residents.
More broadly though, we want to build on the above activity to involve residents more closely to help shape the design of digital services going forward. This will include working with residents at earlier stages to discover the types of services they need, and involve them at a more granular level to help test prototype designs and generate ideas of how these can be designed to be accessible, simple and intuitive to use.
One of the most exciting things about joining the team in Hackney has been hearing colleagues express their interest and enthusiasm for working in new ways. We’ve got lots of ideas of what can change and how we can improve things. But as we embark on this journey, it’s important to understand why we’re doing things.
Russell Davies, the former strategy director of the Government Digital Service came to Hackney this week to talk to us about the GDS design principles. These emerged as the team started to develop its ways of working. He described them as a formulation of a culture and attitude that was already emerging, but also how they served as ‘super rules’ which weren’t “owned” by any particular department but which still required compliance (the service standard and control of the gov.uk domain were other key parts of the jigsaw).
Intriguingly, Russell also urged us to not necessarily adopt design principles, but to consider our manifesto, playbook, or new form of statement. He also regretted that they hadn’t iterated the principles after adoption.
We had a brief set of discussions at tables during the event. Whilst it would have been great to talk for longer, the time-limit perhaps created the sense that we were starting a conversation. As we are on multiple sites, we’re doing that virtually, in the first instance – for all I’d prefer to be able to visualise it in a common space, it does at least mean that you can follow our thinking.
The work will need to grow organically – but as Russell said, we also need to make sure the end product is high quality. ‘Use a designer and a copy editor’, he urged. Watch this space!
I was super-excited when I arrived in Hackney. But I was also conscious that I knew relatively little about the ICT service. In the first few weeks I met lots of colleagues who were also excited to work in ICT for the council – but few people outside who knew much about what we were doing.
In my last job, in Buckinghamshire, I blogged about our work, and ran a weekly email newsletter to talk about what we did that week and what we would do the following week. But in a bigger service, and with high profile leaders like Rob Miller, I wanted to be part of a wider conversation. If we all talked about our work, we’d capture that excitement and potentially showcase the service better as a place to work.
If we called the blog ‘digital’, it may have seemed like it was just for some parts of the team. That would’ve been a mistake: the work of the infrastructure team, for example, is critical to changing our service – making it more flexible and responsive.
We canvassed ideas for a name from the team, and then put a shortlist to our Cabinet portfolio holder: Mayor Glanville. He chose HackIT – Digital change for everyone. It was great to choose a name that captured the mentality that we’re developing (Hacktivism as a force for good) but also made a clear commitment that this isn’t technological change for the sake of it, or the responsibility of a single team, but a collective effort to deliver change for everyone.