Digital Service Design and the Creative Technologist; tricks of the trade

One of the hats I wear as a developer at cxpartners is that of the creative technologist. The role brings both a creative input and technical knowledge to a project. In this blog post, I reveal how I created an illusion of a fully-functioning live chat application. You will also discover how we de-risk critical service design projects. It's a kind of magic, mixed with our own special ethnographic research techniques.

Can you imagine what it’s like to launch a digital product? Maybe you’ve carried out such a project?  One way is to use the classic waterfall approach. Brainstorm your ideas, get a creative agency to mock-up designs and then developers to build and test the thing. Finally, after months (or even years) of blood, sweat and tears, you launch to great fanfare. But what looks good on paper, doesn’t always work in the real world. What if you got the value proposition wrong? Any changes now will involve a lot re-work. What if you could test your ideas at a much earlier stage in the process?

To test our ideas with real people, we create prototypes at an early stage to understand what they need. We invite people to our usability test labs in Bristol, and get them to explore and think aloud how they feel using the prototype. Sometimes a sketch is enough for a test. But when we add a little bit of tech "magic" to our prototypes, our participants get the impression they are using the real thing.

This approach is known as the “Wizard of Oz”.  In the classic movie, the Wizard is exposed as an ordinary old man behind a curtain (and not a large disembodied head with a booming voice).

So, why do we use this approach? Well, because we know that we’re all human, and what we say we’d do in any given scenario isn’t always what we’d do in reality. So, the closer we get to simulating a real experience, the closer we'll get to true human nature.

We have been working with one of the UK's biggest charities, the Samaritans, this year. The Samaritans receive millions of phone calls a year from people in crisis. By giving callers time and space to talk things through, they find a way through their problems.

Suicide is the leading cause of death in young men and women aged 20-34 in the UK. Samaritans are experiencing an ever growing demand.  As most young people use instant messaging to talk to their friends, we wanted to explore this as a new way to help.

There are inherent risks with any new digital service but getting it wrong for the Samaritans could be a matter of life and death. We needed to give the Samaritans confidence in a number of areas. Would users trust such a service to maintain their anonymity, privacy and security? What if someone else entered a room and could see a users screen? Would people feel they could open up using the service or would it lose the human touch?

Our tests were going to be as realistic as possible. We had participants coming into our lab who had used Samaritans’ service in the past and real volunteers from the Samaritans to make the conversation authentic. We needed a prototype that would help a dialogue between the two and test our ideas around the anonymity, privacy and security issues.  The chat experience would need to seem seamless and reliable.

When it fell to me to create the prototype, I thought I would need to write a lot of code - there’s a lot of functionality in an instant messenger. This caused me quite the conundrum as I know that prototypes should be a quick (and dirty) way to test.  Rapid prototyping is an iterative approach - we make changes based on what we learn, and test again. So, to create something in this manner was a real head-scratcher for me!

My solution was to plug together small bits of tech. Modern cloud-based services use APIs.  (API stands for Application Programming Interface). APIs are accessible to developers and allow interaction between different systems.  As a developer, I write web-pages that talk to APIs. I knew if I could find the right combination of tech to use, then I could create our chat prototype in a short space of time.

For the prototype, I embedded a widget, from a chat service called Chatlio, into a simple HTML page.  With only a few lines of Javascript code, Chatlio’s API allowed me to style the widget to match with a background our designer came with up to complete the look.  On the other end of the line was our volunteer using Slack. Slack is an instant messaging tool we use for internal communication. Thanks to the Slack API, I could relay messages between the widget and a specific Slack channel. The conversation would seem authentic to our test subjects and they would feel that they were using a fully-fledged chat application.

Using the prototype, we were able to try out a variety of different designs. We explored ways for the users to hide their screen quickly, experimented with different copy explaining how the service would protect the users anonymity, privacy and security. The API allowed us to add interactions to the chat that explained when the volunteer was typing so the user felt connected, different buttons for actions to express when they needed time to think, and ways of recording the advice and resources the volunteers shared with the user.

Some of our ideas didn’t work. But because we were using a prototype, we were able to adapt quickly and explore different solutions. By creating and experimenting in this agile way, we found ways to solve the problems and proved that live chat can be valuable for the Samaritans.  Using a prototype meant that we learned these lessons in safety of the lab rather than live on Samaritan’s website.

Because we use creative technologists on our discovery projects, we are able to uncover deep learning. We can afford to make mistakes early and cheaply in the lab.  We learn what works and what doesn’t work so when we build a product, we’re confident that it will meet user needs.

If you would like to chat to us about projects that can make a difference to your customers’ lives, we’d love to hear from you.