These are the slides from my ‘lightning talk’ at JISC dev8D on how developers in the JISC community can communicate with a broad, non-technical audience. Given the time constraints of a packed and very interesting event, my presentation was neccessarily a little light. Whilst most of the points I make are common sense, being asked to talk about this at dev8D implies that there is still something of a communication problem between the developers of a system and it’s end-users, so it doesn’t hurt to remind ourselves of the obvious occassionally.
Slidedeck
As these slides might not make too much sense without the speakers notes, you might want to view the slides and notes in context on Slideshare or read them below…
Slide 1: I’m a little wary of sterotypes such as digital natives or the google generation and of extrapolating from these. So while preparing for this talk I scanned for some evidence that the geek sterotypes are still in common usage. Just to be clear, I consider the term geek to be a compliment. Developers do some amazing stuff that the rest of us benefit from, but only if we can understand it and use it.
Slide 2: The first ‘evidence’ I saw was a tweet on the launch of data.gov.uk. This is a resource with amazing potential to give public access to public data. However, that’s only true if the data can be made available in meaningful ways. Luckily, as hubmum put’s it, the geeks came to the rescue.
Slide 3: The next was from Tony Hirst, talking about the responsibilities of developers to make data available to the masses – or as he put it in his tweet – the mortals.
Slide 4: That idea of responsibility is why I think this is an important issue. No offense to developers, but no matter how good your new system is, it’s only as good as the uses that people put it to. So, if there is a communication problem, how can we make it better?
Slide 5: Well the first responsibility is to know your audience(s). As this is where the sterotyping starts, let me defend my position by explaining a little about what I do.
Slide 6: I’m a trainer at JISC Netskills. We provide end-user training in web technologies for 1000s of staff from the education sector each year, as well as producing training materials for institutions to do their own. As such, we work with a fair few of (what I assume to also be) your audience. So although I’m presenting anecdotal evidence, it is at least based on a relatively large sample size (even if one that may be biased by being an audience seeking training). To do this, we need to work at the interface between geeks & mortals, taking the systems and ideas of developers and translating them into something users can put into practice. That often requires us to speek both geek and mortal.
Slide 7: I should also declare that I’m part of the mortal audience. Before working in tech, I spent 10 years as a researcher working on HIV vaccines. As such I worked with some extremley intelligent and capable people. Similar sterotypes applied here regard to the problems of scientists communicating about their research with the general public. The key for both scientists and developers is to recognise the nature of their audience and adpat accordingly. So what can we say about a typical audience for systems developed for use in academia?
Slide 8: Firstly, don’t underestimate how little awareness there is of technologies that you might consider to be mainstream and well-established. Your users aren’t stupid, but tech is just a tool that they pick up to use when they need to, then put away again. They don’t see the world through the lens of technology as many developers do. RSS is a good example of this. For something so fundamental to the modern web that offers real and immediate benefits to users, surprisingly few people in the audience we work with know what it is or make use of it. They’re typically familiar with web browsers and facebook, but much less so with things like RSS, AJAX or XMPP. As for emerging services like google wave, buzz or pubsubhubbub…
Slide 9: A recent example of this was when ReadWriteWeb (RWW) introduced FB connect as a way to allow login to their commenting system. They made a post to announce this and it soon found it’s way to the top of the google SERPs for ‘facebook’. As a result, a not insignificant number of people found their way to RWW and logged in believing they were logging in to a new version of facebook.
Slide 10: That highlights that many users are disorientated by the ever-increasing rate of change in technology. When a geek looks at this ever-changing landscape they see possibilities and opportunities to do new things. When a mortal looks at it, they can often see change and increased choice as confusing. Many people prefer to take the well-trodden, familiar paths with technology, even if new systems are better. So developers need to be careful when adding new system to this already crowded space.
Slide 11: Change is never easy for people and is often met with resistance and inertia. Academia (and academics) is traditionally thought of as being slow to change and the rate of change of technology outside this world can sometimes appear to be inversely proportional to the rate of change inside it.
Slide 12: So, how ‘happy’ are your users likely to be when you present them with your new system? Well, that largely depends on how it is presented to them.
Slide 13: All too often, it’s as an uninspiring product manual or piece of documentation that tells people how to use a system, but not why. I’d argue that this approach might be necessary, but is not sufficient for people to truly understand something new.
Slide 14: What we need instead are some carrots – reasons why a system will help people, their life easier or make them more productive.
Slide 15: That needs some evangelism. Being passionate about tools, selling their benefits, motivating people to try the tools for themselves in context of own practice. An excellent resource for this is the Developer evangelists handbook. But before you get carried away, remember to check that with some pragmatism. People don’t need to know all the gory details about every tool that exists and their probably not going to use them all. They’re more likely to find a tool in time to use it and find out just enough about it to do so.
Slide 16: So, how does all that translate into communication? Well, this is a simplified version of the model we use for our training. It’s based on elements of Blooms’ taxonomy, Kolb’s experiential learning, Honey & Mumford learning styles, Ecclestone’s autonomy to name a few of the giants of educational research whose shoulders we stand on. The key point is that instruction in new technologies should focus first and foremost on the ‘why’. Without this hook, it’s unlikely that people will be motivated to find out how. So we start with some evangelism, then move onto guided practice to hopefully sow the seeds towards the transformation and pragmatism needed for true independent practice.
Slide 17: Consider starting with something akin to a quick elevator pitch. What would you tell someone about your service in 2 mins? What are the key points to communicate? How would you get them across effectively?
Slide 18: Make sure your language is appropriate to your audience and remember the principles of writing for the web, such as using plain English, an inverted pyramid structure and front-loading.
Slide 19: One of your best assets are the people ‘formerly known as the audience’. They’re the one’s use systems in anger. They will find problems you’d never thought would be problems and solutions that you’d probably never come up with. So encourage them to help each other and help you. If you listen, they’ll give you vital feedback. If you let them, they’ll help write the manual, not just read it – as well as make videos, write reviews, make suggestions…
Slide 20: Mix your media. Without veering off too much into learning styles territory, different people prefer to learn in different ways and through different media that suit those ways of learning. Consider what media would work best for your evangelism or for facilitating some guided practice. For example, many new services launch with a short video overview about the why, more than the how. Back these up with more in-depth guides, FAQs as well as forums to encourage discussion.
Slide 21: Problem is that not everyone is happy (or good at) presenting, recording podcasts, making videos, writing manuals or facilitating training.
Slide 22: So finishing on a big, shameless plug that if you need help with any of this, we can help, just ask. That’s what Netskills is here for!
Twitter
Delicious
Slideshare
JISC Netskills
LinkedIn