When it comes to Voice UI there’s a lot of conversation around voices, but very little around personality—whether or not we want to describe it as a personality—that we’re creating. How trustworthy should that personality be? Where should there be a natural boundary? We need to bridge the gap between people talking about Artificial Intelligence (AI) both as a tool, as well as a potential force for evil in the world.

Designers as leaders

As designers, there’s a challenge around how we influence and tell stories, and how we connect with our business partners about “here’s why we shouldn’t do this”, and we might tell it in terms that they understand. 

There’s also a conceit among designers that we are somehow more empathetic or more ethical than our counterparts in other business disciplines; that somehow our motivations are different and inherently virtuous. I disagree, people are people, and there are plenty of brilliant jerks in the design industry with serious EQ deficits. 

I do believe designers are uniquely valuable, but that value is based on how we approach and solve problems, and that is what’s special. 

Telling stories allows design to connect dots across experiences in ways other business disciplines don’t. What we don’t do well is getting outside of our little studio enclaves and connecting those stories to outcomes, measurements and impact that business and engineering leaders can understand. Where voice is concerned, we need to take the shine off the technology and work with our partners to establish principles and ‘red lines’ we are unwilling to cross in the products we create.

Social Reciprocity vs. Voice UI

On some level voice design exploits a natural cognitive bias. Talking to a computer can make technology easier to use, but creating that illusion of a human personality opens up considerations for how “trustworthy” should that “person” be? Voice agents that seem like intelligent people are passively acting on unspoken, unconscious social expectations, like reciprocity. When I say “hello” to Alexa my unconscious expectation is that she reciprocate with “hello”. Humans consider it “rude” not to respond in most circumstances, but our rational side asks “how can a computer appliance be rude”?

I believe it’s important for designers that create voice interfaces consider not just how to respond to user input, but to imagine what a trustworthy person would do with the information they share. Designers need to sharpen abilities that go beyond craft. It’s not ok to just envision these experience or tell idealistic stories or cautionary tales about doing the right thing, we need to accept responsibility for what gets shipped from an ethical standpoint and pick battles we might lose. Ultimately we’re part of the decision on what’s in the best interest of the user, especially when they speak with a computer like a trusted friend and aren’t considering the implications of what they say in their home.

Those are considerations that we took seriously when we were working on Alexa. For example, if you say “Alexa, I love you”, Alexa will answer “Thanks. It’s good to be appreciated.” What should Alexa’s reaction be? Getting “friend-zoned” by a talking beer can is off-putting.

Can you imagine saying I love you for the first time to someone and them saying, “Oh, you’re a good friend.” 

That’s disconcerting. But is that an ethical response on the part of Amazon?

I would argue yes, because you’re not creating this expectation of emotional intimacy – at least not to the degree that might distort somebody’s view of the system and exploit their trust. I think, something people are beginning to consider as the novelty wears off, is how much of what we talk about is being recorded and remembered for later?

A diesel engine in a steam-powered age

I also happen to believe that we (as a society) anthropomorphize AI, and that AI doesn’t work in any way, shape or form like the brain. The idea that AI is going to be this super intelligence, able to do everything better than humans isn’t accurate or realistic. AI is just a set of tools. It’s a diesel engine in a steam-powered age. It does some things better, but its utility is limited. For example, I’ll take a big stupid dog from the local shelter over the most advanced, AI-powered security system for my home.

What we’re really doing is letting the humans that are making the decisions about what that AI does off the hook by ascribing human characteristics to a tool.

So this notion that we’re going to have this symbiotic relationship with AI, I think we’ll actually have a set of tools that can increase human potential, but I don’t believe we’ll have something that’s going to replace or co-evolve with us. That’s not the way computers really work. Right now AI seems amazing in the same way that my grandparents were fascinated by airplanes 100 years ago. 

Visual cues and trust in Voice UI

I think for a version 1 product, Amazon did a very good job with the initial echo. They got a lot of the details right. A lot of their assumptions were wrong. The product was almost successful despite what they thought it was going to be great at.

I know the team that came up with things like the sound library or the way the device lights up when you use the wake word. Those details are very intentional and they are directly tied to the trust and transparency the team committed to from the beginning. 

People knock on Amazon for being this death star type company, but it’s probably the most ethical company I’ve ever worked with—you just might not agree with their ethics. 

With Alexa, there should never be any ambiguity as to when the device is listening. It is listening all the time on a 15-second loop for the wake word, but it is not connected to the internet or retaining what is said when those lights are off.

When it is connected to the internet, those lights turn on. They show which direction the device is listening in, and when its processing what has been said. The user always knows when the device is listening, when it’s searching for your voice, and when what you are saying is being recorded and streamed over the internet.

Those sorts of details are important and model expected interactions between people when they are communicating. 

Devices leveraging human potential  

Our bias towards human interaction gives objects such as Alexa an agency that they don’t actually have. On some level, we assume Alexa is our invisible friend that lives inside the device. But Alexa isn’t our friend—it’s a web service that’s mostly a search engine housed inside an object covered in microphones. In my opinion the only healthy relationship you can actually have with these devices is as a way to do things for you, or to help you connect with other humans.

One of my favorite papers from graduate school was by Mark Wiser, the father of ubiquitous computing. His vision, back in the late eighties, was that a new age of computing would connect people in more meaningful ways by removing distractions from their lives; ousting the bits of life that suck or are annoying. A Roomba is a great example of this. I don’t have one, but my wife would love to because kids are a roaming disaster zone, plus we have a dog. The Roomba isn’t durable enough for our horde, but a device that intelligently takes care of the vacuuming would be great. It would free us from a tedious task, and we wouldn’t have to feel guilty about the rugs looking like a bar floor at closing time.

That’s a great application of robotics and AI or machine learning. It’s not really AI, but I think those scenarios are where the opportunities are.

As designers, we can train ourselves not to think about a particular solution or technology as inevitable. We can refocus the opportunity back onto ‘how do we help humans be the most authentic, best versions of themselves by removing the  shitty, tedious bits from daily life?’

In contrast, right now technology still competes with some of the best things in life, such as spending time with our kids.

Fear mongering in Voice UI

It’s popular for people to warn against the dangers of Voice UI, but there’s a bit of fear mongering that goes with it. I find it helpful to bring those conversations back to a more thoughtful place that balances risks and benefits. History can be a useful teacher here. 

Designers and technologists have a tendency to only look at the future, rather than problems in the past that are echoing the questions we’re wrestling with today. We will always have those moments of angst and horror where innovation and unintended consequences collide with the real world. Rather than blaming the technology—which is a tool—we need to also anticipate where human decisions applied to technology might go badly wrong. “Move fast and break things” is an incredibly irresponsible motto when you’re brokering interactions between billions of people every day.

Using addiction science to hook people onto your product so they look at more ads is objectively sociopathic. It’s not the fault of the technology. The people who designed Facebook and optimized its engagement model made those decisions.

I’m sorry, but you can’t employ techniques known to cause mental health issues and then ask “how did we get here?!” or shrug and blame users for their lack of self-control when you intentionally designed the system to work that way. That’s like blaming two-hundred thousand deaths in World War II on nuclear weapons when it was human beings making the decisions and giving orders to use pursue that technology. The outcomes in both cases were completely predictable and easily anticipated. Technology isn’t good or evil, but human decisions—especially short-sighted decisions—certainly are.

Adopting a new stance in response to technological changes 

We made a lot of mistakes in the early days when designing for mobile devices, especially on the web. We were experimenting and failing a lot with patterns and with approaches to software. As we became more familiar with what these devices were actually good at, our thinking and philosophies evolved. How should using a computer that fits in your hand change?

Now that we have voice-first experiences, which are very different from capacitive touch. The two technologies are good at very different things, but a lot of voice experiences are designed with the same assumptions inherited from the mobile phone context. The experience morphs to the affordances of the device that you’re using.

What makes voice design particularly dangerous right now is that we don’t have a way for users to control what these systems remember. On your phone, you have the ability to turn off or block certain services. You have to choose what different apps have access to. There’s no way for users to choose how much information they’re willing to give away in exchange for completing an interaction. 

The missing piece for AI is that right now there are very few protections for the user. As an analogy, these early days of Voice UI are like the days of the internet before anti-virus software or web certificates; we’re entirely dependent on the goodwill and trustworthiness of companies that are incentivized to profit from our behavior. When we start creating voice agents that seem human, and sound trustworthy, how do I protect myself from being manipulated? Would customers be willing to pay for an agent where they can control it’s goals and limitations? I think it would be very useful to have a trustworthy digital assistant that can warn me when I’m about to share more information than I intended. 

I’d love a version of Alexa that said “Those terms of use are really invasive, and they want a lot of information you don’t normally share. Don’t sign up for that.

Trust in Internet of Things and devices

Has the trust in the Internet of Things (IoT) and devices changed? I think it depends on the ‘thing’. IoT light switches: do I care that much? Probably not. All they really do is turn things on and off. But for customers I think there’s a gradient of convenience versus privacy and trust. 

The business opportunities that companies go after in IoT are generally riskier, more complicated, and less useful than they appear. Consider an IoT light bulb: it simply doesn’t work when the internet is down. That is a very expensive broken light bulb. Only a tech company can take something so straightforward and charge a customer a hundred bucks to make it less useful. When it works, it’s kind of cool, but it takes more than a second for the light to go off. That’s an interesting science fair project, but kind of a terrible product.

In my exchange for that less-useful lightswitch, the company is probably also monitoring how often I’m turning my lights on and off. Am I okay with that? Why do they need to know that information?  There’s a saying in the industry right now that “data is the new oil of the digital economy”. Regardless of whether that is true, consider the implications. When are you drilling on someone else’s land? And should you perhaps be asking permission first? Companies have assumed a lot of power over your data. Are we willing to just give it away for a lightbulb we can turn on with our voice? 

Companies like Apple and Microsoft have made pretty strong commitments to user privacy and that’s likely to be an ongoing part of their brand. It’s going to take them a while to truly achieve that, but it’s a major strategic advantage in the face of companies like Google and to a lesser extent Amazon. I trust Amazon more than I do the other companies, but that’s probably my personal bias and knowing how it works on the inside.

Refocusing the conversation

This issue is ultimately about refocusing the conversation around humans, and not the technology. The humans are why it works, they are why it exists. Alexa has no opinions or preferences. It only speaks when spoken to. The “AI” is entirely latent until a human activates it. I don’t believe that’s something to be afraid of. I think the ethical consideration needs to be applied to human decisions and how the tech will be used and abused. We mustn’t violate the trust of users when they react to a voice in a human way, because that’s the way we’re all wired. There’s simply a responsibility that goes with designing for that.

The post The Ethical Considerations, Trust, and Responsibility in Designing Voice UI appeared first on UX Mastery.

User research is now not only a deeply integrated part of business, but also using ResearchOps to align with the DevOps practices used by development teams, and DesignOps functions of production teams. So why is there such a broad range of different UX maturities across our professional landscape? And what specific role might ResearchOps play in supporting this maturity more equitably?

How UX maturity can be measured 

As the maturity of an applied user experience culture within an organisation grows and adapts over time, the specific approaches that people use for user research often also change. This reflects their progression through different stages of maturity. Knowing where your organisation and your team sit within these definitions of maturity is useful for helping you tailor a realistic approach to research and design for your stage of maturity. They can enable your team to effectively meet organisational strategic goals, while still remaining human centred. They can also help executives understand what UX people do, and what ‘good’ looks like.

‘UX Maturity Models’ are objective frameworks that enable organisations to categorise the quality and effectiveness of their user experience processes and practices. There are a number of UX maturity models out there, with most models defining a spectrum from low maturity (where user research is completely absent) up to the high maturity end (where research is well integrated into strategic decision making).

Bonus Resources:

– ‘How do you measure UX maturity?’ An empirical approach to validating and refining different UX Maturity Models — Jeff Sauro, MeasuringU

– ‘UX Maturity Models – A Collection’ by Natalie Hanson, anthropologist and UX professional.

ResearchOps framework as an indicator of UX maturity

As user research becomes more valued and more integrated within organisations, it starts occurring at scale… but along with that success, we are also confronted with a challenge where the mechanisms and strategies may not exist to support the growing user research practice. This is the problem that ResearchOps seeks to address.

Kate Towsey was the instigator of the #WhatIsResearchOps global workshops and research initiative, and a founder of the ResearchOps Community, an organised group of people openly learning what it means to build and manage research operations. Together, this resulted in the definition: “ResearchOps is the mechanisms and strategies that set user research in motion. It provides the roles, tools and processes needed to support researchers in delivering and scaling the impact of the craft across an organisation.” [source]

The ResearchOps framework developed in 2018 by the ResearchOps community is a good reference of the breath of ResearchOps. The framework defines the key elements of the ResearchOps practice, such as recruitment, knowledge management, governance and more. This framework is the result of analysis from a global survey as well as 33 workshops held around the world to help answer the question ‘What is ResearchOps?’. While the underpinning concepts of ResearchOps are not new, there is an increasing level of awareness and formal recognition of ResearchOps-specific roles. Establishing and growing a ResearchOps team is an indicator that an organisation is towards the mature end of most UX maturity models.

Bonus Resources:

– ‘The Eight Pillars of User Research’ How can you get started with ResearchOps unless you understand what is important to User Researchers? Emma Boulton explains.

– ‘Democratisation of UX Insights: What Does This Really Mean?’ Remote teams, online research tools, and efficient access to use feedback compel action at the operational level via ResearchOps. Alfonso de la Nuez

Deepening organisational maturity

It’s important to recognise that being on the mature end of various UX maturity models doesn’t mean that the UX practitioner’s job is done. It’s now about deepening the organisational maturity (rather than just shifting it up the maturity model). There are a number of factors to consider when going for depth in relation to ResearchOps. Some of these include:

• Requiring different mechanisms and strategies to support User Researchers, versus People Who Do Research (PwDR – a term coined by Kate Towsey). While it is ideal to have highly skilled user researchers doing research, the reality for large organisations often means that a large number of non-researchers are doing the research. They require different types of support to help move towards better quality research so that PwDR can conduct research on their own without support.
• Building and using an effective knowledge management system. We generate an immense amount of information in our research activities but turning information into valuable knowledge and insights that can be actioned and mined over time is a difficult process. User research repositories and libraries are all the rage at the moment but this is incredibly difficult to build and manage. Having access to a good tool to help with this is important but don’t forget to start with the user needs.
• Building research capability. There is often a shortage of highly skilled user researchers and ResearchOps people. Good people are an investment, and building research capability is one area that needs focus.
• Bringing together and supporting qualitative and quantitative research, particularly in relation to Big Data. 
• Cost, quality and the value of research. As ResearchOps centralises a number of the operational processes and costs of research, it becomes more evident how much it costs to do research across the organisation. This quickly changes the conversation to the quality of research being conducted, the value it has for organisational strategic and service decision making process, and the impact the research is making.  

Bonus Resource:

– How to Grow User Research in your organisation Nikki Anderson, a qualitative user experience researcher.

Extending UX maturity

A ResearchOps practice is certainly not the only indicator of UX maturity of an organisation, but it is definitely a factor, particularly for larger organisations. A ResearchOps practice is just the start of the journey – there is so much growth in this space. If you want to learn more about ResearchOps, please join the global ResearchOps community and contribute as we are all on the journey together.

The post Success in ResearchOps: An indicator of UX maturity appeared first on UX Mastery.

See if any of these tensions sound familiar:

• Should we do more Learning or start Building?
• Should we focus on Innovation or Efficiency?
• Should we prioritize Deadlines or Quality?
• Growth vs. Consolidation?
• Short-term Gains vs. Long-term Organic Growth?
• Centralization vs. Decentralization
• New Features vs. a Stable Codebase?
• Generalist or Specialist?

We could go on, listing more of these tensions. And if we’re like most organizations, we’d rush to analysis to determine the best or right answer. I’d argue we should first stop and ask a more fundamental question: Is this A Problem… Or a Polarity?

Too often, we treat conflicts — like those listed above — as problems to be solved, when in reality they’re “polarities”.

Problems vs. Polarities

A problem is something that can have a right — or best — answer. A solution exists. If we’re deciding between two incompatible tech stacks, this is a problem to be solved. We do our analysis. Weigh the pros and cons, determine which is the best choice, all things considered, then commit. Problem, solved.

This is approach is fine, if there truly is a decision to be made.

• Which tech stack do we commit to?
• Which department should I move to?
• Where should we shift our funding?

But, when we level this same problem-solving mindset at things that needn’t or can’t really be solved, frustration follows. “Should we focus on delivery or quality?” Yes. Yes we should focus on these things. That is the honest answer. But this doesn’t sit right; it doesn’t feel resolved. That’s because these aren’t resolvable. These are polarities,  “dilemmas that are ongoing, unsolvable and contains seemingly opposing ideas“.

Problems give us two ideas that are directly opposed and in conflict.
Polarities give us  two ideas that are complementary and interdependent.

Problems push an either/or mindset.
Polarities push a both/and mindset.

Problems need decisions, and resolution.
Polarities do not.

Here’s the rub: Polarities are not a problem to be solved, but rather a paradox to be balanced. Here’s an elegant analogy:

“Think of it like breathing. Breathing isn’t a choice between inhaling or exhaling. If you inhale to the exclusion of exhaling, the negative results show up quickly. And the reverse is also true. The polarity approach says, we must both inhale and exhale.”

Here’s where the polarity map enters the picture.

On the surface, it looks like a simple “pros/cons” matrix. But, as with most things, the devil is in the details.

First, this little loop is vital. It says we are constantly moving between these four quadrants.

Second, the language: You have two poles, yes. But you’re not evaluating the ‘pros’ and ‘cons’. Rather, it’s the Benefits and Unintended Consequences. Language matters.

The Tool in Action:

When we treat a polarity like a problem, looping back and forth is what inevitably happens over time (often over a very long, agonizing, period of time!). For our explanation, let’s use the tension of “planning” vs “building” a new software app.

Suppose we decide to double down on “learning”. We have good reasons for this:

• We’ll be able to make faster decisions, when we do move into building
• We’ll generate deep context / insights that are more useful to ops.

This is all well and good until months later, our zealous focus on “learning” has led to some unintended consequences:

• Teams are stuck in analysis paralysis
• And hey, competitors beat you to market. Bummer.

So what do we do? We swing to the other extreme! We double down on jumping into building. Insert some lean-slash-agile-slash-design sprint Kool-aid here.

At first, things go great.

• We’ve got something built and released into the market that we can iterate upon.
• We’re delivering real customer value

But then…

• That new feature you want, it’ll take a ridiculous amount of time, because we didn’t plan for anything like that.
• Oh, and we were so busy building things that we forget to do any real customer research. Turns out no one wants this thing we built.
• And who knows what better ideas we missed out on, as we sped along with our first idea.

We didn’t intend for any of these things to happen. And so the pendulum swings back to the other extreme. Most of the folks that would remember the previous extreme have moved on, so few people recall the follies of the other extreme.

And on it goes.

Polarity Mapping let’s us explore all these issues and concerns in an afternoon, setting teams up to work together, with a shared sensitivity to all these issues.  You get the benefit of discussing all of these tensions upfront, before living through them. The goal isn’t a decision, but rather recognition of all these simultaneous Benefits and Unintended Consequences — on both sides. And reconciliation, as a team. And the valuing of competing perspectives. And… we could go on listing the goals. The conversations I’ve seen as a result of this activity have been quite remarkable. Aside from bringing Product Managers and Designers together,  it’s also broken down stereotypes about what ‘“the other side” values.

“Are there any actionable outcomes from this?”

While I’ve focused on the core of Polarity Mapping, mapping the Benefits and Unintended Consequences of two polarities, there is more to this tool. Once you’ve identified this core information, you can move out into the margins to address:

1. What are the Action Steps to gain or maintain these Benefits?
2. What are the Early Warnings of unintended consequences?

Done as a group, and pinned to a wall, this should set up teams to successfully navigate many difficult conversations. Hopefully, you’ll find this tool as useful as I have.

The Polarity Map in action!

Downloadable Files:

• Poster of the Polarity Map, for workshops (PDF)
• Complete Polarity Map (PDF)

Further information:

• “Are You Facing a Problem? Or a Polarity?“ — Center for Creative Leadership — a great introductory article
• The Polarity Map  — there are lots of versions of the polarity map; I prefer the clarity of this version, as you may have noticed! (PDF)
• Polarity Thinking, Polarity Mapping  — a longer overview with more examples (PDF)
• [BOOK] Polarity Management: Identifying and Managing Unsolvable Problems Yes, there’s a book on this topic, authored by the creator of this tool, Barry Johnson

You can also get more detailed information and consulting services directly from Polarity Partnerships, co-founded by Barry Johnson Ph.D., the creator of The Polarity Map^® and Principles

The post The Joys of Polarity Mapping appeared first on UX Mastery.

UX research can be extremely helpful in crafting a product strategy and ensuring that the solutions built fit users’ needs, but it can be hard to know how to get started.  This article will show you how to set your research objectives and choose the method so that you can uncover the information you need.

When to do research

The first thing to know is that there is never a bad time to do research. While there are many models and complicated diagrams to describe how products get built, essentially, you’re always in one of three core phases: conceptualising something brand new, in the middle of designing and/or building something, or assessing something that’s already been built.

There’s plenty to learn in each of those phases. If you’re just starting out, you need to focus on understanding your potential users and their context and needs so that you can understand your best opportunities to serve them. In other words, you’re trying to figure out what problems to solve and for whom. This is often called generative or formative research.

Once you’re actively building something, you’ll shift your focus to analysing the solutions that you’re coming up with, and making sure that they address the needs of your users. You’ll want to assess both conceptual fit and specific interactions quality.  We usually call this evaluative research.

When you have a live product or service, you’ll want to continue to assess how well you’re serving people’s needs, but you’ll also want to use research to discover how people change and how you can continue to provide value. At this point, you’ll be doing a mix of the generative type of work that is generally in the conceptual phase and evaluative work.

There is no cut-and-dried guide of exactly what methods to employ when, but there should never be a time that you can’t find an open question to investigate.

Determine your specific research objectives

At any given time, your team might have dozens of open questions that you could explore. I recommend keeping a master list of outstanding open questions to keep track of possible research activities, but focusing on answering just one open question at a time. The core goal of a study will determine which method you ultimately use.

If you need help coming up with research goals, consider things like:

• the stage of the project you’re in
• what information you already know about your users, their context, and needs
• what your business goals are
• what solutions already exist or have been proposed
• or where you think there are existing issues.

The questions might be large and very open, like “who are our users?” or more targeted things like “who uses feature x most?” or “what colour should this button be?” Those are all valid things to explore, but require totally different research methods, so it’s good to be explicit.

Once you’ve identified open questions, you and the team can prioritise which things would be riskiest to get wrong, and therefore, what you should investigate first. This might be impacted by what project phase you’re in or what is currently going on in the team. For instance, if you’re in the conceptual phase of a new app and don’t have a clear understanding of your potential user’s daily workflows yet, you’d want to prioritize that before assessing any particular solutions.

From your general list of open questions, specify individual objectives to investigate. For instance, rather than saying that you want to assess the usability of an entire onboarding workflow, you might break down the open questions into individual items, like, “Can visitors find the pricing page?” and “Do potential customers understand the pricing tiers?”

You can usually combine multiple goals into a single round of research, but only if the methods align. For instance, you could explore many different hypotheses about a proposed solution in a single usability test session. Know that you’ll need to do several rounds of different types of research to get everything answered and that is totally OK.

Looking at data types

After determining your research goal, it’s time to start looking at the kind of information you need to answer your questions.

There are two main types of data: quantitative and qualitative.

Quantitative data

Quantitative data measures specific counts collected, like how many times a link was clicked or what percentage of people completed a step. Quantitative data is unambiguous in that you can’t argue what is measured. However, you need to understand the context to interpret the results.

For instance, you could measure how frequently an item is purchased. The number of sales is unchangeable and unambiguous, but whether 100 sales is good or bad depends on a lot of things. Quantitative research helps us understand what’s happening and questions like: how much, how many, how often. It tends to need a large sample size so that you can feel confident about your results.

Common UX research methods that can provide quantitative data are surveys, a/b or multivariate tests, click tests, eye tracking studies, and card sorts.

Qualitative data

Qualitative data is basically every other sort of information that you can collect but not necessarily measure. These pieces of information tend to provide descriptions and contexts, and are often used to describe why things are happening.

Qualitative data needs to be interpreted by the researcher and the team and doesn’t have a precise, indisputable outcome. For instance, you might hear people talk about valuing certain traits and note that as a key takeaway, but you can’t numerically measure or compare different participant’s values. You don’t need to include nearly as many sessions or participants in a qualitative study.

Common UX research methods that can provide qualitative data are usability tests, interviews, diary studies, focus groups, and participatory design sessions.

Some methods can produce multiple types of data. For instance, in a usability study, you might measure things like how long it took someone to complete a task, which is quantitative data, but also make observations about what frustrated them, which is qualitative data. In general, quantitative data will help you understand what is going on, and qualitative data will give you more context about why things are happening and how to move forward or serve better.

Behavioural vs attitudinal data

There is also a distinction between the types of research where you observe people directly to see what they do, and the type where you ask for people’s opinions.

Any direct-observation method is known as behavioural research. Ethnographic studies, usability tests, a/b tests, and eye tracking are all examples of methods that measure actions. Behavioral research is often thought of as the holy grail in UX research, because we know that people are exceptionally bad at predicting and accurately representing their own behaviour. Direct observation can give you the most authentic sense of what people really do and where they get stuck.

By contrast, attitudinal research like surveys, interviews, and focus groups asks for self-reported information from participants. These methods can be helpful to understand stated beliefs, expectations, and perceptions. For instance, you might interview users and find that they all wish they could integrate your tool with another tool they use, which isn’t necessarily an insight you’d glean from observing them to perform tasks in your tool.

It’s also common to both observe behaviour and ask for self-reported feedback within a single session, meaning that you can get both sorts of data, which is likely to be useful regardless of your open question.

Other considerations

Even after you’ve chosen a specific research method, there are a few more things you may need to consider when planning your research methods.

Where to conduct

It’s often ideal to be able to perform research in the context of how a person normally would use your product, so you can see how your product fits into their life and observe things that might affect their usage, like interruptions or specific conditions.

For instance, if you’re working on a traffic prediction application, it might be really important to have people test the app while on their commute at rush hour rather than sitting in a lab in the middle of the day. I recently did some work for employees of a cruise line, and there would have been no way to know how the app really behaved until we were out at sea with satellite internet and rolling waves!

You might have the opportunity to bring someone to a lab setting, meet them in a neutral location, or even intercept them in a public setting, like a coffee shop.

You may also decide to conduct sessions remotely, meaning that you and the participant are not in the same location. This can be especially useful if you need to reach a broad set of users and don’t have travel budget or have an especially quick turnaround time.

There is no absolute right or wrong answer about where the sessions should occur, but it’s important to think through how the location might affect the quality of your research and adjust as much as you can.

Moderation

Regardless of where the session takes place, many methods are traditionally moderated, meaning that a researcher is present during the session to lead the conversation, set tasks, and dig deeper into interesting conversation points. You can tend to get the richest, deepest data with moderated studies. But these can be time-consuming and require a good deal of practice to do effectively.

You can also collect data when you aren’t present, which is known as unmoderated research. There are traditional unmoderated methods like surveys, and variations of traditional methods, like usability tests, where you set tasks for users to perform on their own and ask them to record their screen and voice.

Unmoderated research takes a bit more careful planning because you need to be especially clear and conscious of asking neutral questions, but you can often conduct them faster, cheaper, and with a broader audience traditionally moderated methods. Whenever you do unmoderated research, I strongly suggest doing a pilot round and getting feedback from teammates to ensure that instructions are clear.

Research methods

Once you’ve thought through what stage of the product you’re in, what your key research goals are, what kind of data you need to collect to answer your questions, and other considerations, you can pinpoint a method that will serve your needs. I’ll go through a list of common research methods and their most common usages.

Usability tests: consist of asking a participant to conduct common tasks within a system or prototype and share their thoughts as they do so. A researcher often observes and asks follow up questions.

Common usages: Evaluating how well a solution works and identifying areas to improve.

UX interview: a conversation between a researcher and a participant, where the researcher usually looking to dig deep into a particular topic. The participant can be a potential end user, a business stakeholder or teammate.

Common usages: Learning basics of people’s needs, wants, areas of concern, pain points, motivations, and initial reactions.

Focus groups: similar to interviews, but occur with multiple participants and one researcher. Moderators need to be aware of potential group dynamics dominating the conversation, and these sessions tend to include more divergent and convergent activities to draw out each individual’s viewpoints.

Common usages: Similar to interviews in learning basics of people’s needs, wants, areas of concern, pain points, motivations, and initial reactions. May also be used to understand social dynamics of a group.

Surveys: lists of questions that can be used to gather any type of attitudinal behaviour.

Common usages: Attempting to define or verify scale of outlook among larger group

Diary study: a longitudinal method that asks participants to document their activities, interactions or attitudes over a set period of time. For instance, you might ask someone to answer three questions about the apps they use while they commute every day.

Common usages: Understanding the details of how people use something in the context of their real life.

Card sorts: a way to help you see how people group and categorise information. You can either provide existing categories and have users sort the elements into those groupings or participants can create their own.

Common usages: Help inform information architecture and navigation structures.

Tree tests: the opposite of card sorts, wherein you provide participants with a proposed structure and ask them to find individual elements within the structure.

Common usages: Help assess a proposed navigation and information architecture structure.

A/B testing: Providing different solutions to audiences and measuring their actions to see which better hits your goals.

Common usages: Assess which of two solutions performs better.

Christian Rohrer and Susan Farrell also have great cheat sheets of best times to employ different UX research methods.

Wrapping up

To get the most out of UX research, you need to consider your project stage, objectives, the type of data that will answer your questions, and where you want to conduct your research.

As with most things in UX, there is no one right answer for every situation, but after reading this article you’re well on your way to successfully conducting UX research.

Want to dive deeper into UX research methods? Try Amanda’s latest course, Recruiting and Screening UX Research Participants on Skillshare with 2 months’ free access.  

The post Choosing the Right UX Research Method appeared first on UX Mastery.

These days auto-suggest is everywhere, from social media sites like Twitter and Facebook, to shopping sites like eBay and Amazon, and even in occupation validation for credit card applications.

At its core, an auto-suggest is a form made of two components:

1. a text field (typically <input type=”text”>)
2. a customised select list based on what’s in the text field

With plugins available for all the latest frameworks and libraries, adding an auto-suggest to your site is relatively easy.

But what about accessibility? I’ve reviewed auto-suggest components from many of the major frameworks, and most of them have one thing in common: they’re not properly accessible.

Some go part of the way and make sure suggestions can be used with the keyboard, but most fall over when a selection is made, because focus ends up in a random spot on the page. This cases confusion and frustration for keyboard and screen reader users.

Screen readers are another area where these auto-suggests often fall short. Unless the number of available suggestions is announced to screen reader users, they don’t know they’re there. So, to screen reader users, these auto-suggest components are just input fields.

So how do you make an auto-suggest accessible?

These are my requirements to make an auto-suggest accessible. I’ve included code snippets throughout and linked to a working codepen at the end of the post.

Requirement #1 – Visible focus

A visible focus indicator (e.g. dotted outline, blinking cursor) enables keyboard users to understand where the keyboard focus is. Focus Visible is also a Web Content Accessibility Guidelines 2.0 (WCAG) requirement (success criteria 2.4.7).

Note: if you’re using <input type=”text”> for the input field and you haven’t removed the focus outlines provided by browsers, visible focus should already work. You’ll need to add visible focus highlighting for scrolling up and down the list options with keyboard (as shown in the codepen).

Requirement #2 – Link a label to the input field

All form fields need a label to tell the user what input they’re expected to provide.

For our auto-suggest, this means defining a <label> element linked to the <input> field by its for attribute.

Example:

Onward!

When defining requirements for the suggestions list, we need to consider a few things:

1. When do the suggestions appear?
2. Where do the suggestions appear?
3. How does the user select a suggestion?
4. How does the user close the list?

Answering these will give us the requirements for our suggestions list.

Requirement #3 – If there are no suggestions, don’t show the list

The list should only show if there are suggestions related to the user’s input. If there aren’t any suggestions, don’t show the list.

Requirement #4 – If there are suggestions, show them directly below the input field

If we have suggestions related to what’s in an input field, it makes sense to display those suggestions close to that input field. Accepted practice is to display suggestions directly under the input field, so there’s our requirement.

But hang on! This “list location” requirement is about the on-screen list location AND the position of the list code in the page source. It makes sense to put the suggestions list near the input field on screen, but it’s just as important to put the suggestions list near the input field in the code for easy access for screen reader users.

Putting the suggestions list directly below the input field, on screen and in code, works best for everyone.

Example:

Requirement #5 – The auto-select must be keyboard-compatible

This is a critical for people who can’t use a mouse, such as those with a visual impairment, hand tremors or repetitive strain injury (RSI). Keyboard compatibility is also a WCAG 2.0 level A requirement (success criteria 2.1.1 Keyboard).

Requirement #5a – Up and Down arrows move through the suggestion list items, highlighting the current item

The user shouldn’t Tab through the suggestion list because that takes focus away from the input field. No input focus means users can’t keep typing to refine the suggestions. Arrow keys to the rescue!

Requirement #5b – Enter selects the highlighted suggestion and closes the list

The Enter key should close the list and populate the input field with the selected suggestion list item. Focus stays in the input field.

Requirement #5c – If the suggestion list is visible, Esc closes the list

If none of the suggestions suit then keyboard users can press Esc to close the list without changing the content of the input field. Focus stays in the input field.

The auto-select must be compatible with screen readers

We must tell screen reader users that the input field is an auto-suggest and that, depending on their input, there may be suggestions available.

To do this we’ll use Accessible Rich Internet Applications (ARIA), a W3C technical specification. It defines HTML attributes to improve website code semantics and provide information to assistive technologies (e.g. screen readers) about non-native HTML components like our auto-suggest.

A short segue – when and how to use ARIA

ARIA is powerful, and it can help you make your websites and web applications more accessible. However, it is NOT the solution to all your accessibility issues.

In fact, the first rule of ARIA is:

“If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” – Using ARIA, W3C (https://www.w3.org/TR/aria-in-html/)

ARIA is like gap filler, it helps to patch things up a bit. But it doesn’t give you all the goodness that native HTML does.

For example, unlike a <button>, a <div role=”button”> doesn’t receive keyboard focus, doesn’t send Space and Enter keyboard events to the click handler, and doesn’t have visible focus. Browsers don’t know that a <div role=”button”> is meant to act like a <button>, the role attribute is just a descriptor used by assistive technology.

I’ve used <div>, an element type with no native semantics, for the suggestions list and its list items to satisfy the second rule of ARIA use:

“Do not change native semantics, unless you really have to.” – Using ARIA, W3C.

Requirement #6 – Make the auto-select work with screen readers

Requirement #6a – Add ARIA markup to the input field

Add role=”combobox” to the <input> field to tell screen reader users that the input field is an auto-suggest.

Add aria-autocomplete=”both” to the <input> field to tell screen reader users they can select from the suggestion list or type their own input.

Add aria-owns to the <input> field to link the suggestion list to the input field.

Finally, add aria-activedescendant to the <input> element and populate it with the id of the currently highlighted list item. The aria-activedescendant value changes as the user presses the Up and Down arrows.

Example:

Read more about ARIA:

• Roles: https://www.w3.org/TR/wai-aria/roles
• States and properties: https://www.w3.org/TR/wai-aria/states_and_properties

Requirement #6b – Add ARIA markup to the suggestion list container

Add role=“listbox“ to the suggestion list <div> to tell screen reader users it contains a list of selectable items.

Requirement #6c – Add ARIA markup to individual suggestion items

Add role=“option“ to each suggestion item, along with a unique id. That id is used by the aria-activedescendant attribute of the <input> element, whose value changes as users move through the list items with the arrow keys.

Requirement #6d – aria-activedescendant should match the currently selected option

As users move through the list items with the arrow keys, update the value of the aria-activedescendant attribute of the <input> element to contain the id of the currently highlighted list item.

Requirement #6e – Announce the number of available suggestions to screen reader users

Whenever the content changes of an element that has the aria-live attribute declared, screen readers automatically announce that content. Like a public address system, live regions enable us to make announcements such as “list status” changes as our user types in our auto-suggest input field.

Aria-live regions are polite, assertive, or off, determining when the user hears the announcement:

• Polite = the screen reader will finish what it’s saying before announcing the live region content
• Assertive = the screen reader will interrupt what it’s saying to announce the live region content
• Off = the screen reader won’t announce the content unless the user focusses on that region

With the auto-suggest, the change in the number of suggestions should announce immediately, so this aria-live region is assertive.

Example:

The content of this <div>, which isn’t visible on screen, updates every time the list length changes to trigger the screen reader announcement.

Conclusion

So there you have it. Fulfilling these requirements should make your auto-suggest widget more accessible.

My auto-suggest code, including commented JavaScript for the event handlers, ARIA attribute updates and list population: codepen.io/ademcifcioglu/pen/xdOyXv

The post Anatomy of an Accessible Auto Suggest appeared first on UX Mastery.

So what qualities do you need to become a UX leader? And what defines UX leadership?

To find the answers, we asked our UXperts to weigh in on what UX leadership means to them. The good news is, there are types and pathways to become a leader.

Make sure you read our second instalment, featuring practical advice from our experts on how you can become a UX leader.

Cory Lebson

Cory Lebson (@corylebson), author of The UX Careers Handbook (CRC Press, 2016), has been a user experience consultant for over 20 years. He is the Principal and Owner of Lebsontech LLC, a successful user experience consulting firm he established in 1997. Lebsontech is focused on user research and evaluation, user experience strategy, UX training, and mentoring. Cory also speaks frequently on topics related to UX career development, user experience, user research, information architecture, and accessibility.

What do you think makes a great UX leader?

A great UX leader realises that there are many pathways to great leadership. In my book, I talk about four kinds of UX leadership: workplace leadership, UX organisational leadership, mentorship and thought leadership.

Workplace leadership is what someone may typically think of when they think of UX leadership: leading a UX team in the workplace, making good UX decisions and ultimately producing successful products. While I started down this pathway myself, I chose a number of years ago to become a freelancer and instead channelled my UX leadership energy into UX organisational leadership, helping a local chapter (UXPA DC) and later UXPA international on a voluntary basis.

A UX practitioner who doesn’t lead a team can also be a workplace leader by mentoring others and helping them to improve their skills. Mentorship doesn’t just have to take place within the workplace and can involve giving advice and support to others outside of one specific company.

Finally, thought leadership involves promoting new ideas and information to UX professionals and advocating for UX to those who aren’t already embedded in the profession. Thought leadership can take many forms – writing personal blogs, publishing articles in established electronic periodicals, giving talks and providing training in person, and doing podcasts online, for example.

How can people lead great UX teams?

Sticking with the theme of leadership outside of the workplace, leaders leading a UX Meetup or local, national or international UX professional organisation should not just do everything themselves. Instead, they should create a proper infrastructure to support events and other activities and should pull in other like-minded UXers to help them.

Not only does this make volunteer leadership more enjoyable and provide a basis for more resources to scale upwards towards greater events and activities, but it also spreads the “wealth” of volunteer leadership – that is, provides opportunities for exposure to more people.

Jodie Moule

Jodie Moule is Co-founder & CEO of Symplicit, a Customer Led Innovation firm based in Australia that has focused on research, strategy and design services since 2003. Following a Design Thinking philosophy that was grounded in the psychology and industrial design backgrounds of the founders; Jodie believes that understanding human behaviour allows you to change the customer experience, and that change happens through great design. Follow Jodie: @jodiemoule @thecookapp @symplicit

What do you think makes a great UX leader?

What makes a great UX leader is what makes any other leader great, really. To my mind, this is a mix of being good at what you do, and also being a great people person. To lead a group of people, you have to have a certain ‘gravitas’ about you, and that to me is the intangible aspect of leaders that gives them the X-factor.

In a practical sense, I think someone who isn’t afraid to jump in and help their team get shit done, and get their hands dirty–guiding by example–is someone I think is a great leader. That would be someone not tied up in the ‘ego’ of merely being a leader for the title’s sake. In my opinion, too many people place too much value in job titles and job descriptions. Those people are not leaders.  

To me, a leader really thinks about the future of the space they work within, and is constantly looking at connecting the dots on where the industry is headed, pushing the boundaries beyond the standard approaches, with a clear vision of where their team needs to head–whether that direction is the popular belief or not–they trust their gut and go for it!

How can people lead great UX teams?

When it comes to leading great teams, I think ‘like attracts like’. If you build something that is great, others will want to be part of that. I also think if you are just setting out to ‘build a team’ you might find that hard. If you are setting out to achieve a mission rather than just ‘building a team’–that’s how you end up building and leading a great team. For example, we always set out to do great work, the rest kinda followed. Be yourself and enjoy the ride! Model great qualities, be passionate and engaged in what you do. Others will see that and want to learn from that, and most importantly–they’ll want to be part of it.

James Noble

James has helped re-define, create and evolve user experiences for over two decades. Founding one of Asia Pacific’s most innovative experience agencies Carter Digital. An active UX industry advisor, mentor, radio presenter, public speaker and serves on a number creative juries globally including Australia’s first UX & Digital Craft representative for Cannes Lion in 2016. Follow James on LinkedIn, Medium, or Twitter.  

What do you think makes a great UX leader?

Empathy. A regularly refuted topic in UX articles. In my humble opinion, this is where UX began. Being in a position of leadership is easy. Being a competent leader, whom people want to listen to is much harder to achieve. If you can embody what you represent and embrace it, people will follow.

Confidence. Cultivate your craft before your passion. Regardless of profession, UX or otherwise. Be sure of yourself and understand the entire suite of approaches available to you: Learn them, break the rules, and remake and refine it. The knowledge to define and tweak the process to ensure the best possible outcome with certainty is invaluable.

Focus. Empower yourself with the knowledge of process from books, speakers and fellow leaders both in and out of the user experience industry. The solutions you are trying to create can be similar but never identical, forever adding to your mental library. People are your focus, not the medium by which a solution is presented.

Awareness. Know your team. Understand each personality, role, drive and focus of every member of your team. Harness their individual drive to empower to push themselves past that imaginary ceiling.

Inspire. Communicate clearly, concisely and emotively. An engaged team wants to learn, and the goal is to make them better than you. Share ALL your knowledge, thought processes and thinking.

How can people lead great UX teams?

No matter how long you’ve been in an industry, never be too senior to muck in and get your hands dirty. People often let their title get in the way of just getting things done, and done well.

Understanding an audience, defining research questions, analysing results, creating personas, user journeys and flows is never linear. People are individuals. Understand and nurture each need, want and goal to harness your team’s drive and success. Inspire, engage and communicate with each individual in a way in which best fits their personality. Turn your understanding and knowledge of the UX process to motivate the team, including yourself. You’ll effectively set expectations, create a roadmap to understanding your audience, needs, wants and goals. Listen. Respect. Consider. Act. Repeat.

Dan Szuc

Dan (@dszuc) is a Principal Consultant at Apogee, as well as the co-founder of the UX Hong Kong conference. He has been involved in the UX field for 25 years, and has been based in Hong Kong for 20 years. Dan has lectured about usability, user-centred design, and user experience globally. He co-wrote The Usability Kit, an implementation guide providing best practices and guidelines for usability teams, and he holds a Bachelor of Science in Information Management from Melbourne University in Australia.

What do you think makes a great UX leader?

I suggest we can consider what makes a great leader. Or we can consider that UX is a word in front of leadership that helps describe a type of leadership that does not exist today. Or maybe it’s about what kind of leader do we need in order to have the type of places we wish to work in going forward?

In the spirit of integrated and connected thinking, the answer probably lies in a hybrid of answers to the questions above. I consider a great leader to be a human leader and a person who does not put process above care. A leader who thinks about the needs of the team and a selflessness to get to great outcomes together. A great leader is also someone who can help a team understand and get clarity on a narrative that everyone can get behind and to work together in respectful ways.

How can people lead great UX teams?

By learning from other people who know how to build a sense of team spirit and know how to help people be at their best. To create work environments that are not just about the delivery of work, but to also provide spaces for people to stop, slow down, reflect and talk about their work and to identify gaps in their own capabilities to assist them to be better on a weekly basis. To give people the necessary artefacts to help structure their routines at work and to have a connected understanding or sense of purpose as to why they come to work in the first place. To know that learning never stops and that we need ways to constantly mature and to have people who can play explicit roles to help us to do that, namely–facilitator, mentor, connector and custodian.

David Travis

Dr David Travis (@userfocus) holds a BSc and a PhD in Psychology and he is a Chartered Psychologist. He has worked in the fields of human factors, usability and user experience since 1989 and has published two books on usability. David helps both large firms and start ups connect with their customers and bring business ideas to market.

What do you think makes a great UX leader? 

I think there are certain characteristics that all good leaders share, whether they work in the field of user experience or in something else. For example, a quick Google search turned up this article. It describes “22 Qualities That Make a Great Leader” such as decisiveness, communication and accountability, and I can see all of them applying to people in a UX leadership role. So I think to really answer this question, we need to address what, if anything, is different about UX leadership?

I want to avoid talking about technical skills here, because although our UX leader needs to know the process to follow to create a good user experience, they won’t be doing the work day-to-day. Technical skills like field research, usability testing, information architecture, interaction design, visual design, technical writing and prototyping are the table stakes—but they are not sufficient to lead a user experience team.

When I mull over this, the one characteristic that I’ve seen in great UX leaders is “Vision”: the ability to describe a future state for the product and to have the soft skills to motivate the team behind this shared vision. As user experience professionals we’re lucky to work in a field where we really can make the world a better place. This is something we do every day by ensuring we’re developing the right kind of products and services for people, avoiding waste and making people’s lives simpler. Articulating this vision to the team is the single most important thing we can do to encourage people to do their best work.

Read part two of the series: Finding Your Path to UX Leadership.

What do you think makes for excellent leadership in UX? Let us know in the forums or leave a comment.

The post The Essential Qualities of a UX Leader appeared first on UX Mastery.

So how do you conduct a persona analysis? This short animated video will give you some helpful pointers.

You can begin by compiling everything you know about your customers and grouping your findings in a spreadsheet. You could use headings relevant to your areas of study, such as industry, device, time, and goals. Or you could create affinity diagrams by organizing your findings on post-it notes. You might start to see patterns—the industries in which customers work, and what devices they use, at what time of day, and where. From here, you can form questions about your customers and work out what they have in common and also how they differ.

Then find the people who form these clusters—either in your existing customer database or by recruiting them— and talk to them. It’s a win-win. You get to learn from customers and they get access to the folks who create the software they rely on. Visiting a customer is ideal. But if you can’t visit in person, a video-chat is your next best option. A persona has a personality—the more you observe and capture during these interviews, the more realistic that personality will be.

You can then tag and analyze your findings. Return to your spreadsheet or affinity diagram and add more data points—office environment, software in use, collaboration habits and so on. Look for the predominant clusters and shared attributes.

You might find that two of your personas share many characteristics. You can combine these personas. Or if there is enough distinction to warrant it, divide the persona into two. Creating personas is an iterative process. What seems right at first glance may not hold up to close scrutiny.

Now it’s time to come up with names and representations for these personas. Your representation might be a photo, an illustration or an icon. The important part is that these personas be distinct and memorable. You want your colleagues, at the mention of the Alice persona, to picture Alice and recall what she represents.

Once you’ve created your personas, you can use them to design for customers with accuracy and confidence. For example, we can say, “This is a feature that Alice would use, but one that Jim might not discover in his typical use of our app.”

Finally, share your personas with as many colleagues as possible. Create posters of your personas and hang them throughout your office. Your goal is to create a shared understanding of just who you work for and how everyone can better serve them.

Personas can give you real insights into your customers, which will your result in you designing a much better product or service. Just remember that personas change over time—create them, learn from them, share them, and then don’t forgot to revisit them and begin the process anew!

The post How To Create UX Personas appeared first on UX Mastery.

Surveys are increasingly becoming a more accepted tool for UX practitioners. Creating a great survey is like designing a great user experience—they are a waste of time and money if the audience, or user, is not at the centre of the process. Designing for your user leads to the gathering of more useful and reliable information.

Let’s take a look at some of the basics of creating and running a useful online survey.

What is a survey?

A survey is a simple tool for gathering information. Surveys typically consist of a set of questions used to assess a participant’s preferences, attitudes, characteristics and opinions on a given topic. As a research method, surveys allow us to count or quantify concepts—a sample or subset of the broader audience is used, the learnings from which can be applied to a broader population.

For example, we might have 100,000 unique users of a website in a given year. If we collect information from 2,000 of those users, we could confidently apply the information to the full 100,000.

When it comes to the digital space, we can use surveys for a variety of purposes including:

• Gathering feedback on a live product or during a pilot;
• Exploring the reasons people visit a website and assessing their experience of that visit (such as a True Intent survey);
• Quantifying results from qualitative research activities such as contextual enquiry or interviews; and
• Evaluating usability, such as the System Usability Scale.

Surveys can be an effective method of identifying:

• Who your users are;
• What your users want;
• What they purchase;
• Where they shop;
• What they own; and
• What they think of your brand or product.

Benefits

Surveys can benefit and inform the design process by:

• Providing information to better understand end users to design better products;
• Mitigating risk of designing the wrong, or a poor, solution for users;
• Providing stakeholders with confidence that a design is, or will be effective. Gathering larger sample sizes, in comparison to qualitative research, often speaks the language of business stakeholders. Whether we like it or not, there is often a perception when it comes to research that more is more.

Before starting

Like with any UX research activity an effective survey must start with a clear understanding of the needs and information required from the project. To create an effective survey both the business context and project objectives must be clearly understood. The business context of the interface or the product includes insight into why it exists and how it supports the business objectives. The project objectives include the reason the survey is being conducted. For example, is the survey being run to understand the end user, inform the direction of a design or assess a live website? The project objectives may inform the type of survey, the collection method and the robustness of the evidence required, which in turn could influence the ideal approach.

Furthermore, a set of research questions should be defined around the information that needs to be collected. These research questions can then be used as a framework for ensuring that the required information is collected effectively. Defining the information  can also be a mechanism for avoiding any irrelevant questions that could creep into the activity.

The information required also provides a framework for the scope of the research.  As a start point to any project, the information to be collected needs to be agreed to by all parties. Without this information the research becomes an exercise in guesswork and is likely to miss the mark for stakeholders and be frustrating for all.

Creating an effective survey

Effective questions and good survey design are important for generating quality data and maximising completion rates. Poor questions result in poor feedback that cannot be relied upon. Dropout is the enemy of achieving a robust sample. It is a win in the first place to get someone to agree to participate in an online survey. It is unforgivable if they drop out because they are bored or frustrated.

The following is a guide to creating an effective and engaging survey:

• Logical flow of questions. In order to make the questions easier and faster to answer they should be grouped with like questions and ordered in a logical manner. Imagine answering questions about your attitude to boat refugees, then being asked about your experience of your favorite fast food chain. The transition can be jarring. Obviously there is a need to be able to change topics, however minimising any unnecessary shifts, particularly at inappropriate times, will result in a more effective survey.
• Questions need to be easy to understand. Many surveys will be completed without the aid of anyone to clarify any confusion. It is important to make sure that questions can be readily understood without any additional information. Of major concern is that ambiguous or difficult to understand questions can be answered incorrectly which can bring the data into question.
• Provide questions appropriate for the audience. People can and will answer just about any question put in front of them. This doesn’t mean that they are qualified to answer them, or are able to provide insightful feedback. A good way to check this is to ask yourself, “will my audience know the answer to that question”?
• Avoid double negatives. Double negatives, particularly in combination with the available responses, can make answering questions difficult. Imagine the question:

For a participant, the response “No, my manager is not non-responsive” could be a challenging idea.

• Avoid questions that contain two concepts. For example:

You may think your manager’s leadership is great but their communication skills could be improved. In that case, how do you decide on an answer? This also gets challenging when analysing the findings. Which skill does the manager need to work on if the rating is poor? All questions should relate to one concept. If required, add an extra question to explore the other concept.

• Use balanced ratings scales. Use an equal number of positive and negative options—this relates to probability. With 4 options the natural spread would be 25% per answer, therefore if we have more positive options than negative we would increase the chances of getting positive feedback. An example of this would be:

A balanced rating scale is shown below:

With a balanced rating scale there is a greater chance of the results reflecting a participant’s true beliefs.

• Avoid answers that overlap. An example of overlapping scale would be:

Obviously for someone who is 24 years of age there are 2 options. The same advice goes for concepts.

• Use open-ended questions. This allows us to better understand what is happening. It is great to use multiple-choice questions to gather proportions of feedback and priority and then ask the more probing, ‘Why’? A common use is to follow-up a satisfaction question. For example, follow-up the question “Overall, how satisfied were you with your experience of the website?” with ‘Why’? as an open text field. This can provide great insights into what was driving the feedback.
• Use writing-for-the-web techniques. Using elements such as bolding key words, avoiding unnecessary copy and using a conversational tone can go a long way to making your survey more engaging and easier for participants to read and understand. For example, a question about gender is simplified in the second option below by removing unnecessary copy:

(Note: Read Jessica Enders’ article for an in-depth exploration of how, when and why you should—or shouldn’t—ask for someone’s sex or gender in a survey).

• Keep it short. There is often a temptation when writing surveys to add more areas for exploration. The problem is that they can become painfully long. A better approach is to keep the survey succinct and run another in a month or two.
• Avoid asking about behaviour. While there is nothing stopping you from asking for feedback regarding behaviour there are better techniques for collecting this type of information that is likely to translate to making better design decisions. For example, trying to assess the effectiveness of myki (Melbourne’s poor public transport ticketing system), observing people buying tickets and travelling throughout the network would yield more accurate and useful feedback than asking people how they had used the system over the last week.
• Include ‘don’t know’ options. There will be cases where participants legitimately don’t have an answer. It is likely to be more helpful to know that your audience don’t hold an opinion on a topic than forcing them into an answer, which can distort the picture by overestimating the positive or negative. The same can be said for neutral options in rating scales.

Once the survey has been written

It is a good idea to test the survey before launching it to your full audience. Initially this could be done with a colleague or someone from your organisation to pilot the survey. Don’t give them too much feedback on the survey background—only provide the information any potential participants would have. Give them clear direction in terms of the type of feedback you are looking for. Something along the lines of:

• Are there any questions that didn’t make sense to you?
• Are there any questions you couldn’t answer or were missing the answer you wanted to provide?

Once you are happy that the questions are clear and can be answered, launch the survey to a subset of your audience. When using a panel, go out to a subset of the total sample or when using an intercept survey (a pop-up on a live website) limit the proportion of visitors who will see the survey. Once you have checked that the questions are being completed as would be expected, go out to the whole sample.

Tools

There are many tools available for scripting and running surveys, ranging from light weight and inexpensive tools right through to specialist market research tools. The more comprehensive tools include greater functionality for including logic and routing in the survey as well as more powerful reporting functionality.

For most UX applications more simple surveys tools such as those discussed in the next section should offer adequate functionality to create surveys. My advice would be to keep surveys simple. A lot of time can be spent creating clever logic and routing within a survey but the more complex the survey, the greater the amount of testing required (a seemingly exponential increase). Often the benefit gained from the additional complexity of the survey does not reflect the time taken to set this up.

Below is a list of some of the survey tools on the market. This is not intended to be an exhaustive list, rather a place to start if you are interested writing and running a survey.

*Only available in paid-for solutions.

Consider the following when choosing a survey tool:

• If you work in a medium to large organisation, someone will already have access to a survey tool. Use it. It will save you money and the time spent trying to choose one. Try marketing, HR or market research teams.
• If you plan to use a research panel for your sample, contact them and see which tools they can integrate with easily.
• For all but the most basic of surveys expect to pay something for the tool. The costs are fairly low—for example SurveyMonkey and SurveyGizmo have $19 offerings which remove most restrictions to allow access to much of the functionality required.

Wrap-up

Surveys can be a really useful UX tool to provide input for the design process. The key to a successful survey is establishing the objectives and information required from the study up front, then making sure the questions asked cover them. Keep at the forefront of your mind the importance of creating a good experience for the participants by writing appropriate questions. Designing an effective survey is going to produce the best results.

Keep it short, keep the participant in mind when writing the questions and engage with your audience—good luck!

The post Better User Research Through Surveys appeared first on UX Mastery.

Many organizations function with an internal focus, and that becomes apparent when customers interact with their various products, services and employees. Every interaction a customer has with an organization has an effect on satisfaction, loyalty, and the bottom line. Plotting out a customer’s emotional landscape by way of a Customer Journey Map, or Experience Map, along their path sheds ­­­­light on key opportunities for deepening those relationships.

What is a Customer Journey Map?

A Customer Journey map is a visual or graphic interpretation of the overall story from an individual’s perspective of their relationship with an organization, service, product or brand, over time and across channels. Occasionally, a more narrative, text-based approach is needed to describe nuances and details associated with a customer experience.  The story is told from the customer’s perspective, but also emphasizes the important intersections between user expectations and business requirements.

Inspired by user research, no two journey maps are alike, and regardless of format they allow organizations to consider interactions from their customers’ points of view, instead of taking an inside-out approach. They are one tool that can help organizations evolve from a transactional approach to one that focuses on long term relationships with customers built on respect, consistency and trust.

All organizations have business goals but leveraging customer journeys as a supporting component of an experience strategy keeps customers (or members, patients, employees, students, donors etc.) at the forefront when making design decisions. They can be used in both current state review and future state visioning to examine the present, highlight pain points and uncover the most significant opportunities for building a better experience for customers.

How Do We Use Them?

Customer engagement is not simply a series of interactions, or getting people to visit a website, “Like” something on FaceBook, or download a mobile app.  Genuine engagement centers on compatibility, and identifying how and where individuals and organizations can exist harmoniously together. Giving thought to how your organization/product/service/brand fits into customers’ lives is crucial.

I also use journey maps to gain internal consensus on how customers should be treated across distinct channels. Holding collaborative workshops with cross-disciplinary teams mixing people who otherwise never communicate with each other can be extremely valuable in large organizations in particular.

Illustrating or describing how the customer experience could be brought to life across channels allows all stakeholders from all areas of the business to better understand the essence of the whole experience from the customer’s perspective. How do they want to be spoken to, what are they thinking, feeling, seeing, hearing, and doing? Journey maps help us explore answers to the “what ifs” that arise during research and conceptual design.

What Components Does a Journey Map Include?

Must-haves

• Personas: the main characters that illustrate the needs, goals, thoughts, feelings, opinions, expectations, and pain points of the user;
• Timeline: a finite amount of time (e.g. 1 week or 1 year) or variable phases (e.g. awareness, decision-making, purchase, renewal);
• Emotion: peaks and valleys illustrating frustration, anxiety, happiness etc.;
• Touchpoints: customer actions and interactions with the organization. This is the WHAT the customer is doing; and
• Channels: where interaction takes place and the context of use (e.g. website, native app, call center, in-store). This is the WHERE they are interacting.

Nice-to-haves

• Moments of truth: A positive interaction that leaves a lasting impression, often planned for a touchpoint known to generate anxiety or frustration; and
• Supporting characters: peripheral individuals (caregivers, friends, colleagues) who may contribute to the experience.

The Process

1. Review Goals

Consider organizational goals for the product or service at large, and specific goals for a customer journey mapping initiative.

2. Gather Research

Review all relevant user research, which includes both qualitative and quantitative findings to provide insights into the customer experience. If more research is needed, get those research activities in the books. Some of my favorite research methods include customer interviews, ethnography & contextual inquiry, customer surveys, customer support/complaint logs, web analytics, social media listening, and competitive intelligence.

3. Touchpoint and Channel brainstorms

As a team, generate a list of the customer touchpoints and the channels on which those touchpoints occur today. Then brainstorm additional touchpoints and/or channels that can be incorporated in the future journeys you will be mapping. For example, the touchpoint could be “pay a bill”, and the channels associated with that touchpoint could be “pay online”, “pay via mail” or “pay in person”.

4. Empathy map

Empathy maps are a depiction of the various facets of a persona and his or her experiences in a given scenario. This exercise helps me organize my observations, build a deeper understanding of customers’ experiences, and draw out surprising insights into what customers need. Empathy maps also provide a foundation of material to fuel journey mapping. The goal is to get a well-rounded sense of how it feels to be that persona in this experience, specifically focusing on what they’re thinking, feeling, seeing, hearing, saying and doing.

5. Brainstorm with lenses

The goal of lensed brainstorming is to generate as many ideas as possible in a short period of time. To gain focus as I generate ideas I use “lenses”—words representing key concepts, brand attributes or mindsets that help us look at a problem or scenario in a different way. For this exercise I recommend that the team agree on 3-5 lens words (for example: accessible, social, comforting), then set the clock for 2 minutes per lens word. Each person individually writes down as many ideas as they can think of in that time. After 2 minutes switch to the next lens word until all lens words have been used as idea inspiration. This ensures that every voice on the team is heard and generates a huge inventory of ideas.

6. Affinity diagram

This is a method to visually organize ideas and find cohesion in the team’s concepts. Affinity diagramming helps us shift from casting a wide net in exploring many possibilities, to gaining focus on the right solutions for this audience. All team members should put their ideas generated in the lensed brainstorming activity up on the wall. Have someone sort the ideas into categories and label them. As a group, begin to consider where you might combine, refine, and remove ideas to form a cohesive vision of the future customer experience.

7. Sketch the journey

Drumroll, please. This is the part you’ve been waiting for! It’s now time to put together all the pieces: timeline, touchpoints, channels, emotional highs and lows, and all the wonderful new ideas the team generated for how to improve the future customer journey. Get creative with how you lay it out—it doesn’t have to be a standard left to right timeline. It could be circular or helical. It could be one large map or it could be an interactive, clickable piece with embedded video. There are no templates, and there are infinite possibilities.

8. Refine and digitize

Journeys don’t always become a sophisticated deliverable—sometimes they begin and end as sticky notes on a wall or sketches on a whiteboard. But most of the time, when you go through the activities to arrive at a solid customer journey map, you want to polish it, leverage it in your work and share it with colleagues across the organization. If visual design isn’t your strong suit, consider collaborating closely with a visual designer who can transform the journey map sketch into an impressive artefact.

While journey maps are usually a tangible deliverable, like the one above, the process of journey mapping is what’s most important – it pushes us to think deeply about how we can use experience design to have a positive impact on our customers.

9. Share and use

It can be beneficial to maintain journey maps over time. For example, you could set a time each quarter or year to evaluate how your current customer experience matches your documented vision journeys. If your organization tracks quantitative KPIs, you can integrate these into a journey benchmarking process. Socializing journeys among stakeholders is critical in moving your organization toward action.

In addition to prioritization, the output of a journey map can serve as a backbone for strategic recommendations and more tactical initiatives.

For example, if you’re a mortgage company and you identify the closing process as a key area of frustration, anxiety and opportunity for engaging with the customer and designing for the “moment of truth”, then mark this as a high priority and get that on your strategic roadmap.

Tips

Schedule enough time to properly go through the recommended process. I’ve found that you can document a current state journey in about 3 hours, and a future state journey in about 5 hours. This makes for a full day to do both for one persona.

Make sure a good mix of people are involved in the journey map creation. It’s helpful to have stakeholder participants from many areas of the organization, as well as people of varying levels of seniority.

Once the journey maps are created, share them with zeal. Shout them from the rooftops and display them prominently in common areas.

The post How to Create a Customer Journey Map appeared first on UX Mastery.

With this in mind, I thought I’d break down the approach I take, and list some tips for others interested in getting started with sketchnoting.

What is Sketchnoting?

The term sketchnoting describes the style of visual note-taking that has become popular at tech conferences in the past few years. Mike Rohde has been the most vocal champion (he has a book coming out on the topic soon), and Eva-Lotta Lamm has been a prolific creator of the art form of late (she’s published a couple of books as well!).

While sketchnoting is usually practiced by attendees at conferences, it can be fun to create them in other situations, too. For example, I recently had a short stint in hospital, and captured my thoughts about surgery as a sketchnote before going into theatre:

Regardless of the circumstance, the skills for creating a sketchnote can be broken down into four basic categories:

• planning
• listening
• processing, and
• drawing.

In this article, I’ll list 20 tips for how to hone your skills in each of these categories.

Planning

For the most part, I don’t really do any preparation before starting a sketchnote. However, there are a few tasks you can do in advance so that you’re best equipped on the day:

1. Tool Up

While it’s not essential to use an expensive art pen and a trendy moleskine notebook to create beautiful sketchnotes, you don’t want to start off on the back foot. Spend a few bucks on the minimum amount of stationery that gives you the best chance at creating something you’re proud of, but doesn’t weigh you down. I recommend:

• A blank notebook large enough so that you won’t feel restricted by space (I use a Derwent A4 Visual Art Diary, with 110 GSM pages)
• A reasonable quality black felt tip pen that you’re confident won’t run out on you half way through (psst: buy a second while you’re at it, in case it does!). You may want to experiment with different tip diameters—I usually use a 0.5 Mitsubishi Uni Pin.
• A Copic grey marker, and possibly one other highlight colour for when you’re feeling really adventurous. Personally I love monochrome sketchnotes, but a splash of colour, when used for highlights, can definitely bring an extra dimension to your masterpiece.
• This last point is a controversial inclusion, but I’d suggest also buying yourself some correction fluid. Purists might suggest that tarnishing your page with liquid paper defeats the purpose, and mistakes are part of the learning process. That’s all well and good, but if you make a minor mistake, I think it’s totally fair game to white it out before presenting it to the world. It’s not ideal, and I avoid it when possible, but a small blob of correction fluid will always look better than an ugly crossed-out mistake, in my opinion.

Note: I have tried a few times to sketchnote using my iPad and the tablet pen that I use with it. There are a couple of great sketching apps for that device (we use Wacom’s Bamboo Paper app for many of the feature images on this site), but none of them give me the flexibility and ability to see the big picture that I need when sketchnoting. Also, correction fluid can damage the screen!

2. Practice On A Recording

Perhaps this is obvious, but if there’s a conference coming up and you’re thinking about sketchnoting some of the sessions, why not get some practice in beforehand? We live in an amazing age, where presentations on sites like Coursera and TED.com are available online for free. Instead of watching yet another Big Bang Theory, plug your laptop into the big screen TV, load up some inspiring presentations, and get sketching!

3. Master Sketching Common Objects

It’s useful to have a cache of objects in your repertoire, ready to pull out as needed. In particular, if you attend tech conferences, there are certain words that will crop up time and again (think “ship”, “cloud”, “user”, “link”). Practice visual representations of these words in advance, so you don’t get flustered trying to draw them for the first time in the middle of a talk. Here are some suggestions:

• Basic shapes: stars, squares, rectangles, triangles, circles,
• Basic objects: ship, home, fish, user, cloud, link, hand, mouse, book, newspaper, magazine, tree, envelope, brick, brain, magnifying glass, pencil, paper, scissors, knife, fork, spoon, iPhone, iPad, desktop, laptop, web browser, cursor
• Basic maps: a screenshot of Google Maps, a quick world map
• Famous brands & logos: Apple, Google, Microsoft, Yahoo, IBM…

Google Images is a great resource for finding inspiration to model your sketches on.

4. Give Yourself A Headstart

For most of the presentations I attend, I like to begin the sketchnote with a caricature of the speaker, as well as the name of the talk, the name of the presenter, and possibly the organisation that he or she represents. You don’t need to follow this format (capturing the likeness of someone’s face is something I still find very difficult to do!). However, if you do, there’s no need to wait for the talk to begin to sketch this information—that stuff is always in the conference schedule, along with a photo of the presenter that you could use as your base for your caricature!)

So while other people are changing rooms and the presenter is being introduced, I like to make a start on my sketch, so that I’m not playing catch-up with meta-data once the presentation has begun.

Listening

Here are a few tips for capturing key points from the talk.

5. Choose Your Seat Carefully

Most people attending a conference presentation don’t really care where they sit—as long as they’re able to see the projector and the presenter’s face. They may be influenced by where their friends are sitting, or may position themselves at the back in case they decide to bail on the talk halfway through.

This means that, for the most part, you should have almost free range to choose a strategic vantage point to obtain the best sketchnote. More often than not, this means sitting in the front row, so you have no visual obstacles. However that’s not always the case—at a recent conference I attended, there were a few round tables at the back. Being able to rest my notebook on a table, rather than on my lap, meant I had a much steadier hand. I think my sketches are better as a result.

6. Look For Easy Wins

I find the easiest presentations to capture in sketchnote form are ones that have very visual slides—graphics, charts, and pictures of LOLcats are all memorable and fairly obvious material to capture on your page. Sure, you can always add ideas of your own, but there’s generally less thought required—the presenter has done a lot of the work in translating words to pictures for you, so make the most of that!

It can be difficult to capture an entire chart on paper—especially if the presenter doesn’t leave the slide up for long enough—so be sure to jot down the axes and key points quickly. Then if the slide disappears, you’ll have already captured the essence of the chart and can round it out later.

7. Latch Onto Quotes

Quotes—whether they be key phrases you hear the presenter say, or quotes by other people that the presenter uses in his talk—are often poignant summaries of a topic, and you should listen carefully for them. When you hear one that resonates or beautifully summarises the point being made, jot it down and wrap it in some fancy talking marks or a speech balloon.

Processing

It takes some practice to be able to truly listen to someone talk while thinking about another topic at the same time. Some might suggest this multi-tasking skill is unique to women, but I know for a fact that there are men who are able to listen to their girlfriend or wife talk while simultaneously choosing which footy team to bet on in the coming weekend, so this is not a skill that is limited to one gender.

Jokes aside, listening and thinking in parallel is something many of us do all the time, and you can tap into this skill while sketchnoting. Here are some tips:

8. Take Advantage Of Down Time

Most talks will have intense moments where the audience’s attention is completely focussed, followed by slower sections in between. This light and shade is the mark of a good presentation, but it’s also a boon for you, as it can provide you with some sketching time.

If you hear something amazing during an intense moment, and don’t want to turn away, don’t! (or jot down the one phrase that summarises the moment). Then, when the moment has passed, you can tune out a little and start to embellish those words (using fancy typography, an accompanying graphic, or additional comments).

9. Pace Yourself

A lot of people are stunned at how I’m able to judge the amount of space it takes to capture the essence of a presentation on a page. I have a secret weapon here—it’s called maths. Yes, I’ll keep an eye on the clock, and if I haven’t filled over half the page by the time that the presentation is halfway complete, then I’ll start getting busy: writing larger, sketching images that might have been playing around in my head, and sifting through what I’ve heard to distil whether any of it is worth writing down or capturing visually using an icon or image that might suit. Likewise, if I’ve burned through page real estate too quickly, I’ll slow down and be more discerning about which snippets of the remaining talk will fill out the remaining space on the page.

10. Curate

It can be tempting to try and capture everything about the presentation. Instead, think of yourself as an art curator whose job it is to sort through the noise, and select a few standout masterpieces to include in your exhibition. Your sketchnote should not serve as a comprehensive reference—it’s a moment in time that reflects the takeaways that you found important.

11. Let It Flow

Don’t confine yourself to a four-column layout, or always move in a strictly left-right fashion. The page is your canvas, and while there’s nothing wrong with creating a very logical, sequential layout, you might try mixing it up on occasion—start in the centre of the page, or move around organically; write sideways, upside down, or in a loop-the-loop when you feel like it. Don’t fret about whether it will look any good, just let the sketch flow.

Additionally, if the presenter hits a technical hurdle, makes an unintended joke, becomes flustered by a heckler, or is interrupted by a security alarm, weave that into your sketch as well! Sometimes the best aspects of a sketchnote are the fortuitous, unplanned activities that accompany the official slide set.

Drawing

Ultimately, the words and pictures you form on the page is what makes your sketchnote. Here are some tips for making them look awesome.

12. Be A C.R.A.P. Sketcher

In The Non-Designer’s Design Book, Robin Williams introduces the concept of C.R.A.P. design. Of course, she’s not suggesting you should arrange your elements on the page in a way that looks terrible, but that you make use of:

• Contrast: This could involve using light and dark colours, combining a straight, rigid typeface with a cursive script, or applying heavy and light shapes.
• Repetition: Litter the same visual cues throughout the design, such as drop caps, bullets, or some little cartoon frog that appears regularly
• Alignment: Line things up on purpose, rather than having them almost match. It looks smarter and makes text easier to read.
• Proximity: Group related objects or concepts on the page. If two concepts are completely unrelated, draw them on opposite ends of the canvas.

These four principles will get you a long way to creating a sketchnote that is pleasing to look out, rather than one that looks like a collection of random scrawls.

13. Use Consistent Type

When I say “type”, I really just mean “make your handwriting neat and the same.” This may be counter intuitive if you have messy handwriting, but the best tip I can give is to slow down when you construct each word. Be patient about crafting each of the letter forms one by one, rather than your usual scrawl. Most conference presentations are 50 minutes long—that’s a lot of time to fill an A4 or letter-sized page, so you don’t need to hurry.

I’ve begun utilising a very tall, narrow typeface lately, mostly because I like the look of it, but also because it allows me to fit more words on one line. It also contrasts well with fancier, more decorative typefaces that I might want to use for contrast, such as a cursive script or a heavy, blocky heading.

14. Employ Type Empathy

Type empathy is a term I first heard back in design school. It occurs when the meaning of a word is accurately reflected by its typeface. Here are some examples:

I’m sure you can think of other examples. It can be really fun to invent empathic typefaces on the fly! If you hear a word that prompts a specific image in your head, see if you can work that image into the type somehow. If that sounds too hard, you could always just keep an eye out for one of the above words (or a synonym) and just copy what I’ve done here!

15. Draw Beautiful Ampersands

The ampersand is a much-loved character by graphic designers. Depending on the typeface, it can be a simple, understated connector or an elaborate, eccentric statement all of its own. Here are a few different types of ampersands for you to practice with. Being able to whip one of these out instead of your usual handwriting can really make a heading stand out.

16. Use Creative Containers

Speech bubbles, thought clouds, sound effect containers, dotted-line rules, double-border rectangles: there are a ton of simple containers that you can add to your sketch to chunk text in a way that is visually interesting. Here are a few of my favourites:

17. Use Creative Connectors

While containers are useful for isolating chunks of text, connectors are used to group those chunks together. Arrows are the most common connectors that I use in my sketchnotes, but there’s no reason you couldn’t include a range of swirly flourishes and other intricate shapes throughout your sketch. In fact, it might be a good idea to keep a separate “doodle” page, where you can experiment and invent new shapes to be brought across into future sketchnotes.

18. Apply Shading & Colour

That Copic grey marker I mentioned at the start of this list is how I add depth to my black and white sketches. You can use it to:

• create shading on one side of an object
• add a shadow on the ground below an object
• highlight text
• colour in containers, for visual contrast
• the list goes on…

Some sketchnoters also like to include a single colour, to highlight text, draw attention to parts of a sketch or make key concepts lift from the page.  The key to colour is not overdoing it—when in doubt, I’d suggest keeping it black and white.

Here’s another dirty secret of mine: the sketchnotes I created at a recent conference all had the grey marker effects applied on the plane home from the conference. I don’t subscribe to any kind of purist mentality that “the sketch must be completed during the presentation” . It only took a few minutes to add grey shades to those sketches, and I think the extra depth that it brings to the sketch is terrific.

19. Find Your Own Style

I’ve given some template approaches in this post which I hope will give you a good framework to build upon, but over time your sketchnotes will develop their own unique personality. Be proud of your sketches, refer to them regularly, and you’ll see an original style evolve.

20. Share Your Work

In general, people love seeing how other people think, and a sketchnote is a good approximation of how you have processed a presentation. Be sure to share your sketch online, either via a blog, a service like Flickr, or by emailing your masterpieces to the Sketchnote Army blog. You’ll find most people will be supportive of your efforts, and you’ll gain confidence from any feedback you receive.

In addition, a sketchnote (either a digital copy or the original piece of paper) is always a wonderful, unique way of thanking a presenter for the time they have put into their presentation.

I hope you’ve found these tips useful, and I look forward to seeing your creations online! Be sure to check out Mike Rohde’s book, The Sketchnote Handbook, which features a two-page spread by yours truly!

If you liked this post, feel free to share it on Twitter or Facebook.

The post Sketchnoting 101: How To Create Awesome Visual Notes appeared first on UX Mastery.