Center on humans
I hate the word users. To me, it feels derogatory and in some contexts triggering the idea of us product people creating addictive solutions for faceless users. I gravitate towards people and fellow humans.
You might be here because I sent you. This patch of my digital garden will grow into a primer for how I like to frame User Experience and Human-centered design. In some sense, it's my journey towards where I am today, but it is also a collection of ideas, links, and articles that I feel could help us get on the same page quickly on these matters. The drive to compile this is also because I've been sharing these ideas with up-and-coming product people that are struggling with pulling their organizations into the current state of User Experience and Human-centered design.
My background is in computer science. I was educated in the craft of making software. This was the last century and we did one usability course in Delphi. Back then and unfortunately within some companies still today, people think that in order to make fantastic software, you only need a group of highly skilled engineers. Identify a problem, engineer a solution, and the world is your oyster.
The fact is, that the world has moved on.
I quickly learned that I suck at coding. My brain is not wired for weeks of low-level coding without any context of "face" to interact with. On my first semester, we were tasked with deploying something on our personal website hosted by the University of Iceland. This triggered an implosion in my brain. After having spent a week trying to get my C program to compile and spit out a single number, I was now throwing animated gifs at the World Wide Web in real-time. I stayed in the lab till late the following days and actually ended up dropping out of full-time studies to set up my first company. This was it for me. It took me 7 years to complete that CS degree but during that time I was riding the .com wave to bust and loving every minute of it.
But around that time there was a rift and I fell into it. I started doing more talking than coding. Product management was not really a thing yet, but I was spending more and more time with our stakeholders. In this case, the IT departments paying us to design and build websites. I have always been design-curious. I actually did layout work for a few print publications and considered myself a Photoshop genius. Today I know better. But the combination of having an eye for design and the ability to communicate with stakeholders and developers on their terms set me up for the career I've pursued ever since.
It started with wireframing, user flows, and eventually personas. We're talking 2004-2005 on the calendar here. The first project I actually remember applying personas properly was for the big Icelandair re-design project. I was working with a fantastic team on their side and we actually convinced everybody to do user interviews with passengers to build the archetypes and personas. This was the first propper user research project I participated in. It was fantastic, even a pivotal time in my life. This single relatively inexpensive exercise changed the whole gravity of the project. Icelandair even launched a new product, Icelandair Golfers, based on a biased interview with some golfers that hated paying for their extra luggage. It was a simple site with the golf courses at their destinations. I just realized they shut it down in 2020, but it ran for a good 15 years. I'll do another post later on how everything I work on ends up in a digital landfill with increasing velocity.
So yes, card sorting, wireframes, user journeys, personas, and the occasional usability test. Google analytics was a thing in 2005 so we even had some data to validate the success of our work, albeit on a very basic level.
Fast forward through the years in London and dozens of projects where I tried and tested different methodologies. My takeaway in all of my experience is that if I managed to sell the stakeholders on the idea of investing in propper research with the people we're trying to serve. These are the projects that have been most successful in my career. I have high motivation to capture each of these projects in separate posts, but no ability as it stands.
Fast forward again to around 2015. I was finally working as a propper Product Owner and applying many of the skills I'd picked up in the past. The company was small and engineering lead. We had product and design sitting on one side, throwing ideas and pixel-perfect designs over to engineering. Hoping for the best. But there was a very strong growth mindset that lead to us trying new things and constantly improving. Around that time Jake Knap was blogging about the design sprint concept he was developing and Google Ventures. It was such a good fit for what I had in my brain but not formalized to such an extent.
We got the go-ahead to set up a cross-functional team, empowered to crack that savings goal nut that all banks were craving but many failed attempts at delivering were just causing frustration. We did the first full-week sprint in 2015 where engineering and design worked together on discovery. Then we sat down and built it. Loved every moment of that. Later we realized that people actually don't want or need the saving goals designed as banks had been asking for them. But that is another story.
The Sprint book was published in 2016 and I ordered a box to hand out the gospel. I have probably given 50 copies of that book and have none at the moment. Read it. It's still highly relevant and one of the best recipes for discovery and validation activities.
I leveled up at Meniga to a point where I was leading the Product Organisation and during that time, we actually packaged the Design Sprint as the best way to kick off a project with our customers. We also got into the flow of starting new work with a sprint. So today I've probably done close to a full year (52 weeks) of design sprint type of work. We even had a kit we used to take on the road and I can proudly say that I've done design sprints in Sweden, France, Turkey, South Africa, Canada, Italy, Spain, and Serbia. In most cases, it was people's first pass at doing many of the activities involved in figuring out what problem we're trying to solve and for whom. But most importantly, work on a solution and put it in front of 5 people to validate if it's going to blend. My favorite moments in doing this work were when we started usability testing and people texting their colleagues to come and watch. In many cases, we were in the biggest bank buildings watching people interact with a version of their digital solutions. For most people, this was the first time they watched other people try to use the app they were building.
How to get there
For the last 10 years or so, I've been evangelizing human-centered design and interaction, but usually under the flag of User Experience or UX for short.
This has taken a lot of convincing at times and I know for many trying to influence the culture at their current project or workplace, it's the same.
So here is a list of ideas or activities that I'd like to share to spread this culture. It will keep evolving as I think of new things or remember old tricks that have worked for me in the past.
Know your stuff
Become an expert in the field, or in the case of Product Managers. Know enough to fake it till you make it. UX and HCI have grown into many specific avenues that have taken on memes of their own. Here are things I believe every Product Manager should be able to discuss over a pint.
Donald A. Norman is probably the first person to have the term User Experience on their business card. If you do not get annoyed by badly designed interfaces, service, doors, or teapots. Perhaps you are not in the right field.
A proven recipe for many of the design thinking, discovery, and validation activities packed into an intense 5-day program. My favorite is the last chapter which is packed with tips and tricks on user testing. There are multiple flavors of this workshop today including the 4-day version with all these insightful videos from AJ&Smart.
Hard to find one good link, but this is fine to get started if you are new to it.
In many engineering lead organizations that are successful. You actually find that the founders have been practicing some aspects of Discovery and Validation. Or they've just been lucky.
Persuading people to focus on UX is high effort and frustrating at times but I find that the proof is in the pudding and many people prefer different flavors of pudding.
The number one activity I have found that generates excitement and buy-in for this work is exposing people to user testing. Just recently I realized that some other people actually figured this out before me. This post on exposure hours from Jarred M. Spool from 2011 summarises it perfectly.
Many organizations are driven by revenue. That audience also likes to look at graphs from McKinsey.
People measured on success worry about time. I love to use this illustration from the Sprint book to frame that conversation.
A week spent understanding the problem, ideating and validating a solution can save you months of pain. You can quote me on that.
This can be tricky. If discovery and validation are not a part of your culture today. You need to convince someone to give it a try. Pick a problem or project where you can prove the value. This has usually worked out well for me. As long as you can demonstrate that developers not sitting in front of a computer coding, can actually lead to a better outcome. That is when the scales start to tip towards UX. If you are not in a cool UX lead startup but rather a well-established B2B with cemented silos. I have found that the Team topology book can be a door opener. Believe it or not, many companies are not what you read on those Medium blogs. Even Spotify is not applying the "Spotify Model" as many people think.
Get out and talk to people. Empathize and understand that most people are not like you. Try things, do your own user research and testing. Try things, try to make something that solves a deep problem. Be brave. One day, deploy something you are truly proud of and celebrate success. Because without celebration it is only work.
I'll put a dot here, but I'd love to get some feedback on this page as I intend to improve it over time.