I became interested in design thinking back in 2009 when I saw how students at Stanford University were developing new concepts. Instead of desktop research and ideation, they built prototypes and brought real people to try them out. Learning and decision-making were based on what worked and what didn’t in the interaction between the prototype and the prospective customer. This felt like a very intuitive way of developing, and later became an essential insight for me while I was pursuing ways to develop new services and service business. In Finland, design thinking became widely used in business development during the last decade. The change was driven by a clear need: Companies started their transition to service business and the digital world.
A big paradigm shift never comes without a bundle of growing pains. This parody by Marketoonist perfectly captures how the adoption of design thinking might not lead to intended results:
Some of the above I’ve witnessed up close in real life and in different organisations. Of course, in the big picture, the shift to customer-centric and experimental development has brought a lot of good things, and the change has come to stay. This blog post will review five specific problems and growing pains that I’ve encountered in Finnish companies. They are something I see has a particular effect on the actual impact:
- Customer insight and development should be closely intertwined
- From designers’ solo games to finding the right roles
- Post-it workshops and sloppy ideas are a sign of something
- Technology and design: Opposing forces or endless possibilities?
- Service design or business design?
Growing pain 1: Customer insight and development should be closely intertwined
Recently, I was discussing with a familiar customer regarding a new project. It was about the development of a new customer relationship management model. When asked what kind of skills she felt that a successful project would require, I was told, “Not a pure service designer, thank you. We need someone who could design our new business model together with our business people.”
The answer left me thinking. I find it reasonably clear that especially a service design team, in particular, should credibly combine business planning and customer insight. But maybe we shouldn’t assume, but rather try harder to understand.
The organisation in question has been building design competence for years. However, their designers have unfortunately gotten stuck into a role where the work is essentially a repetition of the following: Interview customers, and bring back a report on customer needs and behaviours. The business proceeds at its own pace, forming options and making decisions without the presence of design. The link between technology and execution is very thin.
One of the most important lessons in my career has been that it is only when research (customer insight), design, and development come together at the team and project level that results are achieved. To put it another way: Research, design, and development should never be stand-alone project phases, they are a process: Continuously iterating your work based on what you learn through customer insight, what are your project KPIs, and how you shape your vision through sense-making, as a team. Talking to customers or real-life experiments are tools to learn what works, and after learning, you repeat it. Gradually, the level of experimentation becomes more tangible as uncertainty about what brings value decreases. Usually, you start with the hypothesis on a paper and progress your way to actual business experiments.
Some organisations are already good at combining research, design, and development. Most of the designers at Solita that have already learned to combine research and design are now ready to incorporate the actual development of the new service at a more concrete level. Many in-house designers I have talked to have also crystal clearly acknowledged the benefits of combining the aforementioned work types.
Growing pain 2: From designers’ solo games to finding the right roles
When defining structures and roles in organisations, some kind of a label of skills and title is put on people either consciously or unconsciously. With a relatively new discipline, this has resulted in inflated expectations of people who are called Service Designers. I’ve met many of the absolute most talented people in the industry, but I’ve yet to encounter a polymath who could consult top management, evaluate tech options, produce high-quality insight on human behaviour, facilitate great workshops and visualise prototypes. Yet in many cases, these are the expectations many design people have faced. The result has been the bursting of an expectation bubble and also a great number of burnouts.
It is critical to understand that high-quality design is a result of a shared way of working and that no one can perform miracles alone in front of the complex design challenges of today.
In the right roles, talent flourishes. I’ve encountered successful teams, including the same organisation I described above. In one project, business people, designers, and data professionals worked together to set KPIs for work, hypothesized possible solutions, very quickly visualised them, and took them to customers early on to learn and prioritise what they learned against the set KPIs. There were clear indications of a new, more sustainable way to design for complex problems.
Growing pain 3: Post-it workshops and sloppy ideas are a sign of something
The situation is familiar to many of us: You just attended a workshop that resulted in a pile of post-its. Someone emails a document, where the post-its have been moved to a PowerPoint. But what’s next? Nobody has an idea, and the momentum is gone.
This goes back to the cartoon at the start of this text. Adopting design thinking principles is a good starting point, but in the end, actual results are achieved through professional design work.
In a recent Solita Design & Strategy teams’ research project, we talked to business executives who were actively working with the in-house designers of their respective companies. They valued design expertise highly, but there is also plenty of room for improvement. The following were the most discussed topics to improve upon:
- Designers are not able to think about the business side of what they are working on and the logic of how business works. Because of this, they are not able to lead projects and prioritise their work on what is most important for the business. A common problem that especially public sector organisations face is the following: High-level strategic targets are so high level that they become separate from the actual service they are developing. There is not a link between the operational KPIs of the service (leading indicators) and the KPIs of the whole organisation (lagging indicators). There should always be a link between these two.
- Customer insight is vast, but essential insight that has a clear impact on KPIs is lacking. Business management is usually pretty smart, and they are able to separate good insight from bad. Too often, customer insight documents are very thorough and detailed, but seeing the essential from a large amount of data would be needed. Insight needs to be actionable.
- Lack of realism when it comes to the feasibility of the service. Design and IT units are continuing to develop better ways of working together. However, many designers are still learning how to evaluate the realism of how the concepts they are working on would be turned into reality. One manager told us how he was presented with a smart-sounding new concept improving their company’s customer experience. But, the changes at the operating system level would have cost millions of euros. For designers, it is important to be able to tell when their hypotheses are at such an early phase that it’s too early to evaluate technology options and when to involve someone who is able to build a roadmap for execution.
I’m not writing this to downplay design professionals. Many roles and ways of working are still new and very demanding, and many capabilities are still evolving. It is good to critically reflect on how to develop your own team.
Growing pain 4: Technology and design: Opposing forces or endless possibilities?
As a consultant, I was used to building trust with my customers by saying that I will not design anything that will force a digital solution, but rather look at how to build customer and business value and base the solution on that. Still to this day, I think being solution agnostic and customer value-driven is very important. But let’s face it: The relationship between technology and data has changed dramatically in every organisation. Basically, every core process is linked with systems and data.
Good design has to start from building something valuable to people. If it’s not, it’s usually not worth building. As a designer, the relationship to technology should be turned into curiosity. That way, you usually find yourself working with processes that are the biggest sources of impact.
I’ve seen good progress in this as well. In the best communities, designers understand that they should look at data as an essential ingredient of design work. These three questions are very good ways to look at how to design with data in mind:
- How can we use the data we already have to build something new and valuable for our customers? (New services based on data)
- What data do we need to produce excellent customer experiences? (Using data to improve CX)
- Out of all the data we have, what could be valuable for other organisations to build new business or services (Developing ecosystem-level services)
Those are three very critical design questions for most organisations today.
On the other hand, sometimes also technology people build resistance towards design. In many cases, it is because they have no prior experience of good design projects. Design is seen as a phase that slows down the project. Sometimes time to build customer insight or design is cut to a minimum to start working on the technological solution. Sometimes execution planning is done without understanding what customer problems the service is solving. Also, in many of the agile development models of today, design plays a very small role. For example, in the SAFe model design was brought in only at version 5.0 and at a very small role there too. It’s a good thing there are good examples that are changing this. At Solita, many tech people have seen that involving designers actually helps their work and improves the odds for projects to become successful.
Growing pain 5: Service design or business design?
In theory, this is a straightforward topic. There are projects with the need to design or improve services (service design), projects to design new business (business design), and projects to build strategy. In reality, there is a grey area between these three; sometimes altering a service or its user interface could impact the whole business model and organisation.
The biggest problem I have encountered is a staffing one: What kind of team is needed to solve what kind of problems? For example, many consulting companies headline their sales decks with strategic problem solving or business design, but in reality, the core of what they are capable of might be in UX design. The smartest buyers, of course, are able to see through this and ask questions like “What are you actually known for?”.
Another staffing problem I see is whether the actual goal of the work is to create new culture and capabilities or to see business results fast. Both of these goals have their own paths to go and different means and KPIs. The most important discussion should take place in the project goal setting and project planning: What has changed if the project is successful?
We can say for sure that the role of design in business development is here to stay, and there is no going back to the old. The growing pains I have described will eventually disappear, and results will follow. The most crucial skill in leading design work is most likely design generalism and understanding the big picture: What design skills, roles, and ways of working are needed in what parts of our organisation? The key to successful change is – and there is no easy way out – humility and self-reflection: If what we are doing is not working, why? Are we on a learning curve, or should something change? Hopefully, the thoughts I have written help you with the next steps of building design capabilities in your organisation.