Getting started is more important than being right
Starting design without the starting line
A
really great lesson I have learnt is to adopt and adapt the ‘design
process’ that we have been drummed with to everyday design and
problem-solving. Not only as a student but as an Intern we are
constantly reminded of design thinking and other processes that should
be used. But are we ever reminded of when and how they are the most
appropriate tool?
There’s
a small dark area that no one really teaches you and it’s what to do
when there is no user research before the project starts. The
user-centred design approach is designing for real people and users,
identifying a problem. But what if you are tasked with a problem when
you have no real knowledge of those people or specific users? Sure, you
could go and do research but why use all of that time when your solution
could not have any value to the end user?
There are no rules on where and how to start, different projects require different needs and we should be taught to learn and adapt to these needs
I
believe it’s because of the way in which we are taught these processes
that we come to believe they are linear. Design is romanticised to be
this all-knowing, ‘the user is everything’ golden process but in
reality, these concepts and methods are flexible and should be used as
tools to solve our problems, and not as linear processes. What needs to
be emphasized more in the teaching of these approaches is that there are
no rules on where and how to start. Different projects require
different needs and we should be taught to learn and adapt to these
needs.
Getting started with no starting line…
One
method I have learnt to use when starting a project with no prior user
research is by approaching it as a Sprint and adapting the tools in the
method to the project needs.
When I say no user research, this does not mean I haven’t taken some time to become familiar with the project or the people I would be designing for. I mean I haven’t tested, interviewed or really got close to real users. I used Youtube…
Anyway,
by becoming familiar with the topic and it’s users on the surface level
you are able to start exploring the problem and thinking up certain
hunches.
Once
you have an initial understanding of the problem and potential users, I
jump straight into storyboarding. These storyboards are assumed
situations for different scenarios the user may encounter. I make sure
to do two storyboards for each use case — One extreme (novice) to the
other extreme (expert). I find this starts to highlight some potential
problems as we start to visualise how user needs are arising.
From
these needs, you can start to build more tangible questions in the form
of How Might We’s to cluster and form a bigger problem statement to
start a project with
This
may seem like a pragmatic approach to starting a project but I believe
it helps build concepts quicker to test with users and validate if the
idea or solution is worth spending more time and money on to do user
research. Just a really nice way to get yourself started when you feel
overwhelmed that there has been no user research!
I
used this approach in a recent project to build prototypes and validate
an idea early at Bosch. Fail fast, learn faster you know?
