Stampede offers various solution services to address client’s problems, across the world and Malaysia – one of them being service design, to address problems pertaining to workflow beyond the digital realm.

At one point we were conducting research for service improvement of a client from the energy industry, and we investigated one of the touchpoints where potentially lies area of service efficiency improvement: the “request form”, a product that serves as the single channel for requestors to assign designers and resources to their projects. The most logical way to proceed with this investigation would be conducting usability testing, to detect areas for improvement of the form itself and reduce user frictions within it. However, limiting ourselves to a singular research method will risk us missing the insights of a bigger scope that may correlate to the problem or even be the cause of user’s woes.

What happens if we are more open about the scope of the outcome, where we are still bounded by the limitation of problems we need to address at the moment, yet receptive to deeper underlying issues including ones that are outside of assigned scope? That will enable us to solve the right problem, and we tried to achieve this by employing the hybrid research methodology, which in this case usability testing is combined with user interviews — where product testing is still prioritised, yet we open up to discoveries of bigger problems to be addressed.

Here are some of the learnings from the hybrid research method:

1. Getting the most out of the research session without spending additional time and resource

Our initial plan is to only conduct usability testing on the request form, which is merely one of the touchpoints in the whole service and was assumed to be the main point of friction by the client. But we believe that in order to really solve the issue, we need to see the bigger picture, get a clearer understanding, detect the areas needing attention and address the correct problems.

How do we do this, without additional time and resources allocation to investigate the matter?

Every research method can only cover a limited scope of results. Usability testing, the main method we need to use, can only provide insights within the test product’s confine. For broader discovery, we will need to use the user interview method before conducting the usability testing, but we thought that we could employ a more efficient approach.

From there we got the idea to combine them in the same session. In this project’s case, the product that we need to test does not contain too many flow, tasks and screens — enabling us to fit in the user interview components wherever relevant. This is a chance we saw where we could maximise the research outcome by saving the time and resources needed should we choose to do it the other way in order to cover different scopes of results.

2. Additional findings can be obtained organically by being more contextual in the research session

As explained earlier, we wanted to probe into the issues outside of the tested product to understand the service side of the matter and the correlation between them. However, the nature of questions for these two scopes will be quite different; asking them blatantly without consideration will affect the session and responses from users as the questions will be seen as coming out of nowhere and causing a mental load due to not anticipating them.

How do we organically ask the questions outside of (product) scope?

To make the session flow coherently, we strategised meticulously on where to ask the usability testing question and when to ask the questions outside of the product scope, with dependencies.

If we want to ask the users more about a certain topic that is out of the tested product, we ask them when we arrive at the relevant section in the prototype. For example, we want to investigate where the user gains awareness about the product (responses could vary outside of the tested product’s confine), we may ask them about it on the prototype’s landing page, not on the screens that is more specific to tasks.

Being organic in the question flow is important, to get the right answer at the right moment and make it feel less scripted. Putting more effort into strategising this will yield better responses from the users and obtain results efficiently.

3. Insights gained will be richer and open up bigger opportunities for consideration to be addressed by stakeholders

By opening up to a mixture of research methods, researchers also open up the avenue to explore beyond the supposed research outcome from a singular chosen method. This will enrich the insights gained further, providing more value to the stakeholders who placed the investment towards the research — be it in effort, time or monetary form.

Problems of varied scale and spectrum can be found out in one go for consideration, on which issue to prioritise at a given time. To take this case’s example, the usability testing findings about the form are actionable in the product domain and could be solved for a short-term remedy, but our discoveries beyond that (on the service level) have given the stakeholders a greater vantage point on issues in a bigger scale, to be solved in the long run.

But caution must be exercised on scoping the outcome to be investigated, be wary to not dilute the research result and to make them viable to be addressed for all parties involved.

Lessons Learnt

Any research methods — be it usability testing, user interviews, or surveys, they ultimately serve only as the means to get what we are targeting. By clearly outlining the desired outcome and being more open to how we approach the problem, we will be freed from the confine of usual practice on conducting the research and know better when or where to utilise the methods. One may even combine them, by not strictly married to the method’s outcome but by adjusting the method to get the desired outcome. This will enable us researchers to make full use of the scheduled sessions with the users, to get the most out of it and ensure the utmost efficiency is being met.

Efficiency is the crux of us researchers, as not everybody sees the value behind the activity as much as we do. Delivering them within the constraints of time and resources is one of the ways to maintain stakeholders’ confidence in research, supplemented by the apparent impact of the insights gained and the value brought upon through it.

The post Application of Hybrid Research Method to Uncover the Right problem appeared first on Stampede: the strategic design & technology company.

What do we ask?

The first step of finding a solution is making sure you have the right problem. This is where you have to sieve through a lot of information and noise with the hope that the there’s a signal at the end of line. There are several ways to do this, including user research, interviews and workshops. Throughout these sessions, you will have excellent opportunities to dissect a business and ask questions as an outsider looking in.

With so much to ask, how do we know which are the right questions? As a rule, we avoid asking leading questions such as:

• “tell us what you need”
• “will exporting to Excel spreadsheet work for you?”
• “would you like to have a white or black dashboard?”
• “what do you think about this feature?”

Doing so will result in only cosmetic solution that doesn’t solve the real problem. It will not lead to a transformative result that will create the impact your client is looking for. It is hollow and you, the designer, know it.

Instead, we try and ask questions like

• “what are problems you face when performing this task?”
• “which information helps you make more informed decision?”
• “what is the goal of your task?”
• “how does achieving that goal contribute to your KPI?”
• “who do you rely on to accomplish that goal?”

This helps re-frame the discussion from being feature-oriented to being user-oriented. After all, we’re not designing for system. We’re designing for people.

Who do we ask?

At Stampede, we start asking preliminary questions very early on in the client engagement to get an idea of the complexity at hand. We then develop loose hypothesis to help guide the early stage discussions.

The peak question-vaganza though happens during our UX workshops, a joint focused session that can last between 1-4 days depending on the complexity of the problem. This is where we bunker down with our users and stakeholders to gain clarity on the right problem and validate our hypothesis.

If you don’t have access to the end users, the customer-facing team is the next best thing. They are the front-liners who deal with the end-users the most.

They mitigate frustrations, troubleshoot issues and work with the end users day in and day out. Having them join your discussion will reveal things about your users that sometimes even the CEO is unaware about.

“But these users don’t know what they want!”

We hear this often, especially in organizations where there’s a deep-rooted culture of supremacy over users. The truth is, the more you practice UX, the more you realize you don’t know things. And that every UX session with the users are accelerated learning process for the UX designer, not the other way round.

I think the users know a great deal about the problem they’re facing. They may not know the solution to the problem but then again, it’s our job as UX practitioners to design the solution for them.

Many of us however are not equipped at asking them right questions. Nor are we willing to, if it will upset the way we have always done things.

Guiding principle check

This is where your guiding principles will help you decide. Ask the right question, and you will get closer to the right solution.

Keep asking the wrong ones, because it’s easier and comfortable to do, and you might end up delivering the wrong solution. In doing so, the client would have wasted their money and time—they just don’t know it yet. It’s akin to applying a new coat of paint to a crumbling house—the people outside is impressed by the new façade but the people inside had to cope with the danger of their roof collapsing.

You’d also rob the user of the experience of enjoying a task because they will continue to serve inefficient process and forced to learn using new interface with every “redesign”. And the redesign will keep coming because the problem is never really addressed.

It’s the same circus, just different hoops.

Asking the right questions

At Stampede, we ask questions a lot. You don’t have to prompt us “any question?” because we will keep asking until the session ends or someone stopped us. Our team appreciates curiosity and inquisitiveness big time. We believe that to ask good questions, you first have to ask A LOT of questions. And then you wait for the Law of Averages to kick in after your 100th questions, and then you learn again and that’s how you get better at it.

The good news is, we already have it in us to ask the right question. Asking the right question help us guide our mental exertion towards a worthy focus. We’re not solving superficial problem, we’re solving actual problem affecting real people. For a designer, the power to do this gives us a glowing wholesome feeling. I still get goosebumps when this happens.

Asking the right question takes some experience, but I have learnt that a good listening skill expedite that fairly quickly. When you start a UX consultation session with client, walk into it thinking “I have so much to learn from this” and you will find yourself a better listener. You will start using questions as a tool not to lead the outcome in your favour, but to encourage clarity and design-thinking in everything you touch.

Make it count

As UX practitioners, we have the time, the skills, the team and the resources to make this happen. We can solve users and organizational problems through design-thinking and have it ripple across the board. It will touch so many more people than we originally intended too.

Imagine an engineer enjoying his work more now that he won’t need to wait anymore for an Excel macro to run for an hour before spitting out results needed to start his day. Heck, he will now achieve his daily goals with time to spare. Everything he needs to make a good decision is at his fingertips.

In return, he can pay closer attention to the critical aspect of his job because he knows he now has the right and timely tools to solve his problems.

Perhaps when he drives home, he drives better because his mind is less occupied with problems to solve.

And perhaps he is happier to arrive at work the next morning because he knows his skill and expertise are going to be spent being fully productive, making positive change to his organization.

And because happiness attracts, perhaps he will influence others like him to always be looking to continuously improve things. And they in return will influence others like them. And their organization will pave the way for others in the industry to follow.

Goosebumps?

The post The Users Don’t Know What They Want, or Do They?—Asking the Right Questions for UX appeared first on Stampede: the strategic design & technology company.

In UX Research Part 2, we shall take a look at one of the biggest questions that we had been asked: how do we know which methods to use, and when to use them? 

To make this easy, I shall elaborate on the common methods we use based on three phases of UX project:

• Research
• Design and development
• Deployment and maintenance

Research

If we are about to define who the users and customers are for our product, there are several ways to find out:

Survey

Survey is one of the cheapest ways to find out who the users and customers are since most of the survey softwares out there are mostly free or affordable, and in next to no time you can whip something up and start gathering feedback from real users. Implementing the survey is the easy bit, the tricky part is preparing the questions as you won’t get the feedback you’re after if you don’t ask the right questions. Some examples of good questions would be:

• How did you learn about product X? Why did you decide to use product X?
• What were your goals when you started using product X? Did product X meet your expectations related to these goals?
• What are the the most frequent tasks you do using product X? Explain how you do these tasks (step by step)
• What other products do you use to accomplish similar tasks and why?
• When you are using product X, do you find anything frustrating that you wish was easier/different?
• Is there anything that you wish product X allowed you to do that it doesn’t allow now?
• What comes to mind when you think about product X (how would you describe it to a friend)?
• What do you like the most/least about product X?

You may find some other examples of good questions here in UX Stack Exchange, but bear in mind that the questions you prepare need to adhere to your specific set of users, otherwise we are not getting the feedback that is valid.

Persona

A persona by definition is a representation of the goals and behavior of a hypothesised group of users. What functions do they want, and when in certain stage of decision do they care the most? Think beyond gender, income and age, and look to tasks and domain experience as key differentiators. I have written about how to determine a user persona in a previous Stampede blog post.

Competitive Analysis

“Competition brings out the best in products and the worst in people.” says American businessman and pioneer in radio and broadcasting, David Sarnoff. Competitive analysis in UX context is a method for identifying the strengths and weaknesses of competing products or services before starting to work on our own prototypes. Here’s a good guidelines on how to conduct and prepare competitive analysis report.

Stakeholder Interviews

Stakeholder interviews are conducted with the key stakeholders of the organisations for the product: this could include customers, bosses, subordinates, or peers both within and outside the organisation. The interviews allow you to step into the shoes of your interviewees and see your role through the eyes of these stakeholders, which should answer the questions, “What do my stakeholders want from me? What do they need me for?”

Usually stakeholder interviews should provide enhance clarity on how your work as the UX team matters from their viewpoint, how they plan to assess the outcome, as well as identifying barriers and ideas to improve the situation.

Task Analysis

Task analysis, as defined in Interaction Design Foundation, is a simple and effective process for laying out tasks from a user’s perspective. It is sometimes also referred to as “user scenarios”. It is close to a creating a user story as defined in agile methodologies.

This approach helps you avoid the mistake of automating the frustrations that already exist or repeating past mistakes. It gets you to the bottom of what the user will want to do and the simplest, most effective way of doing that. One of the key challenges when conducting task analysis is to let go of what you already think you know and allow the user’s needs to guide the process instead.

Design and Development

As we have moved on to design and development phase, there are several questions before we move on to build final products:

• How will the interface look like?
• How effective will it be?

In Stampede, we use wireframing and prototyping approach to showing clients how the interface will look and function before we move on to design the final product. Ensuring that it works as intended for the target users in the minimum viable product (MVP) stage before we move on to the next phase, would save a lot of time as there will be only be minimum tweaking on the wireframes and prototypes before we finalise.

Wireframing

A wireframe generally is a skeleton of a page, showing the priority and the organization of things on the screen and how users will get to other parts of the site. While wireframes will vary in their level of detail, they reflect the designer’s ideas about the placement of elements on the page, the labeling of elements, site navigation, and how the user will interact with the site. Wireframes are usually shown to the clients during the early phase in design, ensuring that all parties involved in the UX project – designer, developer, client – are all in the same page about what should be in the interface.

Prototyping

A prototype can be defined as “a simulation or sample version of a final product, which is used for testing prior to launch.” The goal of a prototype is to test products (and product ideas) before sinking lots of time and money into the final product.

Prototyping is essential for resolving usability issues before launch. It can also reveal areas that need improvement. Once a draft of your product idea is in the hands of real users, you’ll finally see how they want to use the product. You can then go back and adjust your initial guesswork.

There are a number of prototyping tools for non-coders out there that turn images and sketches into functional, clickable screens like Axure, Sketch and Balsamiq. Your pick!

Deployment and Maintenance

Now that everything is functioning, it is time to understand how usable the product it is as we release it to our clients or users.

User Acceptance Testing (UAT)

As we adopt agile methodology in our UX projects, UAT is conducted by preparing a series of test scripts detailing functionalities and objectives according to user stories. The document is then presented to the client to conduct the testing, as well as to log the notes of defects. At the end of the UAT, the tests are compiled, assessed based on severity, and assigned to the team.

There are many ways to do UATs as well as adapting the UAT template to your liking. We personally use Google Spreadsheet as it is easily accessible to everyone, but if you have quite a number of testers, I would suggest to use tools to conduct UAT. Tools like EngageUAT have been receiving good reviews, so we look forward to try it one day!

Usability Testing

There are two ways to conduct usability testing post-launch: moderated and unmoderated.

In moderated setting, users are to attempt tasks under the watchful eyes of observers. These observers shall record their reactions to using the website or product, as well as encouraging them to voice out their opinions, whether pleasant or unpleasant, loudly. However, the observers are not to tell them what to do – instead, just watch as users interact with the product and record them.

There is an easier way to do this through unmoderated setting. Users can now attempt tasks remotely while we record their behaviour using tools such as Hotjar, UserZoom and UserTesting. Decide a goal, start recording, and watch results from dozens to hundreds to users in the same day.

Comparative Benchmark Study

Comparative benchmark study is what we do when we ask users to perform the same tasks in the products we built against other products mentioned in the competitive analysis. We would define some core metrics to be compared and tested between our products and competitors’ products like completion rates or checkout time taken and assessed the strengths and weaknesses in of our own products.

A/B Testing

Being Stampede, we are always trying to improve on things, for example, what would happen if we do enlarge this button or move it to the left – do you think it would affect user experience? As design and improvements don’t stop upon releasing, our rule is this: don’t guess, test. However, we do take into account of if time and budget allow us to further experiment, otherwise, the improvements are done gradually, subject to the clients’ approval.

Can you tell us more about the tools?

Now that there is a simple guideline on which UX methods to use in every phase of UX project, you might be asking – there should be tools to improvise each and every method, is that so? The answer is yes absolutely! We shall take a look at these tools in the Part 3: UX Toolbox.

What are the methods you often use during your UX projects? How have they helped you understand your users and build your products? What have you learned? Tell us about them in the comments section!

The post UX Research Part 2: Which UX Methods to Use? appeared first on Stampede: the strategic design & technology company.

Were answers provided to our questions? Not quite, because we doubt the reviews but we’d love to watch it anyway. So we set up expectations, or metrics – that if something happens or does not happen in the movie, then it’s going to be good. So we go. It ends up making us feel good. Hypotheses proved, metrics met.

In this case, we are the end user. So it is easy to conduct research based on the persona we know best – ourselves. But what if we are taking someone on a date to see the movie, whose favourite genre is entirely different from ours – and impressing him/her is paramount?

The scenario is no different in the user experience (UX) when you are building products, services, applications and websites for people who are intended to use the website, and whose opinions and impressions matter.

In UX, research is important to ensure that we are designing it for the users, instead of ourselves. The formalised research is called UX research, which helps us identify, prove or disprove our assumptions, recognise their needs, mental models, their pain points, challenges as well as what unites them together towards the common goal of using the product. Essentially, research shall add information to our work, improves our understanding and validate our decisions.

How do we start?

Created by Erin Sanders in this article, the Research Learning Spiral provides five main steps for conducting UX research. The first two steps are about forming questions and hypotheses, and the last three steps are about gathering knowledge through selected UX research methods.

1. Objectives. What are the knowledge gaps we need to fill?
2. Hypotheses. What do we think we understand about our users?
3. Methods. Based on time and manpower, what methods should we select?
4. Conduct. Gather data through the selected methods.
5. Synthesise. Fill in the knowledge gaps, prove or disprove our hypotheses, and discover opportunities for our design efforts.

There are many ways to do UX research. The most important question is: how do we frame it within many other factors? These factors can include:

• The end goals of the product – both from business and users’ perspectives
• Time constraint
• Accessibility (to information, users, stakeholders, decision makers etc.)
• Other limitations

The first three are the most common factors we encounter in Stampede. In taking considerations of these factors, we work closely with clients to ensure that we get as much information as possible in the research stage before we begin in the UX designing phase.

The end goals of the product

When a UX research does not take place…

For example, after 3 months of launch, they’d like to see the sales increase 300%.

For strategists, this is an important thing to note – as we can reverse engineer our way in finding out how to increase the sales by 300% through a number of methods, which should be specified in research.

Secondly, the most important thing is of course, to consider the needs of the users. For example, by the end of the process, the client should be receiving testimonials as how easy it is to use the website now. Other ways to measure this expectation is also to install heat map analysis tools for your websites such as Hotjar, Crazy Egg or ClickTale.

The tools on UX shall be explained later in Part 3.

Time constraint

As much as we like to talk to as many users as possible and take much longer to conduct research, most of the time we do not have that luxury.

Typically, user research stage in Stampede takes place for the first two weeks after a UX project kicks off. At this point, as we work closely with our clients on securing the business and user end goals, we also narrow down the best methodologies as possible to fit in the timeframe.

For example, in the course of two weeks, it is quite impossible to conduct a physical workshop involving the main stakeholders who are scattered all over the country. It takes a lot of time by itself for the arrangement and logistics, let alone preparing and conducting it.

So what do we do? In the research stage, we ask the clients…

• … for the contacts of key primary users we can get hold of and ask them for time to do usability tests – depending on accessibility arrangements, if any (see next point)
• … if there are existing products they like, and we do comparison reviews
• … if there are existing data of users we could take a look – users statistics, testimonials, dev site links, wireframes etc. Every data should come of use.

We shall talk about knowing which UX methods to use later in Part 2.

Accessibility

Another factor to take into consideration before starting on the UX research journey is to find out the accessibility of the key stakeholders. These can be:

• The decision maker from the client side – most likely the product owner
• How accessible we are to users if we intend to interview or do usability testing?

Other limitations

When we talk about user experience we often forget about the most important thing: the user’s experience. Too often we are so obsessed with clever solutions and stunning visuals that they completely ignore the fact that their users won’t care about it as long as it works. This is why limitations are key to great UX. The odds of achieving a clear and understandable user experience are way higher if you limit yourself and the features of the product you’re designing depending on the users’ needs.

Other limitations that might surface before you start on UX research would be:

• Scope given by client. There are clients who are lenient about us experimenting and suggesting, but it is always good to check with them every single time.
• Client approval
• Other items that might have been mentioned in Non Disclosure Agreement (NDA) e.g. the limits to how accessible the current site data might be, their users or disclosure of current information etc.

All of these can help us to narrow down how to begin our UX research and determine which methodologies to use in the next stage.

What’s next?

Now that we have established the factors that will help us to move to the next stage, here’s one thing to keep in mind: the biggest mistake a UX strategist can make is excluding end users from the process. Start the design process by including the users from the start, listen to their disappointments, pain points as well as what makes them happy – not only while using the product, but also understanding their mental model in general.

In conclusion, UX research is a very interesting process in a sense that it helps us avoid our biases since we are required to figure out solutions for people who are different from us.

What factors have you considered before you embark on a user experience research? Share with us in the comments section!

There are a number of popular methods used in improving the user experience at all phases of research and design. We shall take a look at some popular methods and when you should use them in Part 2: Which Methodologies Should I Use?

The post UX Research Part 1: How Do We Start? appeared first on Stampede: the strategic design & technology company.