Design thinking is not just for hipsters….

In recent months, I have been exploring design thinking, a practice I first encountered nearly 20 years ago (when it was called user-centred design). Whether we are talking about UX/UI, CX, human-centred design, service design or even “boring” process improvement, it’s important to realise that this is not just the domain of hipsters – everyone can, and needs to understand how these design thinking techniques can build better product and service outcomes in multiple applications. Here are three real-world examples to consider:

Curved Space-Diamond Structure by Peter Pearce, Hakone Open-Air Museum, Japan (Photo © Rory Manchee, all rights reserved)

Curved Space-Diamond Structure by Peter Pearce, Hakone Open-Air Museum, Japan (Photo © Rory Manchee, all rights reserved)

1. Financial Services – a case of putting the cart before the horse?

A major bank was designing a new FX trading system, to replace a labour-intensive legacy system, and to streamline the customer experience. The goal was to have more of a self-service model, that was also far more timely in terms of order processing, clearing and settlement.

The design team went ahead and scoped the front end first, because they thought that this was most important from a customer perspective (and it was also a shiny and highly visible new toy!). However, when I heard about this focus on the front end, I was prompted to ask, “What will the customer experience be like?” By automating the process from a front end perspective, the proposed design would significantly diminish the need for customer interaction with relationship managers, and it meant they would have less direct contact with the bank. Whereas, part of the bank’s goal was to enhance the value of the customer relationship, especially their priority clients.

Also, by starting with the front-end first, the design did not take into account the actual mechanics and logistics of the middle and back office operations, so there were inevitable disconnects and gaps in the hand-off processes at each stage of the transaction. (This is a common mistake – a colleague who consults in the retail sector told me about the online storefront for a major retail chain that looked really pretty, but revealed no understanding of the established supply chain logistics and back-office order fulfilment processes.)

The bank team had a rethink of the storyboarding and workflow analysis, to make sure that the customer experience was streamlined, but that there were still adequate opportunities for customer touch points between client and relationship manager along the way.

2. Construction industry – inside and looking inwards

Another colleague told me of a specialist supplier in the construction industry, that was undertaking a review of their processes and service design model. From an internal perspective, everything looked fine. The customer orders came in, they went into production, and were then delivered according to the manufacturing schedule.

However, there were two stages in the process, that did not work so well from a customer perspective:

First, customers did not receive any confirmation or acknowledgment that the order had been submitted; so they might be worried that their order had not been received.

Second, once the order had gone into production, there was no further customer communication until it was ready to be delivered. Meanwhile, the client’s own schedule might have slipped, so they might not be ready to take delivery (we’ve all seen those moments on “Grand Designs”). Resulting in the supplier having to hold unpaid for work-in-progress in their warehouse.

For the supplier, it was a simple case of implementing a formal acknowledgment process, and a check in with the client prior to fabrication and a follow-up prior to delivery to make sure schedules were aligned.

3. Energy sector – gaining empathy in the field

A friend of mine ran a local distribution and installation business for an international supplier of energy switching gear. They specialised in remote operating systems, most notably used in indigenous communities. Head office was in Europe, and the clients were in outback Australia – so communications could be challenging. The overseas engineers would not always appreciate how time critical or simply inconvenient power outages or interruptions could be. “We’ll fix the software bugs in the next upgrade,” was usually the response.

Then the local business started inviting their European colleagues to come and work in the field, to get some downstream experience of how customers use their products. It was also a good opportunity to train technical staff on how to handle customers.

One time, a visiting engineer was in a remote community, trying to fix a power operating system. When Europe said they would take care of it in the next upgrade, the engineer pointed out that he was with the client there and then, and that without power, the community could not function properly, and that Head Office had to solve the problem immediately, even if it meant working overnight. The issue was sorted right away.

If nothing else, the visiting engineer, schooled in siloed processes and internal systems at Head Office, had managed to gain empathy from working directly in the field.*

While none of these examples seems to involve cutting edge design thinking, they do reveal some fundamental service design and product development concepts: the need for empathy, the value of prototyping and testing, the role of user scenario and workflow analysis, and the importance of challenging existing processes, even if they seem to be working fine on the inside.

*Footnote: This reminds me of a time many years ago when I was travelling around Beijing in the back of a cab, between client visits, calling my production team in the US, asking them to investigate a problem the local customers were having in accessing our subscriber website. “The Chinese government must be blocking the site”, I was told. Given that most of the clients were state-owned enterprises, or government departments, I thought this was unlikely. Turns out that the IT team in the States had “upgraded” the SSL without informing anyone and without doing multiple site testing first. Some clients had problems logging on from slower internet services, because the connections timed out. Being in the field, and speaking directly after witnessing the client experience for myself enabled me to convince my colleagues of what the cause actually was. Although we had to implement an interim workaround, going forward, every software upgrade or product modification was benchmarked against multiple test sites.

Next week: More on #FinTech, #Bitcoin and #Blockchain in Melbourne

Change Management for Successful Product Development

Recently, there have been a number of commentaries on the current trend/fad for applying Agile and Lean product development methodologies to corporate management. I’ve also noticed an increasing focus on “Product Management” as a formal discipline by training and professional development providers. Consequently, I’ve been revisiting some work I did many years as part of a Change Management Diploma.

Situational Leadership

My thesis is that different Change Theories of Management can be applied to each stage in the Product Development Cycle*, to ensure that the organisation is aligned with the business needs as they relate to strategy, capabilities, capacity and execution. This is also the context in which organisations use Situational Leadership techniques to cope with constant change in technological, social, economic and environmental forces.

(*This work was based on a reading of Theories of Organisational Change as Models for Intervention by Dunphy & Griffiths (published by Australian Graduate School of Management – Centre for Corporate Change, University of New South Wales, 1994). For a copy of my model, please contact me: rory_manchee@yahoo.com.au)

1. Fit for Purpose

Various skill sets are needed along the journey from ideation to production, and management has to harness appropriate resources to increase the potential for success. Organisations may need to consider restructuring to maximise their ability to develop sustainable product development systems that incorporate continuous improvement, feedback loops and market responsiveness.

For example, moving from annual software updates to quarterly releases might simply suggest some production rescheduling, but it may also mean changes to documenting user requirements, customer billing systems and client support tools.

2. Playing to Our Strengths

The person who is great at capturing the design specs may not be the best person to undertake market testing with beta users. And it’s generally accepted that someone who is adept at working in a production or QA role on an established product may need some re-training before they get to work on building a prototype.

3. The Model Approach

In conclusion, my analysis reveals that at each stage in the Product Development Cycle, there is a need to review the relevant Business Challenges, address the corresponding Change Issues, and apply appropriate Change Management models or techniques.

 

Update on Perspective – Introducing the “We R One World  Game”

In a recent post on “Perspective”, I commented on the value of stepping back and taking a different look at current ways of doing things. For an immersive, interactive and experiential learning opportunity on how to gain a new perspective on problem solving and how we might address global challenges, the Slow School of Business is running the “We R One World Game” on Saturday, July 25 in Melbourne

Dymaxion_map_ocean2

The Dymaxion or Fuller projection is a world map, which can be rendered in 2-D.

Facilitated by Ron Laurie, and based on the pioneering work of Buckminster Fuller, this event promises to combine a hackathon, a meetup and an unconference all in one! Tickets available here.

Next week: Who needs banks?