Est. Reading time: 15 min
Misnomer in the term itself
There’s a lot to a name or a label. In this case the term “Design Thinking” is misleading. Since it has the word ‘design’ in the term, many misunderstand that it’s a design device thus only designers are only good at it – it’s simply NOT TRUE.
In order for Design Thinking to work at optimal capacity the whole org (every facet of company) must all buy into it and collaborate/contribute to its process. From business, engineering, sales, marketing to customer service etc; UX designers are merely facilitators throughout the methodology– to extract insights from cross-functional colleagues & translate them for practical use. In fact Design Thinking is an organisational affair, highly collaborative, and definitely not exclusive to people from design backgrounds.
Distilling it down to its pure essence
UX = User eXperience design = Human-Centered design.
It goes without saying, the heart & soul of UX is driven by “User Advocacy” within our orgs – being obsessed with customers’ needs & problems. It’s common to hear many terms being thrown around in the industry such as “UCD” or “User-Centred design”, “UX”, “Lean UX” and it goes on. They all essentially lead to the below (diagram), which is the core engine of Design Thinking:
The best acclaimed practice/method to come out from the design thinking umbrella is undoubtedly Lean UX– where its philosophy mixes in business needs/goals to align with user goals in an agile framework for continuous learning (via a 2-way communication with Users/ market). It is fusing design, business, & development to all work together in product design as an org. More on Lean UX in another blog posts (pending)…
Key question then…Why?
So why involve so many people? isn’t it pragmatic to appoint it to the UX team and expect them to deliver (like we always do)? Aren’t they extra overheads of time & bandwidth to involve so many people and ‘design by committee’? why even bother? When to UXers are evangelizing Lean UX, these types of questions from colleagues from legacy organizational culture will pop up in one form or another– if not, for sure they are thinking it (they’ve yet to voice it out in the open).
Firstly let’s tackle the “design by committee” issue – this insinuates that there’d be project blockers due to having too many decision-makers (or too many ‘chefs’ in the kitchen), which do not apply in our case. Since we follow the evidence (via by customer input ) of what works & doesn’t – findings on Users’ behavior & facts are driving direction, not the committee. Lean UX bakes in the 2-way conversations with Users in product design process with low-cost & rapid experiments to get answers which dictate design decisions. Involving colleagues starts the process off by mapping best educated guesses (assumptions) as starting points in the process for UXers to validate in a continual learning process. This actually saves time since those assumptions gives us targets to test/validate rather than from a blank canvass.
Our colleagues in Sales, marketing, business, customer support, engineering, all have insights. They give the product vision different perspectives, vantage points, leads to a richer knowledge base vs. a small group of people working in silo. Leveraging them and declaring them as assumptions as starting points provide focus to UXers – key milestone in Lean UX.
Big learning up-front approach
Using economical & Rapid Prototypes , orgs can obtain plenty of insights by failing fast, early, and frequently. Failure is good in this context as poor results in usability tests direct project teams on what not do, and what to keep – this can happen within a couple of weeks into the start of the project as many online tools offer low-fidelity prototyping. Once again, the tools are quite simple that non-designers can become proficient quite easily. UX designers are indeed excellent facilitators to guide the org through this step, particularly interaction designers.
If there’s one key ingredient to success from Design Thinking, giving your project teams the “permission to fail” is invaluable. It allows for Rapid Prototypes to get made, encourages innovative ideas to get tried out frequently. Since they incur little time investment/costs, the failures are negligible while adding much value by increasing customer behavior IQ into the project teams. More experiments are outputted, more insights are gathered, and numerous answers are found as the potential solution– naturally the cream of the crop (best) answers rises to the top in the process.
Contrarily, in the traditional approach of trying to create the single answer to the problem from get-go (and debilitate teams & incur valuable time in the process) are going through a path or tunnel with a giant “?” of how it will get received by Users in the end.
The common trap: Group-think
There’s a common scenario “Group-think” in UX which we are mindful of looking to avoid– a select group of people within an org makes decisions on roadmap, product features, budget and contract decisions for a product– in the typical top-down fashion.
Key issue with this situation is that a team is not likely to challenge ideas from their superiors in the room, so the bosses’ decisions are soon embraced by others in the board-room. At times those decisions are on the mark leading to success, while it’s the times they are off-the-mark with what is needed from the market, creating risks in business.
The other major issue with group-think it starts & ends within the org in key points of product design, rarely getting out into the market during the process regularly to test out theories/ideas to mold & shape a product from direct feedback from Users.
Design thinking is the antithesis to group-think, as is oil to water. Its key principles demands that we get out of our own heads and speak with Users to measure our theories/assumptions against reality. Sometimes our assumptions are correct, and often they are NOT, Design Thinking enables orgs to get to the bottom of what are valid/not valid, as insights to feed back to our projects in a continuous cycle.
Group-think leads naturally to waterfall approach where Top-down-executives makes key assumptions & decisions, which then leads to Big-design-Upfront, including coding/building. Typically it leads to big hand-off to another hand-off, with little room for feedback from the market making the required adjustments along the way— runs the high risk of failure once the product reaches customers. Statistics show that more than 70% of products in software fail to be accepted by users , for this exact reason.
Culture of building things Vs. building the Right thing
As software companies we can design/build apps, if our company rewards us in doing JUST that, we will continue to do this with the mantra ‘they more we do, the better’ mentality.
This is another trap.
What good can it bring to companies by having software which doesn’t get used because it doesn’t add value to actual users? What good is having a software with 100+ features where 95% are rarely or never used?
It’s building for the sake of building fast and as often (without sufficient dialogue with Users on usability) . Ultimately, if the app doesn’t get adopted by Users, was it really worth the time & effort in designing/building the years it took to get to market finally?
Let’s flip the case upside-down now. What if we had a company culture of Rewarding people who design/build the Right things instead? What if…. we included Customer feedback in all of our assumptions to help decide direction from the very beginning? Act on evidence-based science of higher usability and mold/shape the product with the Customer being at the center of our decision making process. Industry statistics indicate that this led to much higher probability of success in the market, mainly due to the fact that it led to higher probability of User adoption of the product as a consequence.
This way of thinking, acting, and interacting (as company culture) in software/product design process is called Design thinking.
A question to you then: which of the 2 types of company culture do you recognize within your org right now?
