This resource is for anyone responsible for making any grant application that includes digital costs.<\/p>\n
It covers:<\/p>\n
Discovery is a preliminary phase in any good design process. You can do it when designing a service, a funding application or even choosing new software at work. <\/p>\n
Discovery is a structured process. It involves learning about what\u2019s already happening in a defined area of concern or interest (for example, people you want to support or your staff’s digital skills). It seeks to understand problems, challenges and common themes. It does this by exploring people\u2019s wants, needs, behaviours and habits. Discovery requires you to have a clear objective or research questions, though you can iterate these as you learn more. <\/p>\n
You could apply the process to core, internal infrastructure situations at work, for example:<\/p>\n
You can also apply the process to service delivery situations at work, for example:<\/p>\n
As an attitude, discovery is about:<\/p>\n
Discovery is also the start of a journey. It is not a standalone event you do only to get funding. <\/p>\n
Running a discovery process before writing any funding proposal for digital costs is good because it:<\/p>\n
Internal discovery activities for core funding bids. <\/p>\n
Make sense of your existing digital infrastructure. Run an audit of what tools you use and who you pay digital costs to. Look for gaps and duplication too. Use Dot Project\u2019s tech audit tool<\/a>. <\/p>\n Start by talking to whoever manages your finances and software licences. Then think about any other tools that your people enter data into. <\/p>\n You might feel relieved to see all the digital tools you use written down in one place. Even if it looks complicated, you are now more aware of your priorities. <\/p>\n Digital isn\u2019t only about opportunities. Not using digital tools or processes can create organisational risks, for example:<\/p>\n Framing the risks of not spending on digital is a way of showing how digital supports good governance. <\/p>\n “Understanding risk is important. Compliance and governance are key for funders” <\/em>– Annie Legge, Dot Project<\/p><\/blockquote>\n List your relationships with external parties who provide digital support. For each one ask:<\/p>\n Use the tech audit tool<\/a> to help you.<\/p>\n Your staff use digital tools so you should find out about their experience. Interview them and ask about the challenges they experience and the work arounds they use. Find out where they are both innovating and resisting using tools.<\/p>\n This will help you build a picture of their pain points – things they struggle with. This could be due to skill deficits, poor software or other factors. Only they can tell you about these things.<\/p>\n When you talk to them it’s best to do it 1-to-1 to reduce the bias that focus groups create. Running interviews with your staff as users of technology is the same as running user interviews with the people you support<\/a>.<\/p>\n Internal and external discovery activities for hybrid and digital-first services<\/a>.<\/p>\n Your proposal needs to show that you understand who will use your service, and why they need to use it digitally. The best way to do this is to run 1-1 user interviews with those people. <\/p>\n Interviews will help you:<\/p>\n Learn how to run user interviews<\/a>.<\/p>\n If you can\u2019t get support to run interviews, or have to use a more traditional approach, then it is still possible to get insights from focus groups<\/a>.<\/p>\n Once you’ve completed your interviews you can create a journey map for an existing journey<\/a> or a potential future journey<\/a>. These help you understand the flow of a whole service, including how digital and human interactions work together or crossover, from the person using the service\u2019s perspective. <\/p>\n Making a journey map is useful for many situations, for example:<\/p>\n A journey map helps you see the different channels they might use. <\/p>\n Read our guides to journey mapping or start with a group of post-its. Involve the people you support in a journey map workshop if you can. You might also involve frontline staff who can offer insight into where a journey needs improving, but lack the technical knowledge of how. You can even make a journey map of their experience, if useful.<\/p>\n You should interview staff who run the service too. Use the same approach as when interviewing the people you support. <\/p>\n Find out what they need to deliver the service. Examples of needs include:<\/p>\n Again, talk to them 1-to-1 to reduce group bias. <\/p>\n If your service is digital-first, or even hybrid it’s likely that some people will be excluded from using it. Map these potential consequences and consider how you might make it work for them too. You can do this by doing more discovery and risk analysis. <\/p>\n If you don\u2019t do this then you could end up with a badly designed service that makes something harder for people or reduces their trust. <\/p>\n It’s also good to identify which groups you are comfortable to exclude. This may seem counter to the concept of inclusive design, however it helps to set the scope. For example, some digital services are comfortable excluding toddlers and young children due to cognitive barriers like reading. However, they don’t wish to accidentally exclude users who face similar barriers due to English being a second language<\/p>\n Before you apply this article\u2019s advice, get clear on the 3 types of funding for digital costs<\/a>.<\/p>\n You might also want to use some of these 9 tips on how to make your organisation more attractive for digital funding<\/a>.<\/p>\n Get more help with our latest resources on applying for funding for digital costs. <\/a><\/p>\n \u200d<\/p>\n Thanks to Annie Legge of <\/em>Dot Project<\/em><\/a> for their big contribution to this article.<\/em><\/p>\n \u200d<\/p>\n —<\/p>\n \u200d<\/p>\n2. Assess current risks<\/strong><\/h3>\n
\n
3. Review external partnerships and internal skills<\/strong><\/h3>\n
\n
4. Interview your staff as technology users<\/strong><\/h3>\n
Running a discovery process for applications that include digital service costs<\/strong><\/h2>\n
1. Interview the people you support<\/strong><\/h3>\n
\n
2. Map people’s service journeys<\/strong><\/h3>\n
\n
3. Interview staff<\/strong><\/h3>\n
\n
4. Be strategic – identify who is excluded<\/strong><\/h3>\n
Further information<\/strong><\/h2>\n