This interview with Ron Kersic is part of Touchpoint Vol. 8 No. 2 - Design Thinking and Service Design Doing.  Discover the full list of articles of this issue or flip the preview to get a sneak peek at fascinating insights on this topic! Touchpoint Vol. 8 No. 2 is available to purchase in print and PDF format.

Ron Kersic and his team of four colleagues represent one of the foci of innovation within the bank. Relative newcomers to service design, they’ve dived in enthusiastically, and are applying aspects of the discipline to their day-to-day work. What makes them unique - however - is their location within the bank. Ron’s team are a mix of developers, interface designers and economists, sitting within the Enterprise Architecture group, and formally focussing on APIs and client-facing applications. 

Jesse Grimes: Perhaps more than any other sector, banking and financial services have seen the widespread application of service design. What specifically has triggered your team's interest in the field, and what are you doing to apply it within ING?

Ron Kersic: We started out as practitioners of the agile mindset, and specifically the Scrum framework. Scrum describes how to get from a Product Backlog, an ordered list of everything that might be needed in the product, to a valuable increment of that product, and how to get there repeatedly. It’s really a nice framework. It does not, however, prescribe how to get to that Product Backlog and how to keep it in such a state that the resulting increments are not only feasible and viable but also desirable.

So we set out to find a framework to precisely do that and do that repeatedly. What we found was the Agile Inception Deck. What this Deck gives you is a set of ten questions “you’d be crazy not to ask before starting your project” to help align and set expectations when taking on a new project. There are questions and exercise like ‘why are we here’, ‘create a NOT list’, ‘meet the neighbours’ and - our favourite - ‘design the product box’. It’s a great tool that really deserves more attention. What it does not give you is a structured and repeatable way of getting to the answers!

And that’s where we stumbled on the Design Council’s Double Diamond. We then realised that what we had been trying to do all along was moving from right to left across these diamonds; from Develop & Deliver to Define & Discover. This is the bridge between “doing the thing right” and “doing the right thing”. From that moment on we have been using and promoting service design as a structured and repeatable approach to creating and managing truly valuable Product Backlogs. We’re still doing that to this day. 

What struck me most when hearing you and your team speak recently was that you're all coming from the IT and Enterprise Architecture area of ING, whereas service design typically is discovered and first applied in departments such as design or UX. Can you explain how that came about and how your roles impact your interpretation and application of service design?

Your experiences with Enterprise Architecture departments may vary, but our interpretation is that we should primarily provide context and guidance on aspects of both IT and business to all our stakeholders. In fact, the motto we adopted is “developing the environments, tools and processes that help our colleagues deliver superior service in a way that is proprietary to the brand.” We got this quote from the This Is Service Design Book.

Now, how people use complex systems is changing; from a functional perspective to a more engaged, emotional relationship. There is a need for a way of working that recognises this shift. We are inspired by the ‘conversational’ capabilities of some service design tools, especially service blueprints. We do think it's a shame that their application often stops at prototyping. We attempt to bring continuity to service design practices by linking them with the agile software development practices.

In the context of the current dynamic times, it is especially crucial to have a clear plan to get rid of complexity and to articulate long-term goals. Uncertainty, certainly at a widespread scale, is a mind killer. We position Enterprise Architecture as a group that is actively helping ING be clear on the uncertainties that need confronting; getting rid of any ‘autopilot’ mentality. It’s a position that is as unexpected as it is natural!

One aspect that we discovered just recently and that is really coming from our relative location within the company, is the issue of service design as a tool to help discover, define and refine the long-term goals of both Enterprise Architecture and the organisation at large. This is what Eric Roscam Abbing coined as “design shapes strategy” in his book and what also falls nicely in line with the “managing as designing” movement (if one could call it that).

ING also has a team of dedicated UX designers, sitting in a different part of the bank both physically and organisationally. Because they are directly involved in designing the tangible aspects of customers' experiences with the bank - such as the website and app - they naturally need to play a role in service design initiatives. How do you bridge that gap and have the strategic and orchestrational mandate that successful service design requires?

Is there a gap? We also have Customer Journey Experts and DevOps teams, all of whom practice humancentred design in one form or another. At the heart of our organisational model is a self-organising ‘Squad’, a multi-disciplinary team. This team, together with the designated architect, have the mandate to create meaningful value propositions. Our main task is to provide a shared, uniform context for all disciplines.

The bank earned national headlines 18 months ago when it was entirely re-organised around the so-called "Spotify model", with dedicated multidisciplinary groups created across the organisation, such as the ‘Squads’ you just mentioned. How has your team been affected by this, and what has it meant for the practice of service design and customer experience in general?

We have reorganized ourselves according to the Spotify ‘Squads-and-Tribes’ model. Multi-disciplinary ‘Squads’ are self-organising and manage their own Product Backlogs. This frees up time for Enterprise Architecture from being involved in day-to-day work on individual IT components, to thinking across components, teams and organisational boundaries. It’s all quite natural.

So it sounds indeed like you're applying those strategic and orchestrational aspects of service design. Can you briefly share an example of some recent work you've done, where you've applied service design to an Enterprise Architecture challenge?

An important part of the bank going forward is building out a platform-based ecosystem; an Amazon-for-Banking if you will. Our CEO has articulated this quite a lot recently. It’s quite obvious for Enterprise Architecture to come up with a framework for describing the technical aspects of platforms and the organisational traits of the ecosystems they support. On top of that, we are formulating a framework to express what it means to design for such an ecosystem and what impact this would have on our current (service-/UX-) design toolbox. This is in effect our interpretation of ‘Diffuse Design’ as put forward by Nicola Morelli and Amalia de Götzen, mixed up with some ‘Experience Economy’ and Fjord’s ‘Living Services’. This framework, aptly coined ‘Living Design’, we are now refining in the context of a large project (that has to remain anonymous for now, I’m afraid).