When/Where/How do users use what they use?
A few months ago, I purchased a Nintendo Switch. At the time, this was a silly decision. You see, I’m the type of guy who loves the idea of playing games, but rarely prioritizes playing games. I love the games with long stories, deep gameplay mechanics, and 40 hour+ campaigns. The issue is this: I have a wife, four dogs, full-time job, multiple side projects, 2.5 hours of commuting daily, a sick father-in-law, and many other life-things that are more important than playing games. My game room already has a PlayStation 4, Xbox One, Wii U, PlayStation 3, Xbox 360, nVidia Shield, and a mountain of cobwebs, why did I also need a Switch?
I’ll tell you why: the Switch is designed to be played in the situations where I need it to be. Put more simply, the Switch is more suited to the reality of my life.
A Product Example
A few years ago, I released a web app for early childhood literacy teachers in Canada. It was a pretty simple web app intended to help them track student progress across a variety of traits. We looked at a variety of different user experiences that would “meet the requirements,” and prototyped a few. When we got the app in the hands of teachers, we learned a very interesting detail: every teacher needs the same capability (tracking student progress), but there were several different scenarios in which a teacher may have this need. Some of these examples are:
- One on one with a student after class
- One on one with a student during class
- With a small group of students (during or after class)
- Sitting at home with no students, recapping the day
There were several other examples, but the point is the same: it would be very easy to build an interface that didn’t work in those scenarios. Instead, we updated our interview script to get a better understanding of the situations in which a teacher would be making their observations, and the constraints associated.
At the end of the day, we figured out the primary context we wanted to solve for, but also learned enough about the other scenarios that we could put effort into not making something totally awful for those situations. Without question, this helped us build an app that was mega-useful at best and tolerable at its worst, rather than “meh” across the board.
Context Makes the 10x Difference
As I mentioned earlier, I love the lengthy single-player games with a focus on narrative. I have plenty of those games on other consoles, but most of them sit unopened in their cases. I don’t have multi-hour chunks to sit on my couch and game. What I do have, however, is an assortment of 15 or 20 minute chunks throughout the day. Due to this, the Switch is at least 10x more valuable to me than other consoles.
Now, 10x is a phrase I hate saying, but hear me out. For users to make a switch from one product or service to another, they need to perceive a 10x improvement from their current solution. Objectively, the Nintendo Switch is weaker, has fewer online services, has fewer games, has poor battery life, and a list of other negatives that other consoles don’t have. The reason why it’s my go-to gaming platform comes down to the contexts in which I’m able to play it, nullifying those other negatives and giving me the 10x perception that makes it my main device now.
This 10x perception is entirely due to context. For your product or service, the same could be true. There are some fantastic productivity mobile apps out there without a desktop or web equivalent. Objectively, these may be great tools that tick the “user requirements” boxes. Realistically, I’ll never be a user of them. Those app developers can look at my base needs from a feature standpoint and think that I’d be a perfect user for them, totally missing the point that I don’t “do work” on my phone on the go. For me, a web-based tool without a mobile app is 10x better than a mobile tool without a web app.
Wrapping Up
When you are building your product or service, are you taking user context into consideration? Do you know how, when, and where your target users are feeling the pain you’re trying to solve? Understanding this can mean the difference between a successful product and a bust.
If you’re looking for more information or want to have a chat about how you can improve your product process, reach out to me directly. I love chatting! Feel free to email at andrew@betterproduct.co, send me a message on LinkedIn, or comment directly here.
