Service Blueprint

Blueprint is one of the basic tools in service design practice. It specifies each element of the service across different levels – including those visible for the user and, most importantly, those actions “behind the scenes” that influence the visible outcomes, like in a cause-effect relationship.

‘This is Service Design Thinking’ recommends collaborative creation of blueprints with the company that a designer is working for which could be a great, engaging and actually fun way to discover and deconstruct together the crucial areas for a company. Unfortunately, this maybe is not so much the case in a student project. However, since I had a great opportunity to speak with the Festival Producer, Corinne, I showed her the blueprints that I had made based on the user journeys and the research that I did. That was a great way to engage and although Corinne actually did not suggest many changes, it helped both of us to support the conversation visually and was a small taster of how such “blueprint co-creation” may take place.

Below you can find three blueprints for each user journey with their comparison and critique at the bottom.

Blueprint v2-01

Blueprint v2-02

Blueprint v2-03

Blueprint comparison:

Blueprint v2-04-04-04

Interview

Today I had an opportunity to meet Corinne Orton, Glasgow Film Festival producer who was kind enough to answer some of my questions about the ticketing system of the festival. Corinne gave me some interesting insights into the mechanisms of the festival and the main problems that they are struggling with. The biggest one seemed to be an old booking system and no money for a new one. She also admitted that they do not offer a return ticket service – visitors cannot return the tickets to the ticket office with the only exception of event cancellation or program change.

Continue reading Interview

Stakeholder Map

Stakeholder map or a relationship map helps to visualize all the parties involved in the service. It is easier to translate the connections and the proximity to of each stakeholder or touchpoint to the user using a circular form.

With three user journeys and three personas, I firstly sketched out relationship map for each journey. By combining the three maps, I was able to create a general service stakeholder map which accommodated all the journeys. Now, it is easier to notice which touchpoints are used by each persona, which were crucial to buy a ticket or find out about an event, and which connections were missed.

Stakeholder map general-04

Stakeholder maps2-05-05

Personas and Users

After the both events took place, I attempted to create three personas based on my experience of the user journey and the people I met spoke along the way.

There is an ongoing discussion about the difference between persona and user profile. It used to be a common practice to give a “fake name” to a persona, give them their personal characteristic like hobbies, family status and type of work. So for example we had a single John, who was 45, working in a bank and playing football during the weekends. But how much can we identify with that fictional John?

Another way, the one that I followed here, is to create a persona profile that focuses on habits that might be relevant to the project. It can fit people from different backgrounds and it is based not on the age or profession, but on the motivation and needs that bring this particular type of users to the service. It is something like a collection of “psychological profiles” that users or clients can identify with.

personas-14  personas-15

personas-16