Running a UX workshop is a user experience lesson by itself as there are several types of personalities that can be identified from the involved participants. One participant might be very eager about the project creating a dominating presence, while the other might be too shy and nervous and keeping him/herself recluse from the beginning. This is where the UX workshop facilitator truly shines, by navigating around different personalities so that every participant becomes involved. Everyone has a say in things and their opinions are valued.

Deriving from our experience running this UX process, here are a few commandments in facilitating a UX workshop.

Thou shall be super prepared

There is a quote by author Joe Poyer.

Thorough preparation makes its own luck.

While luck itself is commonly linked to a coin flip, the quote itself means that being prepared will reduce the the risk of things going wrong.

Over the years we learned that the most impactful decision to reduce risks and uncertainty was to implement a checklist. Checklists are helpful, simple, and gives everyone a baseline of things we should agree on before starting the workshop. It can cover items such as, what stationery to bring (markers, pens, post-it notes, flip-charts, tape, ideation cards etc.), a list of participants, an agenda of the workshop, a brief flow/script of facilitation and many more.

For first time facilitators, you might want to hold a quick rehearsal with your internal team a few hours or a day ahead of the workshop. As you gain more experience overtime, you may find that this is no longer needed.

Thou shall have an agenda

Having an agenda lets everyone in the workshop know what to expect, what will happen, what they need to do, and plans moving forward.

Picture this, your clients arrive on that day hoping for a significant outcome from the workshop. They have allocated a huge number of hours or days out of their busy schedule just for it. Because of this, it is of the utmost importance to let them know what will happen during the workshop and what they will need to do and expect. By having an agenda, they won’t feel overwhelmed with uncertainty and everyone’s goals are aligned throughout the session.

Thou shall delegate

This is a lesson we learned the hardest. Stampede is made up of such talented people – sometimes we individually become too ‘enthusiastic’ and do everything by ourselves! However, realistically we can only do so much. If a person is able to focus on something, the better the outcome will become.

As a workshop facilitator, you can’t be doing everything at once. Delegate someone to take care of the note-taking or recording, or someone to bring in the refreshments at the start of the workshop. Ask someone in your team to alert you if they see someone is disengaged, or one part of the session exceeds its time limit – so you can keep the workshop back on track.

Thou shall be realistic

As a rule, you cannot possibly cram all UX activities in one day.

Decide what sort of activities will take place in the workshop. If it is only about identifying the user persona and journey, in my experience, the two itself would take roughly a day and a half. If there are no prior identification to the user personas beforehand by the clients, it would probably take more days. There will be many discussions going back and forth, especially if it involves quite a number of participants. To not overwhelm everyone, dedicate at most a two-day session just for one method. Some of these methods are the user persona, user journey, card sorting, and usability testing. Schedule an additional session if another method needs to be accomplished.

Thou shall be friendly yet determined

As mentioned, facilitating a UX workshop is a user experience lesson by itself. You need to be able to exude a friendly aura so that everyone feels relaxed and comfortable with you. In general, being friendly means that we become too lenient about things. We can go overboard with time limits, or one participant might just sit and stare into the screen while the others offer feedback, or worse, they might be too shy to participate at all and we don’t want to ask them so many times as not to humiliate them.

There is no shortcut around this. The first step is to identify the personality traits every participant have. Commonly seen are, The Shy One, The Rambler, The Off-Piste, The Assertive One, The Space Cadet and The Yes Man/Woman. This article frames a good way on how to deal with each personality trait – granted it is for user interviews, but a good guide nevertheless.

Thou shall have fun!

I shall not lie, after so many workshops, I still get anxious about facilitating one after another! Above all, we should bear in mind that what we do in these workshops is to help each other. We help the client to discover the best experience their users could have, and as the custodian of their business, only they could provide us that.

As a UX workshop facilitator, if you project yourself as having fun, your positive vibes will show and rub off on the rest of the group. However, if you are anxious, that will show too.

So, smile, enjoy the attention and focus on keeping everyone involved!

The post The 6 Commandments of UX Workshop Facilitation 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.

An increasing number of design companies have now begun to ditch the unforgiving waterfall project management approach for an agile one. It allows teams — both internal and clients’— to hit key milestones fast, to get greater visibility to the project, and to receive continuous feedback — hence allowing them to reach quicker to change and bottlenecks in the development process. The agile approach helps teams respond to these unpredictabilities through incremental, iterative work cadences, known as sprints.

In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the life cycle. When a team stops and re-evaluates the direction of a project sprints every two weeks for instance, there’s always time to steer it in another direction. The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Mistakes are reduced, products are shipped fast, reiterations are made there and then, users’ needs are more addressed rather than initial requirements.

Simply summarised, Agile project management is the process by which projects can be managed and implemented in small chunks of work. Small victories.

Scrum and Kanban

Scrum and Kanban are two terms that are often (incorrectly) used interchangeably in Agile approach. In reality, there are significant differences between these two Agile methodologies. Understanding these differences is key to choosing the path that will work best for your environment.

Scrum vs Kanban (Source: solutionsiq.com)

Scrum is a tool used to organise work into small, manageable pieces that can be completed by a cross-functional team within a prescribed time period (called a sprint, generally 2-4 weeks long).To plan, organise, administer, and optimise this process, Scrum relies on at least three prescribed roles: the Product Owner, the Scrum Master and the Team Members. Scrum board refers to the visual representation of the work flow, broken down into manageable chunks called “stories”, with each story moved along the board from the “backlog” (the to-do list), into work-in-progress (WIP), and on to completion.

While Scrum limits the amount of time allowed to accomplish a particular amount of work (by sprints), Kanban limits the amount of work allowed in any one condition – so that only a certain number of tasks can be ongoing and completed on the to-do list. Kanban board, just like Scrum board, refers to Kanban’s visual representation of the work flow.

How are agile projects managed?

Using Scrum model rather than Kanban, as previously adopted, we have established that there are three roles: product owner, ScrumMaster and team.

The product owner is largely responsible for the business aspects of the project. She ensures the right product is being built and is the most empowered to make decisions about the product. If an agile project involves teams both internal and client, someone from the client side is usually the product owner as she has the say on what should be established within the requirements.

The Scrum Master is usually the project manager or the project lead, ensuring that the team works together in the most effective manner possible. A good Scrum Master facilitates meetings and discussions within an agile project, remove impediments in the progress, tracking progress and issues — in short, ensuring the teams get what can be done as smoothly as possible.

Then there’s the most important people: the team. They assume each role dedicated in the agile project either as Strategist, Designer, Front End Developer, Programmer etc and together will collaborate on how to best achieve the product goals.

Agile project management divides responsibility among more than one team member, and everyone is involved in every phase of the project, rather than focusing on one member at a team— like waterfall approach. The result is every team member is more informed of every project decision and everyone should be in the same page once done right.

Tools

Scaling agile isn’t easy the first time round – all good things is not the first time round. Luckily there are always tools to help expedite agile approach as good as possible. Here are three of which we have tried out.

Yodiz

We use Yodiz as our Agile project management tool in Stampede. Its features include Scrum tool, issue and bug tracker, Kanban task board, and epics management software. With a visual, Kanban style Scrum board, users are able to see a comprehensive sprint planning view. They effectively manage user stories and sprints, create, edit and re-prioritise them easily, associate them into epics that span across multiple projects, and track daily work progress and burndown charts. It is so far the most comprehensive out of all tools we have tried.

JIRA

JIRA Software gives your team the flexibility to plan and adopt any agile practice, whether it be scrum, kanban, or a mixed methodology. Teams can create and estimate stories, build a sprint backlog, visualize activity, measure team velocity, and report on progress. JIRA seems to be more visual and less cluttered than Yodiz, however, JIRA is more catered towards large enterprise scalability and we serve smaller companies — hence, Yodiz is a better choice for us.

ZebraPlan

If you’re a tech startup, it can be tough to find quality Agile software at a palatable price point. ZebraPlan offers a great solution for small teams with big needs. The software breaks down tasks into sprints, which users can easily drag-and-drop tasks into. The dashboard view has all the necessary charts to keep your team in check, and the software has some overall cool features, like KPI comparisons, code review, and, for those opting for the “ultimate” plan, 16 reports to choose from.

Conclusion

Agile approach might have been touted to be oriented heavily towards software development, but to be honest if we think about it, its core principles of “inspect and adapt” should apply more now where things are often changing and evolving. Agile should be a natural fit, once you figure out how to make it work for you. After all, as each team and project is different, you are best off picking the methods and applications that work and adapt them as you go.

Does your team also run agile? What tool do you use? Do you have any good tips for running agile project management?

Sources:

• Agile Methodology
• Agile Project Management Done Right
• What Is Agile Project Management?
• 3 Differences Between Scrum and Kanban
• Understanding Agile Design and Why It’s Important
• Agile Project Management Software 

The post Getting to Know Agile Development appeared first on Stampede: the strategic design & technology company.