As a user experience design firm, it’s no surprise that we are proponents for understanding the end user before creating any framework or wireframes. How can we possibly design a system if we don’t know anything about the people using it? But user research isn’t the only thing we do before we put pen to paper (or mouse to computer).

We also spend time understanding the industry your solution will live in. Whether it’s finance, insurance, or military; we require a firm understanding of the expectations, standards, and regulations we must follow to create a successful experience. In other words, it would be nearly impossible to play a baseball game if one team didn’t know the three-strike rule; the other team would just get frustrated and quit.

If you don’t know the rules, you can’t play the game (well).

After years of practice, we’ve learned how to immerse ourselves in an unfamiliar industry and quickly increase domain knowledge. We attribute a lot of our success—in solving tough problems in complex systems—to this skill.

How do we increase our domain knowledge?

As a company, we have a few go-to methods we use before sketching a concept or creating wireframes. Here are our favorites:

We immerse ourselves in the user’s environment and participate, if possible.

Compare this to when an actor is preparing for a large role, they may completely transform themselves into character for months at a time before beginning the filming or performance process. This allows them to experience and understand the character’s environment, thoughts, and emotions.

Experience and understand the character’s environment, thoughts, and emotions.

Without going to such extremes, we do something similar by putting ourselves in the environment of our users. We, essentially, become who we are trying to design for. As an example, when we designed a gambling application, our team spent time at the track learning how to place bets on our favorite pony. We were able to experience the entire environment—sights, smells, sounds— with avid users.

We, essentially, become who we are trying to design for.

We talk to you and your customer support team.

You are the expert. We want to learn from you, pick your brain, and soak up as much as we can. We also want to know where you go to educate yourself. Where do you find industry news? What are the most credible sources?

It’s also highly valuable to spend time with customer support; they are solving your users’ issues every day and understand what people think is hard, confusing, and frustrating about your product.

We learn from your competition.

Using the competition’s product gives us a chance to experience their solution firsthand. What are the similarities? What are the differences? How do they talk to their users? How do they handle errors, help, and onboarding?

And let’s face it, sometimes the competition figures things out first. Not only can we learn from them, but it can be a trigger to do some self-reflection and may be a good indicator that we  need to revisit your users to acquire more insight.

And let’s face it, sometimes the competition figures things out first.

We use Google.

Yes, this may seem obvious, but it’s an easy place to start. Plus, we have the white papers, journals, blogs and other sources recommended by you to jumpstart our research.

The push to continuously learn is what I’ve found to be one of the most rewarding things about working in this field. It’s fun to be curious, expand my knowledge, and learn from people who have differing perspectives and expertise. It also increases my empathy for user problems and in turn, gives me the guidance to produce a successful product. I wouldn’t be confident that I’m putting my best work forward without taking the time to understand the industry I’m designing for.

Check out these links if you want to read more about the domains we’ve worked in: military, agriculture, online gaming, heavy duty trucking.