User Research

User research is you talking to users and getting information from them so that when you're designing a product, you create something that people want. The short answer is, should you do it or not? No, and Yes. No, not in the traditional way that most people will tell you to do user research. We don't believe in that. We still believe in user research but in a different way.

First, let me give you some background and talk about some history of user research. This whole user-centered design and UX research revolution started about a decade ago. It began when people realized that their products are failing, and when they investigated why it turns out that people didn't want their work, they hated them. So they started asking people what they wanted before building the product, and they found that this is good for business.

This whole thing came from people who started going into user-centered design, which focused on the user because it was good for business. All things you know your swing back and forth used to be wrong where nobody talked to the user, and then five years ago, it became too much in the other direction, and the user was everything. Which we also think in the wrong order, and you should avoid doing that. The focus now is so much on the user. That it's ignoring the business, which is the wrong way to go about it, because in the end, what you want is for the product to be successful. If you prioritize the user to an extent where the product itself suffers, or the business suffers. You're not doing your job because your job should be to have a long-term product successful in the market. Suppose you prioritize the user over the business and not worry about aligning those two together. You're going to go out of business, not what your users want your user wants you to be in the industry as long as possible.

Design Sprints are the best way to do User Research

We believe the best way to do user research is by making design sprints. There is a bit of controversy here because some people think creating a design sprint means skipping user research when it's not the case.

Design Sprints are a form of user research. What's different about it is you are putting something tangible in the user's hands instead of just asking them hypothetical questions. The most important thing about a design sprint is the learnings you get from the users. It's not the prototype people think it's the prototype, but the prototype is thrown away; it's not what you care. You care about all of the feedback and insights you get from talking to the users when you show them your prototype and knowing whether they care about your idea. That's why we think design sprints are the best form of user research. The only real user research you're going to have is once you launch your product, put it into the market, and know whether your customers want it. Still, suppose you're going to have some research before that. In that case, it's best to get as close as possible to having a real product in your user's hands. You can get more realistic answers, and the way that we found to do it real fast is making design sprints that way, you don't spend a lot of time upfront. You pay only less than a week. You put a prototype in front of your customers. You get much more realistic feedback than going out into the field and asking them about something that they haven't even seen, so that's why we think design sprints are the best way to do user research.

Design Sprint (Client on-boarding / research questions)

The first thing we do is prepare a form for everyone joining us from the client-side to fill out. We send a way for them, and we start with a question:

Question 1: What are the top two things you'd like to get out of the Sprint:

Validate ideas and prioritize features.
Increase user engagement of existing products.
UI design.
Increase user activation.
Monetization of a new or existing product.
Clear vision and direction.
Defining what the USP should be.
Prioritizing the project timeline and agile backlog

This is for us to know what they need and see if everyone on the client-side is coming with the same goal. You'd be surprised how many times people are coming in with different assumptions, different purposes, different expectations.

Question 2: After the Sprint, the next step is this project is:

Get further buy-in for the organization/stakeholders (to greenlight & finance the project). It might be an idea that you know a couple of people have within a company, but they don't have a budget. Hence, they run a sprint because they can do it fast and without investing a ton of money into developing a product. They get validation for it, and then they can show like the prototype and the user feedback to their bosses and get permission to run with this project if they've already decided that they know for sure. Maybe they already have a product on the market, and they have the data that tells them they should be building a specific product.
Pass the Sprint outcomes immediately (prototype and testing results) to another internal team to keep making progress in the project (e.g., design team, marketing team, content team). They like the prototype to an internal team that keeps working on it.
Go into a development team to start execution. This is rare. Sprint doesn't take care of the whole design, but sometimes if you run a couple of Sprint's back-to-back, you can go into development after the Sprint.

We asked this question so that we can tailor the report that we

give them at the end. If we know what is their next step. The Sprint is so great at giving you momentum and just having a great start, and we want to help our clients carry that momentum throughout their work on the product. We ask them what the best way for us is. What is the best format? What are the assets? What are the most important things that you need to get out of the Sprint and plug right into the next step so that you can continue just moving fast and iterating?

Question 3: Looking ahead at what you have planned for this project, please finish this sort of sentence:

"In two years, our product/service will be...."

We ask them to fill out, you know, to complete that sentence.

Question 4: Who is their target customer/user?

This helps them understand who was designing for, which is crucial and super important. They give us an excellent description of who their users are. Is it a B2B company? Is it a B2C? What is age group are the users who primarily are on mobile or still on the desktop? For example, a B2B solution that service reps use or something like that. This helps us put out a form to recruit users before we start the Sprint once we know who the target customer is.

Question 5: Who their most significant competitors?

We can also take a look at the market since we work with companies from various industries. Not just the tech industry. We ask them who are your base competitor is, who do you want to beat, and take a look at their solutions before the Sprint. Therefore we're informed on what that market looks like.

Question 6: Name 1-3 companies/products that inspire you, and you would like to emulate your product?

We can incorporate some of that design into the work because this is something that they want to emulate. So if you like apple, and you like their design values of just being minimal, straightforward, and clear. That helps us a lot in knowing how we're going to design the prototype for them. What kind of you know aspects, values, or elements we can borrow from other design systems or other companies.

Question 7: What are some ideas/directions that you'd like to explore during the Sprint? Maybe something that you've wanted the company to try but hasn't had the chance?

Many people who work at companies get constant ideas about how they can improve their product or service. They don't have the time. They don't have the resources to try these things out, and they want an outlet to try and see. The Sprint is the perfect vessel for this, for them to like play around and test out their idea.

Question 8: Are there any documents you would like to share with us because they are relevant for the Sprint?

Sometimes companies have already tried to build something and maybe if they've designed some internal prototype. Before they've come into the Sprint, they've explored an idea, and they want to explore it further. It's beneficial for our team to have that context and know if this will be what we will be working on. If we're going to be continuing down a direction that they've already started.

We asked them to share that, but we say this is not mandatory. You can share this if you have it. That's the form that we send to our clients, and everyone on the client side who will be joining this print has to answer that. We can get the best possible picture of their business before we start the Sprint. After we have all the answers from our client's form, we schedule a few calls, maybe not with everyone from the client-side but definitely with the decider and maybe one or two extra people that the decider recommends we talk to before the Sprint.

Now that we have the answers from the forum that they submitted, we get on a call to go more in-depth and have the decider precisely explain how their company works, how their existing product works, or the new product they want to be working on. It's going to be, you know the business model for it, why are they going into this in the first place, do they have specific targets that they want to meet, and how does the industry work in general. This conversation is super valuable. The form doesn't go deep enough, and it's just better to have this out all on a call because it's much easier for the client that way. We're then taking notes during that call to share with the entire team from our side.

After done with that call, we go out with all the information we have, and we start looking for some Lightning demos that we're going to show off during the Sprint during the Lightning demos exercise. We begin looking for solutions within the industry and outside the industry that might be relevant in interactions.

For example, if it's going to be a two-sided marketplace, uber could be an example because you have the driver's side and the writer's side. Then once we're done with that, we move on to preparing how we might questions. Those would be questions that we want to ask everyone in the room and answer during the expert interview section. Those are usually super good for us to know more about the client's business. Maybe stuff that came up after we talked to the decider, or if we want to hear from more people on the team who we didn't have calls. For example, someone in the customer support role, or the marketing role, can see their perspective on the problem. That does it in terms of the preparation that we do before this Sprint.

Realtime Board - User Research / Testing Feedback

The last thing I want to show you in this video is capturing notes during the user interviews. We use Miro and other devices to do the same, but we are comfortable with this one, and we like it.

I will show you our template that we have set up in Miro for every Sprint. So this is the template zoomed out. What we're going to be focusing on in this article is this little thing right here. Our second Sprint is usually made remotely, not in person. We use Miro for our iteration sprint.

We're going to be focusing on this section called Week 1.

This looks like the wall of justice, which is explained in the sprint book, but we have it in digital form to be searchable and much better for sharing with the client. We have it set up because we have five columns, one for each user that we're going to be testing with on Thursday. We have the rows that usually correspond to the screens we have in the prototype, such as the welcome screen. Then the onboarding, and sign-in screen, and all of that. We would rename all of these to the name of the screen.

In the beginning, we have a few primer questions to get the user comfortable. The context of what we're going to be talking about is watching the news. Then we would ask them, "okay, how do you currently watch the news" and "what apps you use. "

We have like this kind of coloring system so that when a user says something good, we use a green note when they say something that's not that they don't like about our product, we use some an orange note. We copy and paste these. Just like any other design program, you know if you option drag, then you copy it. Hence, what we do is we make a few copies in the beginning, and then as they're getting feedback, they say " something good," and they say, "I don't like this," and this is how we capture feedback going through the Miro.

In the end, we ask them a few questions. Once we've shown them all the screens, we asked him a few questions to round it out we ask "what did they like?", "what didn't they like?" "what would they change about this product?" and "how disappointed would they be if they couldn't use our product?" then we asked them for a rating. Finally, we have a yes/no summary of the Sprint question, so here we pasted in the Sprint questions that we decide at the beginning of the Sprint. We say, "For this user, is the answer yes or no" for this, can we question.

User Research (Design Sprint Test)