Prospering in the Era of Design Thinking

Millie Gillon, Senior Managing Director and Global Head of Client Experience, Innovation and Transformation at Standard Chartered Bank

Millie Gillon, Senior Managing Director and Global Head of Client Experience, Innovation and Transformation at Standard Chartered Bank

Design thinking, innovation, client experience - all buzz words nowadays. It’s easy to find an agency or vendor to offer services to create a journey and promote it as the next best thing your business must go do now. But very few can figure out how to really build it. Worse, the CIO world is usually who is brought it in at the end to figure it all out.

No… can’t do… won’t work… not enough resources - are all unacceptable responses.

How do you prevent this from happening? Again?

Aside from quitting or burning out your organization, there are smarter and better ways to get through this as a winner.

This is how I operate. If you want to as well, then you must find an open-minded, persuasive, and trusted colleague on the business side.

When: The CIO must be engaged at the beginning of the process.

Who: A Solutions Architect

What: If all he or she does is listen, then you’ve avoided the above recurring issue. If he or she adds to the ideas, is open-minded, and does not approach with a “can’t do” attitude, then you are on your way to the path to success.

Why do this? If the solutions architect is engaged at the beginning, he or she can hear from the business perspective why a feature shouldn’t be deprioritized. What the business logic is to not consider specific aspects is equally important.

How to?: A Solutions Architect’s role doesn’t end at listening. Once the end to end concept is prototyped and each feature is ranked by desirability index, his or her work ramps up and begins. He or she dissects the prototype and maps it back to the other initiatives, backlogs, etc. the solutions architect creates a list of features that are not on the company’s radar. This helps to sketch out the architectural diagrams to build the prototype. The seasoned design thinker partners with the Solutions Architect to map out what to buy, borrow, or build.

What next?: The Design Thinker and the Solutions Architect consider vendors, agencies, startups, co-creation partnerships with Fortune 100 tech companies to figure out how to fill the gap through buying, borrow or build.

A true Design Thinker understands the value of technology and how to leverage a strong Solutions Architect as the bridge between business and technology. He or she also understands great UX design, but that’s a story for another time.

A true Design Thinker understands the value of technology and how to leverage a strong Solutions Architect as the bridge between business and technology

Keep in mind, the purpose of this exercise is not to build out the entire concept, but instead to build out into phases with good enough technology, so that proof of concept phases can run with employees, friends and families, and in specific key markets or segments. This allows for room to adjust, validate, and refine throughout also known as agile, but when the business perspective meets the technology world.

I encountered this situation. Luckily, I’m on the business side and had enough experience to explain the value of this method, with countless real-life examples that are in the market. It was not a walk in the park. It was tough to convince my business colleagues and to even explain to my Solutions Architect what I needed, and why it would work.

First, my team and I worked hard to convince countless stakeholders of the value and importance of investing time in both deep client insights, and design thinking. Our negotiated settlement included a hyper abridged design thinking sprint.

Second, we were instructed to include in the process DVF - Desirability, Viability and Feasibility. Since I lead CX, the easy part was determining the Desirability amongst over 100 ideas. The squad believed a list of ideas was enough for the Solutions Architect to “go build it.”

After many iterations of explaining why the Solutions Architect could not possibly move forward, and suggesting the next steps of how to get to the “go build it” phase, I was finally asked what I think. At which point, my response was - “I just want to tell you - please trust me.” Turns out, no one had experience or knew what to do, but instead of pointing this out, I laid out the plan of how to approach. Since there were no alternatives to the process, the squad took a leap of faith and followed suit.

Third, my team and I created a clickable end to end prototype from both the external consumer-facing perspective and internal - our most important clients.

After handing over the prototype to the Solutions Architect, he was able to dissect it and map it back to each of the initiatives across the organization. Separately, he created a list of components that were not on the organization’s radar. This helped us to figure out what to buy, borrow or build. Consecutively, the squad assessed viability and feasibility, alongside building the business case.

The Solutions Architect pulled me aside and informed me of his experience working with me. He said that this was the best project he worked on during his tenure. The method was the optimal way for the business and technology side to partner together to realistically deliver. It was the easiest and most valuable initiative for the Solutions Architect to ever work on. A week later, he informed me that he resigned before this project. Prior to this initiative, he was frustrated with the unrealistic manner in which the organization operated. CIO organizations are often put in a tough corner. How might this article help prevent turnover during the great resignation and beyond?