Design an awesome experience! Part one.

The methodology behind designing service journeys provides you with great analytical tools that will fit almost any kind of experience. Working in the areas of design, development and project management this approach have been amongst my favorites for many years, but I’ve never taken the time to really document the way I use it.

Years ago, I attended a session demonstrating AT-ONEs Touch-point cards, and how simple images and text can be used to design a service or a service journey. I have kept my stack of cards and used them in every project I have worked on since.

The last few years I have dived into different methodologies and dragged more concepts into my work as I saw them fit. Now, time is overdue to tie some threads together and document my work. My next few blog posts are dedicated to this subject, and I hope that they can be helpful.

My context is based on designing web and intranet experiences, so naturally I will try to tie up this in my examples. Designing a SharePoint intranet for a medium sized company will be the case for the series.

Service design

Service design cross into most disciplines. The service itself forms the very base for the existence of each discipline in the first place. Why? Because each discipline in one way or another supports the service being provided. The point being, leaving service design solely to one person in the organization will not work so well.

However, let us not lose focus on the subject. :) How is this relevant to your company intranet?

The answer is really – what goes in your intranet? We define an intranet to be an arena for collaboration, sharing information and working with documents and workflows. The users find their tools for registering hours, sharing documents and for social interaction across the organization. All users will use a portal as their starting point, and will find their tools and content using search and navigation.

In order to design a coherent experience providing the users with content exceeding the native functionality of the intranet, we need input from the right people. Mapping different stakeholders and using them as resources for the design process helps collecting the input and set the requirements for the design.

So, here’s the case:

Sally from accounting want the company’s employees to register their hours using a new reporting system. Her requirement for the intranet is to provide a link to this system. The link must be visible and easy to find. Max, the sales manager, want to check in his hours when he is on the road, connecting via his phone. Pat from IT, requires that access to the intranet is secure so company confidential information do not get lost.

Only providing a simple service as this shows the necessity of the design properly thought through.