In life, risk is all but inevitable. That’s just as true in our financial choices and daily work life as it is in our social interactions and health decisions. Whether we like it or not, every time we walk out of the house there’s some kind of risk involved.
But there are actions we can take to mitigate that risk. When we walk out of the house, after all, we don’t stride down the middle of the road hoping for the best—instead, we keep to the sidewalks to reduce any chance of collision. And when we go for a drive, we wear our seatbelts and make sure the car isn't running on fumes.
At Architech, many of the projects we work on also come with some kind of inherent risk. Part of our job, then, is recognizing that risk—and putting the processes in place to prepare for it. If there are unknowns or assumptions about your customers, end users, or the product space itself, you could be setting yourself up for failure if you move forward with an implementation amidst all those unknowns.
For risk-inherent projects like those, then, we always start by conducting research.
Recognizing and Assessing Risk
First up, what do we even mean by risk?
Put simply, we define risk based on the number of unknowns involved and the possible repercussions if something goes wrong down the line. To get to the heart of that, we start by asking questions like these:
- Who are your end users? What does their ideal experience look like?
- Would the project or feature require a team of designers and developers a lot of work to fix if our assumptions turned out to be wrong?
- Would an issue with a feature have a big impact on a customer or user’s experience?
The more unanswered questions or potential for catastrophe down the line, the more research necessary. Something like a bill payment function, an online exam tool, or a shift from an online portal to a voice application, for example, are all risky projects. That’s because they all come with a lot of unknowns about the problem space, the end users, or the technology itself. In cases like these, user research needs to be built into the project to various degrees. In contrast, something like a contact form has very minimal risk involved and usually requires little or no research as a result.
If we want to judge the level of risk by the amount of time and effort it would take to edit or redo a feature or product once it’s complete, we rely on the expertise of our engineers, designers, and product owners for these estimations. Judging the level of risk involved with your end users, though, takes more collaboration. Some situations might seem obvious—we know securing credit card information adds a level of risk, for example. But sometimes an entire product or feature presents risk—I wonder how much research the founders of Quibi put in before they blew $1.75 billion launching a product they quickly found out no one really wanted, forcing them to shut down after six months.
Other risks might not be quite so straightforward: Airbnb likely didn’t realize the negative impacts it would have on long-term rental markets in cities around the world, for instance, and I’d guess Zoom didn’t anticipate a rise in plastic surgery in its users after staring at their own faces all day.
The Difference Research Makes
Our goal is to anticipate any potential risks and design around them. But we don’t want to add tests and research components just for the sake of it, either. That’s why we design our research activities specifically around the project at hand, to explore and mitigate the potential risks that exist uniquely for that product. Some of the research tools we often call on include:
- Stakeholder interviews: Interviews help us ensure stakeholders are aligned and everybody is on the same page before development begins—giving us the opportunity to uncover research gaps that exist and unproven assumptions that need to be explored further.
- User Interviews: By talking to the people who will eventually use your product or feature, we can develop it specifically with their needs and usage in mind, uncovering different types of users and what they want and need to do with a product. These directions provide guidance throughout the development phase.
- Workshopping: Design thinking, discovery, and ideation workshops involve collaboration through carefully selected exercises that are crafted to help us understand the different problem spaces involved with a specific product.
- Rapid prototyping: Creating quick low-fi prototypes of features or flows and usability testing them with end users helps us ensure we’re on the right track in building a solution that will be easy to adopt and integrate into users’ lives.
Ultimately, research like this can help us recognize future problems—and save our clients both time and money later on. For example, we had a client who had developed an internal application for tablets, to be used by their warehouse staff on their job sites. But when we were brought on board, we learned that employees found the tablets awkward to maneuver—they would have found it easier and more efficient to use the application on a phone, freeing up one hand. A bit of research up front instead of post-development would have saved the work of reformatting the application for a different device.
Other Exercises to Draw On
Along with our more standard research protocols, there are a few out-of-the-box exercises we can draw on that will help us uncover potential risks related to your users and the impact of your product. Sometimes we’ll use exercises like these to get to the heart of your product’s risk potential:
● Black Mirror Brainstorming: With this exercise, we try to imagine your product as if it were the focus of an episode of the TV show Black Mirror. How could this product be twisted or go terribly wrong? Teams can have a lot of fun with this, taking hypotheticals to the extreme—but from those wild plot points can come real considerations on the impact of a product.
● Abusability Testing: In contrast with usability testing, “abusability testing” is about trying to figure out ways in which your product could be misused. So it’s similar to Black Mirror Brainstorming, but without the theatrical framework. We’re simply trying to find answers to the question “how might we cause harm to segments of the population with this product?”
● Tarot Cards of Tech: Tarot Cards of Tech are handy primers for discussions around various risks inherent to a product, depending on the industry. They’re great conversation starters in workshops or stakeholder interviews and can also be used to get the creative juices flowing during a Black Mirror Brainstorm or abusability test.
No matter what tools and techniques we draw on, the end result we’re aiming for is the same. We want to start the development phase with a clear understanding of what your users need, how they’re going to use the product, and where possible danger zones might exist.
In the end, after all, our goal is to build exactly what your users need the first time around—without any potential for unwanted surprises down the road.
Contact us at info@architech.ca to meet with a Tech Expert.
