Design in the Boardroom #1: Timing

Machiel Oskam
onlinedepartment
4 min readNov 5, 2019

--

In a world dominated by IT driven projects and technological innovations, al lot has changed. Researchers, strategists and digital designers are moving up — or moving forward in the value chain. Meaning that before developing digital products, validation needs to be in place. In this first chapter we will discuss timing, als part of the digital maturity discussion within larger organizations.

Supported by design thinking and lean innovation trends and methods, an increasing amount of business leaders and managers are asking the same question: should we invest in technology and IT at this stage, or do we need more proof of real value for our customers? Failing and wasting resources on unvalidated propositions was never a big issue. Nobody’s head was cut off, and people could hide behind the general misconception that IT is just really expensive.

With relatively new tools and methods the process of technological innovation has changed. These methods, stem from the Lean Startup movement and the design thinking approach, are winning ground in operational-, technological- and financially-driven organizations. It helps them to save on wasted resources, time consuming meetings and building products that nobody wants. They understand that now. The question is just how to implement these new strategies. How to transform an organization that is used to manage projects based on requirements that are not thoroughly validated in the market.

The timing challenge
Still we (and many other UX designers and digital product design experts) are called upon to participate in projects where a team of programmers is already lined up. We just need to deliver screens as fast as possible, because a group of expensive people is waiting for requirements and needs to build that app, platform or application before the deadline is due.

I understand how this works. Programmers are hard to find and always busy. You first want to confirm these resources and then sell it to the internal stakeholders. The question is, how can we change this way of approaching a project? I often use this article by Jeff Gothelf. It shows that before getting into development sprints, you can or should plan reseach effort or a design sprint. It is important to move a few steps back though.

Getting back to the idea
In my experience, a design sprint is sometimes used a an excuse to follow a value-driven process. Maybe you need multiple design sprints or a more intensive discovery phase to understand how to best move ahead.

First of all, get researchers and designers into the room.

Organize an assumptions workshop where all the ideas for new propositions, improved business models and other initiatives are held up to the light. As a business leader or manager you must be brave enough to be vulnerable and say: I think this is a great idea, but I need prove this idea actually has value. Value for our business, and value for our customers.

When there’s still a chance you might tackle the real problem before you put people to work, use it and buy some extra time. In a month or so, UX researchers and designers can provide you with all the data you need to confidently move forward. Invest in experiments, prototypes or other proven methods they hold in their designers’ toolkit, and put a break on any technical development. I promise you you’ll be the hero of the month.

The stages of UX Maturity Framework from timing perspective.

To conclude
In order to make this change, timing and roles need your attention. The person that understands how to run a ‘problem-solution fit’ project should be close(r) to the decision making level. There are many titles for this role. To name a few: a business strategist, UX lead, experiment lead, lean startup coach or design thinking expert. Whatever the name, make sure you craft clear problem statements together, make a plan for validation, provide access to a customer base and create space and time to run the experiments.

Make UX activities part of your business requirements, prior to code.

======

This article is part of an exploration around design maturity and the obstacles and changes that are involved to materialize this within larger organizations. The common goal is to create more value-driven companies and seek a more effective dialogue between business leaders and designers.

Our UX maturity framework functions as a guide for further research and discussion. Care to dig deeper? Download the (Dutch written) whitepaper from our website.

--

--

Machiel Oskam
onlinedepartment

founder and Creative director @Online Department, Design Thinker, UX Design Trainer, investigating and writing about design on boardroom level.