Getting started is more important than being right…
Getting started is more important than being right so when we lack a starting line what do we do? More often than not (as a student designer from my experience) you find yourself starting projects without an understanding of the problem, without any user research and with no clue of where the starting line is. Over the past year during my time as an intern I was exposed to how organisations leverage Design Thinking around their own problems and it made me wonder how I could leverage Design Thinking for my University projects in my university projects.
The problem with design in education is that it 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, not as linear processes. I think this is what some people struggle to come to terms with, after all we have had linear processes handed down to us for as long as we can remember.
So, with my bachelor project starting I decided to use my first week of the project to test run how I could leverage the tools from Design Thinking I have learnt, kind of like a one-man design sprint without the prototype.
Understanding the problem
Before this experiment started I already had an idea of the problem area I wanted to explore. Through some quick and rough research, interviews with possible stakeholders and assumptions (very important at this stage) I learnt more about the use case so that I was ready to start.
Understanding relationships — Exploring the relationships of a problem area allows you to understand how each and every individual may interact and influence one and other over a certain scenario. I did this by building a stakeholders map — each user in the map has a role and a motivation.
Understanding the user — Once I had a better understanding of how all of the stakeholders involved would interact I took influence from IBM’s Design Thinking toolkit and decided to start understanding and building more empathy with the user in the problem area. I did this by building an empathy map — placing the user in the centre and explore what they could do, think, feel and say about the problem area in question. This tool really allowed me to uncover some feelings I had not previously considered.
Mapping the users experience — Once I felt comfortable that I had started to establish a better relationship with my user I moved onto ways in which I would be able to understand the experience of the scenario better. I used two methods here: An as-in scenario where each step is broken down into what the user is doing, thinking and feeling, and an experience map so that I could start to identify dips in the users experience.(the opportunity for me to solve problems!)
Perhaps the pivotal moment for me throughout these tools came through the as-in scenario and the experience map, by being able to see the dips and peaks in a users experience through their journey it becomes clearer at which points I can ideate for in a short sprint like this.
By taking these dips and my empathy map I formed need statements for my users before reframing them into How Might We’s to ideate from. These ideations formed as the basis for my initial concept. Now I know this was all carried out through assumption based decisions but perhaps the most exciting part is that I now have an initial concept to go out and test with real users and build relationships with.