—

Well, we shared a little about the event orchestrations in the previous blog. Now, let’s focus on the next part.

We attended the workshops on Day 2 of the Focus Days and also talks on the latter Conference Days. Following are the breakdowns of our learnings there, in separate POV formats to cover our different experiences!

Day 1: The Workshop

Day 2 of the Focus Days portion, was our Day 1 — the workshop day.

All the workshops were very useful and interesting and we were keen to join all of them. The topic ranges from soft skills development like negotiation strategies and UX influence, to the craft-oriented ones like eye tracking and service design. But alas, our time and resources are limited so we need to choose really well which one to attend!

We needed to make full use of this opportunity, so we deliberated in-depth on which workshop to be attended by each of us. Factoring in the relevance of topic with our domains, strength, future project and function considerations, finally we settled with:

• Me (Sarah): Soft skills for UX professionals by Prof. Clemens Lutsch, Claudia Bruckschwaiger & Hanna Köhler
• Azim: Service design and UX – a conversation by Eric Reiss

On to the learnings we obtained from these two workshops!

In Sarah’s perspectives:

In this workshop, the speakers, led by Prof. Clemens Lutsch, divided us into several groups consisting of multiple hats to allow us to see different perspectives from different roles.

We were given some activities to increase our self-awareness about our own capabilities. To top it up, the speakers then provided some input about how these capabilities have been useful to our lines of work. We were then given an assignment to role-play based on several scenarios. These scenarios were to mimic the real life situations on how we adapt to different kinds of challenges during communication.

The outcome of this workshop emphasised that our technical skills are just medium to execute, but in order to be successful in design, there are many other soft skills that we need to master, and they are not easy and that practice is all it takes to succeed. There were 3 categories to these soft skills, being communicative, social and personal soft skills.

Communicative soft skills revolves around the way we designers communicate with the people we interact with. This includes our business or product team, our developers, and our designer peers. Examples would be the negotiation skills, active listening, ability to abstract, linguistic fluency, or ability to enthusiasm.

Social soft skills on the other hand would be on how we are dealing with the interactions with our team, like resiliency, emotional intelligence, conflict resolutions, diversity competence, or even ability to cooperate. Do you see the difference from communicative skills?

Personal soft skills is all about the core supporting your work executing. These skills revolve around the how behind you are executing your tasks or job, like analytical skills, decision making, creative thinking, strategic thinking, self reflection and willingness to learn. Whether or not you realise it, we pretty much rely heavily on these skills in your day to day work. It makes our executions more human and user-centric.

My take was around the communication area (that includes conflict resolution, influencing, negotiation skills, etc). We heavily practice this in Stampede, and it does not get any easier because you definitely don’t experience the same situation every day. We work with people from different industries, priorities and personalities. It is all about us versus the problem!

Azim’s Point of View:

Relevant to my designation as a UX designer, I enrolled into service design workshop by Eric Reiss of FatDUX. I had no prior deep knowledge about the details of service design works at this point of time, which makes this workshop such a pivotal moment for me to realise that services are everywhere – and they can be designed.

The workshop was filled with lessons that Eric himself has gained throughout his life and related them to the UX design or service design domain. One simple example, Eric told his personal story of cat food catering to “customers” (himself as cat owner who buys the food) rather than the “real user” (his cat, who didn’t appreciate green peas in the cat food) and the story of great service nuances provided by the hotels he stayed in during vacations, each of them provided the audiences with clear examples on how even the minuscule details can affect user experiences.

Those were the personal touches that Eric had throughout the session, but being a workshop that is geared towards service design, naturally there are technical lessons being passed down.

Some of the discussed methods and tools have already been incorporated into our practice in Stampede — like the how-tos of user interviews, building user persona, or ways to design effective surveys. Strengthening the fundamentals is always great as a starting point and further validates that what we have been practicing is on the right track.

However, plenty of methods and tools presented were new to me (or even to anyone in Stampede) that brought massive value out of this workshop.

The Service Star provides a clear visual on areas to be focused for the service provided, either for the company we are evaluating or our own service. A star-shaped spider chart would be ideal, but that would be an extremely rare (or even impossible) case where the service provided is perfect. On the service provider side, they would be able to gauge which areas to be improved and maintain the performance.

The ergonomics of need can outline users’ perspectives in clear metrics to detect which part of the service could be focused upon. The outcome will also prepare the service provider for what kind of situations they will face when dealing with customers (eg: when the attitude and expectation are already negative to undergo the task, how can the service provider handle the situation in the best way?)

Aside from the typically-used customer journey map and touchpoint matrix/service blueprint (which often end up being too convoluted and needing massive effort to be understood by people who don’t follow the process), FatDUX have their own framework of communicating the outcome better to stakeholders — the service-experience scope sheet. By filling in this sheet with the details and touchpoints involved, it will communicate the design clearly, outlining the factors and actors involved in the service, with a clear demarcation of the period in service.

There were many learnings to be unpacked and relayed to the team for us to improve our service design practice. This avenue is waiting for us to explore structurally as some of our recommendations when tackling digital UX problems were in the form of service design, and we are eager to flesh out the solutions using methods gained here to maximise the value that our clients can receive.

Day 2 and 3: The Talks

Finally, the main event starts — the conference.

The day started with the official launching of the event, as this is the day where most attendees registered for. We got to see the fantastic opening ritual where there were drums, gongs and an opening act by the Founder of the event itself, Hannes before all the talks started.

Once again, we faced the same dilemma — all talks were exciting for all of us. We had a problem here! The 2-day conference was filled with talks given by speakers that came from many countries and backgrounds. Yet it was set to be multiple tracks segregated by theme ranging from leadership to design management to UX research, it would be wasteful if we focus on just one or two, and miss the talks that would benefit us.

We had four team members, so why not split? To maximise what we could gain out of this, we made use of our numbers and specialisations, strategised on how to split up and went to the workshops that would give us the highest impact on our growth opportunities. Shaza and Wan attended the ones that were relevant to the business side, I (Sarah) attended the ones about design advocacy, and Azim attended the ones that were heavy on the UX research side.

We saw that the strategy deemed effective after several talk sessions, and we continued to do so till the end of the conference.

Sarah’s Point of View:

As a product designer, the central theme of the talks I went to was design advocacy. It emphasises that designers educate and collaborate with non-design teams and stakeholders about solving problems using design. The outcome of design advocacy is the value of design being recognised and practised in not only business, but also the technical team.

One of the things I learned was that when it comes to advocating design, the key is opportunity. However, designers ourselves are the ones who should create the opportunities. Scott Parker, who talked about “Functional Process to Strategic Contributor – Realising the Value of Design”, explicitly covered the topic where designers are problem solvers and how we are responsible for realising where and how we can create opportunities for ourselves when it comes to making the value of design visible across the organisation; we should not just wait for those opportunities to come our way.

On top of that, I learned from Ashnee Gounden of Discover Limited who spoke about “Scaling Design with Limited Budget and Time in a Sustainable Way”, that there are considerations when it comes to advocating design. You need to look into the UX maturity of the particular organisation. Evaluate it before you can start navigating around it; this is because as designers, we need to understand before giving solutions. Find out what matters to the organisation and work your way to improve the UX maturity level. Trust me, the “scaling” portion is most exciting part.

Scaling here would mean how you would navigate to increase that maturity itself. How do you plan that incremental journey and what your considerations are. Of course, there are many ways to improve it. It really depends on what matters to the organisation and what their challenges are. Empathise their situation before coming in and introduce the process. Really look into it and strategies based on all the resources you have. It was John Bowie who emphasised “Influence is Not Enough: Inspiring the Unconverted”. He talked about how people respond to inspiration more than influence, so what can you do to inspire them? And what’s next?

When it comes to design debt, of course, a designer like me would be excited to manage it. “What are my considerations?” “How much are my resources and capacity?” “What can I do with everything that I have currently?” These are the questions that you need answers before executing. According to Alicja Suska of Outlaw Design, who talked about “The ROI of Managing Design Debt – Getting the Leadership Buy-in”, communication of the return from managing the design debt is also crucial as it definitely helps the overall organisation to be more effective and profitable in the long run, so create those opportunities! Leverage the people around you as this helps us understand other people’s perspectives and priorities. This was also covered by Manuel Schnell of Kelag and Juergen Hillber of Red Bull. They emphasised gathering and understanding what the other team is doing so that the whole team could see things eye to eye. This way, our solutions will be richer with inputs from multiple disciplines.

As a plus point, Alejandro Carbejo shared “Context and Empathy as Pillars for Collaborations in DesignOps”. This is where I learned how the DesignOps team at the back end has been supporting the structure of the design team to collaborate as support to other teams in an organisation.

The interesting part is that Stampede has already been practising these for years and attending the talks diversifies my view on navigating situations.

Azim’s Point of View:

I was assigned to attend the UX research & management track, which is very relevant to my line of work in Stampede — UX design. These talks have expanded my horizon on how research can be done from an international perspective, with some familiarity about how we have always done things and issues faced in projects (many things are similar!). But of course, there are many new discoveries made here, which opened my eyes regarding the level of international design thinking. Wish I could cover them all but here are some of the selected highlights we could all learn from!

There were talks discussing the process. One of the notable one I have attended was by Javier-Bargas Avilla from Google, where he shared his experience of improving YouTube’s localisation feature, where they started with the complex German language as the base model (German translation were atrocious, at least according to native speakers). He outlined the metrics used as base to be gauged, and emphasised the importance of collaborative effort with the deserved party (locals in this case) which in the end lead to measurable success.

And there were talks discussing the methods. Dr. Panagiotis Zaharias from UX Prodigy discussed long-term UX, where he made the stance that the UX research methods we have adopted so far are actually measuring momentary experience only, not considering the long-term experience yet. Sourced from academic studies, 4 methods were outlined that have yet to be used in real practice; Day Reconstruction Method, Experience Sampling Method, AttrakDiff, and UX Curve — with their pros and cons to be considered before use. All these to capture the user sentiments of long term usage, in order to leverage on hedonic quality (related to user’s intrinsic motivation) of a product which will result in memorable experience and loyalty.

Then there were talks about the tools. Bill Albert of Mach49 shared about the advanced tools that can be used to measure user’s emotion to gauge the experience by breaking down the existing spectrums when classifying emotions and prioritising the relevant ones to UX. Plethora of scientific tools were demonstrated, like Galvanic Skin Response, Electrodermal Activity, eye tracker, pressure sensitive mouse or chair, and facial expression analysis, to name some — but ultimately, knowing the why behind all of the readings obtained is the most important aspect to assess the real user experience.

Another notable talk that attracted my attention was the talk attended by all four of us — about Systemic Design by Peter Horvath of Whitespace. The presentation was very smooth (too smooth even, for me who loves to snap every slide and failed to capture some of the slides this time) and eye-opening, where Peter described the components of Systemic Design and the relations between them. It took me quite some time to absorb the topic of systemic design fully, and how it plays into the bigger picture of UX design.

Overall, the conference was a treasure trove for those who love the research aspect of UX design and have curious minds open to new ideas and concepts — especially for the ones who are fairly new in the field like me.

Closing

So, as we look back at all these moments and learnings from the workshop and the World Usability Congress itself, we realise that design is so much more than just looking good or being functional. It’s about creating connections, understanding each other, and constantly evolving towards the greater good.

At the end of the day, design isn’t just a job for us, it’s a lens through which we view and interact with the world, imagining all the ways it could be better with every new thing we learn, every fresh perspective we take in. It just brings us one step closer to a future that’s not only smart but also kind and inclusive.

So, let’s embrace the complexity, celebrate the diversity, and continue to design not just for the eye, but for the heart and mind. After all, we are designers, aren’t we?

The post Lessons and practical applications we brought back from World Usability Congress appeared first on Stampede: the strategic design & technology company.

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.

We quickly realised that people have yet to understand the difference between reliable and unreliable data and the difference between factual evidence and opinions. Most businesses are making decisions based on users’ opinions which likely lead to a really frustrating product development journey. We’ll talk more about this later in this article.

Now, user research is not rocket science, but just like any other skill, you need to practise in order to get good at it. For some reason, most companies will send their least trained employees, or even interns, to go out and talk to customers. For them, if you can talk and ask questions, you can do user research. “This is the set of questions, now go wild!” is often the attitude, but really, there is an art to interviewing and doing user research that yields truly useful results.

This article is about avoiding these fundamental mistakes so that you get reliable, useful and usable data. We’ll first discuss common mistakes and then we will go through small steps you can take to improve your practice.

Mistakes

1. Collecting opinions, not facts
2. Imposing Quantitative methods on Qualitative data

Steps to improve

1. Using Themed questions
2. Insights: more than just findings

Collecting opinions, not facts

In user research, the people you are talking to and interviewing are naturally inclined to be helpful and will give a lot of feedback that they think is important. Be wary, though, as a lot of the “feedback” you get is actually opinions if you don’t ask the right questions or if you ask in the wrong way. One of the most common research mistakes that people make is to interpret opinions as facts. Opinions are dangerous because they change, are subjective and are inconclusive. If you build your products/services based on them, your product can become irrelevant pretty much anytime because opinions shift and are heavily influenced by how a user feels at the time. The focus should always be on how users use your product instead of what they think of it.

Facts, on the other hand, are concrete. You want to dig into the facts of users’ lives – pain points, behaviour and what solutions they deploy. The focus should be on understanding if there are any existing habits, like how they usually tackle a problem, or technology that you can ride on for users to easily adopt your solution as part of their routine. These all need to be taken into consideration as you design the solution. It is the holistic journey of how they will adopt your solution and not about whether they like it.

In order to collect facts from a user, you need to ask the right question. I usually divide my questions into three parts and types: context specific, product specific and opinion-based. Most of my focus will be context and product specific as useful insights will mostly come from these two areas. I often ask for examples so users will tell me stories which are facts. If I have extra time to kill, I’ll squeeze in some opinion based questions. Let’s run through an example:

Research Goal: Find out how might we improve Jira as a product for task management.

The first two types of questions will give you richer data about a user. It allows you to:

1. Imagine/understand how your users use your product as part of their daily routine
2. Decide on information hierarchy, i.e. prioritisation of what to show or provide your users with, as you now know what important information they need to complete their tasks
3. Decide on your non-negotiable features and “nice to have” features

Qualitative vs. Quantitative Data: More does not necessarily mean more

Most companies are familiar with quantitative rather than qualitative data which means that they are skeptical of research that has a small sample size. After all, when learning about research and statistics in school, we were always taught that a larger sample means more reliable results. As a result, and from my own experience, most teams resolve to increase the number of research participants to double, or even triple that of a qualitative study. The outcome is often remote, unmoderated testing or well-curated surveys where the focus is on getting a large number of responses rather than getting rich, quality data. What’s worse is when they quantify the results and turn them into graphs making things look more scientific than they are.

It is not that quantitative data is bad, but you shouldn’t try to use quantitative methods on qualitative data. You need to first understand the differences between the two and what they can be used for. Quantitative is used to segment and identify your target market and qualitative is used to gain an understanding of the underlying reasons, opinions and motivations of your target market.

Using quantitative methods on qualitative may mean testing the product on and talking with more people to get more results but this does not necessarily lead to more insights, just a lot more work. Be aware that there is a difference between the two types of data. If you want to understand the user beyond the surface, you should focus more on qualitative data. It is not just about what they say and think, but finding out what they feel and discovering their unmet needs. This is something that you almost certainly cannot achieve through a survey.

Doing better research

It’s not hard to change your research methodology a little to get better quality data. Here’s a couple of suggestions.

Using Themed questions

When you design your question guide, start with broad themes. Then test it.

Themes will help you create categories on different kinds of data you want to collect. Once this is done, flesh out a few questions under each theme and test it with people around you. From their answers, you will know the questions to ask to solicit relevant data. Let’s look at an example:

Research question: How might we help our youths get better at saving money?

Insights: more than just findings

Good researchers are great at spotting patterns and findings. Great researchers take the results, analyse them and can derive insights to inform breakthrough solutions. Deeper insights are truths that are unearthed by continuously asking “why” to get to the heart of the problem.

Identifying the difference between a finding and an insight is like a muscle that needs to be strengthened. The key is to always be curious about the deeper meaning of someone’s behaviour. “People watching” is one of the best exercises to train your eyes to identify interesting findings that can lead to deeper insights. When you are in a public space, observe what people around you are doing or carrying. Question why they’re doing this and if you are bold enough, casually chat them up to understand them better. If this is too much of a challenge, try observing and chat up your colleagues instead.

Example of Findings vs Insights

Small steps, quick wins

Overall, the good news is that user research is just like any other skill; it requires practice to get better. These are small, easy steps you can start adopting as part of your practice. If you take small steps to avoid these fundamental mistakes as a part of your current user research practice, we are sure that the time you invest into talking to your users will be more productive and will yield better results. Let’s move the needle on the user research scale from “awareness” to “nailing it”.

The post User Research: Common Mistakes and Best Practices 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.

I remove the clients’ fears; I reassure them.

Like many other Stampede clients, Michael is brimming with positivity. I was glad to be given the chance to have a chat with him about the first few years of User Journeys, his usability methods and what he believes in, amongst others.

The post Putting Users First: An Interview with Michael Heraghty appeared first on Stampede: the strategic design & technology company.