Integrating service design and software development teams

I had the immense privilege of being a conversation guide at this year’s CodeCraftConf, hosted by CodeCraft. CodeCraft is a group local to Glasgow and was borne out of a need to create a space for people who craft software that is explicitly diverse, inclusive and encouraging of cross-language technical development discussions. Attending this event and being in the company of these crafters is at the tip top of my list of highlights this year. The guided discussion format is amazing and something I’ll use again. The sessions I attended around growing teams, taking care of teams, remote working and hiring developers were the most exciting, forward thinking and empathetic I’ve ever heard and some of the things I picked up I really hope we can play around with at Snook.

I guided a discussion called ‘Integrating Service Design and Development Teams’ and I had no idea what to expect. Here are my highlights and the things that have stuck with me since. If you were at the session and see anything here that isn’t represented well or that you’d like to build on, please comment! Here goes…

A good amount of time was spent trying to get to the bottom of what service design is, especially in the landscape of user experience designers, user interface designers, systems designers and business analysts. (Sidebar: Job titles suck. What if we moved to creating short mission statements to describe our work selves instead of job titles?) It dawned on me nearly right away that attempting to distinguish and untangle these roles was pointless and to be honest, I sort of started to feel like a jerk for trying. Letting that go meant stories started to emerge from our conversation which gave me opportunities to draw parallels or highlight typical features of service design. For example, someone recalled a ubiquitous story about the elevator that got never ending complaints from its users for being too slow. When the elevator’s owners decided to install mirrors as a way to distract folk in the elevator instead of replace the thing itself, complaints died down. That story it opened a door for me to talk about the holistic nature of service design. If we imagine a service designer had been on the case, it could have been the experiences and stories of users were considered alongside, say, qualitative data about elevator (how long does it actually take the thing to move between floors?), the elevator owner’s needs (assume making users happy while avoiding buying a new elevator) and understanding what job the elevator is helping the user get done by uncovering *why* they’re in the elevator in the first place (this is my preferred framing of user need and it’s called Jobs to be Done), a simple solution of mirrors did the trick. Voila! All the features of service design illustrated in one hypothetical story: user-centered; co-created; sequenced; evidenced and holistic.

From the room: ‘What is the difference between me doing user research and a service designer doing user research?’ I answered by saying service designers could bring a level of rigour and different research practice. Someone else pitched in service designers could bring scale, that if a developer is working directly with users, it is likely to be one or a small group and perhaps focused on a narrow set of experiences. Earlier in the session a hypothetical example was given of the kind of thing developers might be asked to do to improve a service or experience like bring 7 clicks down to 3. I added that if those developers were working with service designers they might also know that before the user even gets to that website with 7 or 3 clicks, they have to fill in a form or pick up a phone as well, that they are usually in a rush in the morning when trying to use the service, etc. Note to self: illustrating the features of service design to newbies through hypothetical stories is handy.

Early on in the session someone asked how service design could help if what is being developed is middleware because in that case, the end user is another computer. Toward the end of the session that same person said they can see how service design could be useful in ethical software development. This was a real moment of clarity for me and gave me something to take away to explore, the intersection of service design and ethical software development. Is this already happening somewhere? Where? Can I help make this happen here?

From the room: ‘What would service designers get out of working with developers?’ I surprised myself at how difficult it was to spit out an answer to this. My default setting is working collaborative and cross-discipline it’s not something I ever really articulate. What I landed on was that it would be very good to know that user stories and needs had been considered in development. Also that it would be beneficial to understand why sometimes software is the way it is, why technically something isn’t possible or very difficult to implement. A flow of information through service designer to shorten the distance between user and dev could be a beautiful thing.

When describing service maps and journey maps as possible outputs from service design work, someone said what I was saying sounded a lot like event storming. I said I have no idea what that is and hit a ubiquitous search engine as soon as I could to find out. Here we are again with language and packaging. What’s your favourite flavour? Choose your own adventure! It’s so useful for me to understand where practice I understand and carry out sits in another discipline (and has cooler names). This year I’ve delved back into my community engagement and asset based community development roots and now I am adding to that the approaches and jargon of software development. Level 2 of Become A Kick Ass All Rounder unlocked.

I said I don’t know any service designers working very closely with developers but imagine the glorious pitfalls and spectacular strengths of a blended development and service design team. Two comments from the room: 1) Someone shared that they know of teams being created in organisations that bring in service design approaches through departmental representation but that it can mean humongous teams. 2) Someone else said this idea confounds their Agile mind because a development cycle ends with the delivery of a working product whereas (ideally) service design acts as an ongoing feature of a service through which there is (ideally) continuous improvement. Some interesting things to consider for the future.

At our final whole conference reflection session, someone said about the service design session, ‘I learned that service design is as confusing to me as it is to everyone else.’ Job done 🙂

Over at Snook we are interested in practically exploring what service design in software development could look like. Let me know if you want to work on something together or even if you just want to throw some ideas around. Our kettle is always boiling.

Posted in: Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s