No
matter how sick you might be dealing with unending visual
inconsistency, design systems are still challenging. They can scare any
designer regardless of their experience. Still, if you want to bring
order to chaos, introducing a design system into your workflow is worth
the trouble. Tatsiana Tarkan digs deep into iconography as part of a
design system and shares some doable tips that will turn icon creation
and maintenance into an enjoyable process.
We all have
an inherent tendency to like aesthetic and approachable things. That’s
why any designer strives to deliver an intuitive and comprehensive
design. And any designer knows it’s a pain in the neck, particularly
when it comes to complex projects with lots of pages of design,
components, and prototypes. As someone who has already traveled that
road and learned quite a few valuable lessons, I have some wisdom to
share with you.
Granted, tons of articles have been written about
design systems, their complexity, and all the ways they can benefit a
project. So, I’m not going to waste too many words on the matter.
Instead, in this article, I want to dig deeper into iconography as part of a design system.
Besides, I’ll share with you doable tips that will turn icon creation
and maintenance into an enjoyable — or at least bearable — process.
Shall we?
Before
we actually dive into the alluring and frightening world of
iconography, I want to take some time to introduce you to the concept of
a design system, as well as share my thoughts and rules that I follow
while working with them.
If I were to call a design the way your
interface speaks with your user, then — building on the metaphor — it
would be fair to view a design system as a language.
Simply put, a design system is a functional set of defined technical standards, best user behavior practices, and navigational patterns that are used to build a pixel-perfect digital product.
It is a powerful designer tool that helps you make sure that you will end up with a coherent product and not a pathetic mess.
It
seems that nowadays, designers are obliged to try their hand at
creating or at least adopting a design system. So what exactly makes it
an all-around beneficial thing for the designer lot? Let’s have a look:
The design system makes for the only source of truth since all the components are under one roof and are easily referable.
It hosts all the guidelines
on how to implement existing components. And following the very same
guidelines, designers can easily create new ones that match the former.
In the case of a two- (or more) designer team, a design system allows for visual consistency (which is crucial if your project is major and fast-evolving).
You can either use ready-made design components or alter them swiftly and in accordance with the guideline if any need arises.
You have access to a library of surefire design patterns, which greatly reduces the strain of coming up with new solutions.
That
sounds like a treat, right? Still, creating a design system is
generally viewed as an exceptionally time- and effort-consuming
endeavor. If you do want to develop a design system, there is a way to make the process a bit easier. Enter the atomic design approach.
It’s
been over six years since I first introduced the atomic approach into
my workflow, and let me tell you, it was a game-changer for me as a
designer. This methodology is a blessing if you work on a big project
with a team of fellow designers.
If you know the pain of trying to
track the changes in components throughout the projects, especially if
these components are minor, then you’ll see why I’m so enthusiastic
about the atomic approach. It allows for smooth and well-coordinated
teamwork where every designer is aware of what component they are
creating and how to make it consistent with the rest of the system.
The
atomic design approach was pioneered by Brad Frost (a chemist of all
occupations). It implies building your system brick-by-brick, starting
with the smallest items and going all the way up while sustaining
hierarchy. There are five stages to the process.
Atoms In a nutshell, these are basic HTML elements.
Templates They
provide a context for using molecules and organisms and focus on the
page’s underlying content structure. In other words, templates are the
guidelines.
What exactly makes this approach a thing designers gravitate towards? Here are my two cents on the matter:
Creating a design system resembles playing with a construction set. You begin with the smallest components and progress in size, which means you are eating the elephant a bite at a time and don’t get overwhelmed.
Altering a component in one place will cause updates wherever a certain atom, molecule, or organism is applied. This eliminates any need for manual tweaking of components.
This approach provides designers with design patterns, meaning that you no longer need to create new ones and worry about their consistency.
That’s
clearly not all the advantages of this methodology, so if you are
interested, go ahead and read more about it in Brad Frost’s book.
What
I’m really willing to focus on is our job as designers in creating and
maintaining those fabled design systems, both atomic and regular. More
specifically, on iconography. And even more specifically, on the
pitfalls we have a nasty habit of falling into when dealing with icons
as the atoms of our systems. Off we go.
Since
I’m relying on my own experience when it comes to design systems, it
would only be fair if I shared the biggest issues that I personally have
with iconography in the context of design systems and how I solve them.
I’ll share with you surefire tips on how to keep your iconography
consistent and ensure its smooth integration into design environments.
If
we regard a single icon from the atomic design standpoint, we would
consider it an atom — the smallest but essential element, just like the
color palette or typography. If we continue with our language analogy, I
will take the liberty of calling icons a design’s vocabulary. So, it’s
fairly clear that icons are the actual core of your design.
As any
designer knows, users heavily rely on icons as an interactional element
of an interface. Despite being the smallest of components, icons might
prove to be a major pain in the neck in terms of creation. This is the
lesson I have learned during my tenure as a UX designer.
Tip 1: Since an atom is not just an autonomous element,
you have to think beforehand about how it will behave as part of a
larger component, like a molecule, an organism, or a template.
These are the variables you have to keep in mind when developing an icon:
Is your icon scalable?
Does it have color variations?
Do you classify your icon according to meaning, group, style, or location?
Is there an option to change the icon’s meaning or style?
How can you easily introduce a new icon into an existing roster?
How should you navigate a situation when different designers develop icons separately?
How can you make locating a certain icon within your design system easier?
Here are some challenges that I personally face while developing iconography for a design system:
How should I keep track of icon updates and maintain their consistency?
How should I develop icon creation guidelines?
What should I do if current icons happen to be inconsistent?
How should I inform my design team of any changes?
It
might be hard to wrap your head around so many questions, but worry
not. I’ll try my best to cover all these issues as we go on.
An icon isn’t just a little pictogram with a certain meaning behind it. An icon is a symbol of action, an interactive element of a digital interface that helps users navigate through the system.
In
other words, it is a tool, and the process of building a tool implies
following rules. I found out firsthand that if you master the basic icon
rules, then you’ll be able to build both stand-alone icons and those
that are part of a larger environment with equal efficiency. Besides,
you’ll enhance your ability to create icon sets and various icon types
within a single project, all while maintaining their readability and
accessibility.
Tip 2: Keep consistency by establishing the basic icon rules before building your icon library.
I
use the classic 24px grid for standard icons and a 44px grid for larger
icons. Each grid consists of the padding area (marked in red, 2 px) and
the live area (marked in blue, 20 px). The live area is the space that
your icon content stays inside. Its shape depends on the icon’s body and
could be circular, square, vertical-rectangular, or
horizontal-rectangular.
Before you sit down to draw your icon,
decide how much space your icon’s body will occupy in order to come up
with the proper shape.
Each
icon within a design system has to have a primary size, which is the
size that up to 90% of all icons share. I consider the 24px icon size
suggested by Google’s Material Design to be the golden standard. This
size works well both for desktop and mobile devices.
Still, there
is room for exceptions in this rule when an icon needs to be smaller or
larger. In this case, I employ a 4-pixel step rule. I increase or
decrease the icon’s size by 4 pixels at a time (e.g., I go from 24 to
20, then 16, then 12 px, or 28, 32 px, and so on). I would still
personally prefer the golden standard of 24 pixels since I find smaller
sizes less readable or larger sizes too visually domineering.
Another
key property to consider is the outline weight of your icon if you opt
for this type. If you are building an icon library from scratch, it
would be wise to test several outline weight values before you make a
decision. This is especially crucial for icons that contain fine
details.
Granted, you can assign different weight values to
different types of icons, but you might struggle to write clear
guidelines for your fellow designers. I usually make a conscious
decision to go with a unified outline weight for all the icons, namely, 2
points.
A
solid icon variant might considerably enhance the accessibility and
readability of an interface icon. It’s really handy to have both solid
and outline icon types. But not all your icons should have two options.
If you choose to draw a solid option, determine what parts of your icon
you want to make solid.
As
I’ve mentioned before, an icon is an essential interface element. This
means that an icon should be simplistic, bold, and — what’s even more
important in the context of design systems — created according to the
unified rules.
I have a little trick I use to see how well a new
icon fits the standard. I simply integrate the new icon into the
interface populated by already existing elements. This helps determine
if the new icon matches the rest.
Such
aspects as corner, counterstroke, and stroke terminal provide the
much-desired visual consistency. Obviously, all these elements should be
unified for all the icons within a design system. A comprehensive guide
to icon anatomy is available at Material Design.
Before
I actually share my tips on how to deal with icons within a design
system efficiently, here’s a little backstory to how I came up with
them. It all started when I joined a project that already had an
established host of icons. There were over a hundred of them. And the
number grew because the project was a fast-evolving thing. So, the
design system, like any other, was like a living being, constantly in a
state of change.
The icon library was a mishmash of different icon
types, creating quite a noise. The majority of icons differed in style,
size, and application. Another problem I had was the fact that most of
the icons did not have the source file. So, there was no way to quickly
tweak an icon to match the rest.
The first and most important
thing I did was to establish the basic rules for icon creation (that’s
something we’ve already covered). This step was supposed to keep the
design team from creating inconsistent icons.
Tip 3: Put all your icons on one layout. This way, you’ll get a full visual understanding of your icons and determine repetitive design patterns.
Now, here comes the juicy stuff. Here is my guide on how to sustain iconography in the context of a design system.
Divide your icons into subcategories. This
rule works wonders when you have an array of inconsistent icons on your
hands. There is no rule on what subcategories there should be. It all
depends on your design system and the number of existing icons. In my
case, I established three groups divided by size and icon style, which
resulted in three subcategories: regular icons, detailed icons, and
illustrations. Once you divide your icons in the same manner, it’ll be
easier to apply the same rules to each group. Besides, this approach
allows for a more structured storage of these icons within your design
system.
Determine guidelines for each icon type. The
next step is as wise as it is hard to pull off. You need to assign
certain icon creation rules for each of the icon types (provided you
have more than one). This is the basis upon which all your other
attempts at achieving visual consistency will be built. To tame all the
mismatched icons, I used the basic icon rules we’ve covered above. To
keep track, I created a page in Figma for each of the icon types and
used the basic size as the file name.
Group your icons wisely. When
naming icons, I opt for the semantic section approach. Generally, you
can divide all your icons into groups based on their meaning or
application in the interface. Look at the example below; we have three
distinct semantic sections: Transport, Services, and Warnings. Depending
on their meaning, icons should be assigned to the corresponding
sections. Then, those sections are, in turn, divided into subsections.
For instance, the Transport section has Ground Transport and Air
Transport. The main idea you should stick to is to keep your icons in
separate sections.
Stick to clear names and descriptions. I
have to admit that dividing icons into semantic sections does have a
massive disadvantage: this division could be quite subjective. This is
why it is crucial to add a detailed description to each of the icons.
This will simplify icon search within a design system and will give a
clear understanding of an icon’s application. This is how I create a
description:
Tags: reference words that facilitate searching for an icon within the system.
Usage: a brief description of an icon’s application.
Group Name: the name of the group an icon belongs to. This helps with locating an icon right within the library.
Designs:
an incredibly nifty tool that allows you to insert a link to the design
and documentation that features the icon in question. This way, you’ll
know the context in which the icon is applied.
Description which belongs to the icon. (Large preview)
Use color coding and symbols while updating icon design. This
trick works best when you are not yet done with the icon library, but
you need to communicate to your team which icons are ready to use and
which still need a bit of enhancement. For instance, I mark the names of
finished icons with a green symbol. An orange symbol marks those icons
that need to be improved. And in case I need an icon deleted or drawn
anew, I use a red cross.
Keep non-rasterised versions of icons. It
can be handy to have a non-rasterised version of an icon at arm’s
length. There’ve been cases when I was asked to create a similar icon or
an icon that could use the same graphic forms as the existing ones.
Should this happen again, I can simply take the original file and easily
draw an icon. I store all the non-rasterised icons on a separate page
in the file following the defined hierarchy.
Rasterise the icon vector. Be
sure to apply the Outline Stroke feature before you create the icon
component. This will allow for easy color change (more on this in the
next tip) and scaling.
Mind the colors of your icons. I
suggest keeping icons in the primary, most commonly used color by
default. Another worthwhile thing to do is to name all icon colors
according to their intended use and the interactions they perform. In
order to do that, you need to equip your color library with a separate
set of colors for all icon states, like primary, hover, and disabled.
Make sure to name each set properly.
Color names according to interactions and type of icons. (Large preview)The color palette in the main design system file. (Large preview)The color description. (Large preview)
Assign a designer to maintain icons in the system. This
is a seemingly trivial tip that, however, will save you trouble
maintaining style and categorization consistency. I’ve personally had
edge cases when the established rules failed. Having a designated
designer who knew their way around the system helped to find a quick
solution.
No
matter how sick you might be dealing with unending visual
inconsistency, design systems are still challenging. They can scare any
designer regardless of their experience. Still, if you want to bring
order to chaos, introducing a design system into your workflow is worth
the trouble, especially when it comes to maintaining iconography.
After all, iconography is the most volatile part of a design system in terms of visual variety.
That’s why iconography was the biggest challenge I had to face in my
tenure as a designer. And that’s exactly why I am genuinely proud that
I’ve tamed that beast and can now share my hacks with you.
What
can we do to make a mobile app better? What subsidiary features are
worth providing for our users? I have some ideas. You might, too. So,
let’s compare our notes. Without any prescriptions attached, here are
seven features I believe can palpably improve a user’s experience with a
mobile app.
Remember the “mobile first” mantra? The
idea was born out of the early days of responsive web design. Rather
than design and build for the “desktop” up front, a “mobile-first”
approach treats small screens as first-class citizens. There’s a reduced
amount of real estate, certainly less than the number of pixels we get
from the viewport of Firefox expanded fullscreen on a 27-inch studio
monitor.
The constraint is a challenge to make sure that whatever is sent to mobile devices is directly relevant to what users should need;
nothing more, nothing less. Anything more additive to the UI can be
reserved for wider screens where we’re allowed to stretch out and make
more liberal use of space.
/* A sample CSS snippet for a responsive main content *//* Base Styles */.main-content{container: main / inline-size;}.gallery{display: grid;gap: 1rem;}/* Container is wider than or equal to 700px */@container main (width >= 700px){.gallery{grid-template-columns: 1fr 1fr;}}/* Container is wider than or equal to 1200px */@container main (width >= 1200px){.gallery{grid-template-columns:repeat(4, 1fr);}}
Now,
I’m not here to admonish anyone who isn’t using a mobile-first approach
when designing and building web interfaces. If anything, the last five
or so years have shown us just how unpredictable of a medium the web is, including what sort of device is displaying our work all the way down to a user’s individual preferences.
Even
so, there are things that any designer and developer should consider
when working with mobile interfaces. Now that we’re nearly 15 years into
responsive web design as a practice and craft, users are beginning to
form opinions about what to expect when trying to do certain things in a
mobile interface. I know that I have expectations. I am sure you have
them as well.
I’ve been keeping track of the mobile interfaces I use and have started finding common patterns that feel
mobile in nature but are more desktop-focused in practice. While
keeping track of the mobile interfaces I use, I’ve found common patterns
that are unsuitable for small screens and thus could use some updates.
Here are some reworked features that are worth considering for mobile
interfaces.
Economically-Sized Forms
There
are myriad problems that come up while completing mobile forms — e.g.,
small tap targets, lack of offline support, and incorrect virtual
keyboards, to name a few — but it’s how a mobile form interacts with the
device’s virtual keyboard that draws my ire the most.
The keyboard obscures the form more times than not. You tap a form field, and the keyboard slides up, and — poof! — it’s as though half the form is chopped out of view. If you’re thinking, Meh, all that means is a little extra scrolling,
consider that scrolling isn’t always a choice. If the page is a short
one with only the form on it, it’s highly possible what you see on the
screen is what you get.
A more delightful user experience for mobile forms is to take a “less is more” approach. Display one form field at a time for an economical layout
that allows the field and virtual keyboard to co-exist in harmony
without any visual obstructions. Focusing the design on the top half of
the viewport with room for navigation controls and microcopy creates a
seamless flow from one form input to the next.
More Room For Searching
Search
presents a dichotomy: It is incredibly useful, yet is treated as an
afterthought, likely tucked in the upper-right corner of a global
header, out of view and often further buried by hiding the form input
until the user clicks some icon, typically a magnifying glass. (It’s
ironic we minimize the UI with a magnifying glass, isn’t it?)
In
this example, combining iconography convolutes the meaning of what the
component is and does. The label also fails to accurately identify the
feature. (Large preview)
The problem with burying search in a mobile context is two-fold:
The feature is less apparent, and
The space to enter a search query, add any filters, and display results is minimized.
That
may very well be acceptable if the site has only a handful of pages to
navigate. However, if the search allows a user to surface relevant
content and freely move about an app, then you’re going to want to give
it higher prominence.
The Smashing Magazine homepage displayed at a mobile breakpoint. (Large preview)
Some
sites even have search forms that occupy the full screen without
surrounding components, offering a “distraction-free” interface for
typing queries.
No Drop-Downs, If Possible
The <select> element can negatively impact mobile UX in two glaring ways:
An expanding <select> with so many options that it produces excessive scrolling.
Scrolling
excessively, particularly on long pages, produces an awkward situation
where the page continues scrolling after already scrolling through the
list of <option>s.
I’ll come across these situations, stare at my phone, and ask:
Do I really need a <select> populated with one hundred years to submit my birthdate?
Seems like an awful lot of trouble to sort through one hundred years compared to manually typing in a four-digit value myself.
A
better pattern for making list selections, if absolutely needed, in a
space-constrained mobile layout could be something closer to the ones
used by iOS and Android devices by default. Sure, there’s scrolling
involved, but within a confined space that leaves the rest of the UI
alone.
A Restrained Overview
A
dashboard overview in a mobile app is something that displays key data
to users right off the bat, surfacing common information that the user
would otherwise have to seek out. There are great use cases for
dashboards, many of which you likely interact with daily, like your
banking app, a project management system, or even a page showing today’s
baseball scores. The WordPress dashboard is a perfect example, showing
site activity, security checks, traffic, and more.
The WordPress administrative dashboard displays a summary of various site activities at a glance. (Large preview)
Dashboards
are just fine. But the sensitive information they might contain is what
worries me when I’m viewing a dashboard on a mobile device.
Let’s
say I’m having dinner with friends at a restaurant. We split the check.
To pay my fair share, I take out my phone and log into my banking app,
and… the home screen displays my bank balance in big, bold numbers to
the friends sitting right next to me, one of whom is the gossipiest of
the bunch. There goes a bit of my pride.
That’s an extreme
illustration because not all apps convey that level of sensitive
information. But many do, and the care we put into protecting a user’s
information from peeping eyeballs is only becoming more important as
entire industries, like health care and education, lean more heavily
into online experiences.
My advice: Hide sensitive information until prompted by the user to display it.
Hiding
sensitive information behind a user prompt is an effective approach to
protect it from onlookers while continuing to provide convenient access.
(Large preview)
There’s
a natural order to things, particularly when logging into a web app. We
log in, see a welcome message, and are taken to a dashboard before we
tap on some item that triggers some sort of action to perform. In other
words, it takes a few steps and walking through a couple of doors to get
to accomplish what we came to do.
What if we put actions earlier
in the login flow? As in, they are displayed right along with the login
form. This is what we call a shortcut.
Let’s take
the same restaurant example from earlier, where I’m back at dinner and
ready to pay. This time, however, I will open a different bank app. This
one has shortcuts next to the login form, one of which is a “Scan to
Pay” option. I tap it, log in, and am taken straight to the scanning
feature that opens the camera on my device, completely bypassing any
superfluous welcome messaging or dashboard. This spares the user both
time and effort (and prevents sensitive information from leaking into
view to boot).
Signing in can take a more personalized path by offering shortcuts. (Large preview)
Mobile
operating systems also provide options for shortcuts when long-pressing
an app’s icon on the home screen, which also can be used to an app’s
advantage.
It may be possible to leverage an operating system’s default controls, like the long-press feature in iOS. (Large preview)
All
modern mobile operating systems are smart enough to tailor the virtual
keyboard for specialized form inputs. A form field markup with type="email", for instance, triggers an onscreen keyboard that shows the “@” key in the primary view, preventing users from having to tap Shift to reveal it in a subsequent view. The same is true with URLs, where a “.com” key surfaces for inputs with type="url".
Onscreen keyboard for an email field, with @ key shown upfront. (Large preview)
The
right keyboard saves the effort of hunting down relevant special
characters and numbers for specific fields. All we need to do is to use
the right attributes and semantics for those fields, like, type=email, type=url, type=tel, and such.
This
may have been one of the first things that came to your mind when
reading the article title. That’s because small text is prevalent in
mobile interfaces. It’s not wrong to scale text in response to smaller
screens, but where you set the lower end of the range may be too small
for many users, even those with great vision.
The default size of body text is 16px
on the web. That’s thanks to user agent styling that’s consistent
across all browsers, including those on mobile platforms. But what
exactly is the ideal size for mobile? The answer is not entirely clear.
For example, Apple’s Human Interface Guidelines
do not specify exact font sizes but rather focus on the use of Dynamic
Text that adjusts the size of content to the user’s device-level
preferences. Google’s Material Design guidelines are more concrete but
are based on three scales: small, medium, and large. The following table
shows the minimum font sizes for each scale based on the system’s typography tokens.
Scale
Body Text (pt)
Body Text (px)
Small
12pt
16px
Medium
14pt
18.66px
Large
16pt
21.33px
The real standard we ought to be looking at is the current WCAG 2.2, and here’s what it says on the topic:
“When
using text without specifying the font size, the smallest font size
used on major browsers for unspecified text would be a reasonable size
to assume for the font.”
So, bottom line is that the bottom end of a font’s scale matches the web’s default 16px if we accept Android’s “Small” defaults. But even then, there are caveats because WCAG is more focused on contrast than size.
Like, if the font in use is thin by default, WCAG suggests bumping up
the font size to produce a higher contrast ratio between the text and
the background it sits against.
There are many, many articles that
can give you summaries of various typographical guidelines and how to
adhere to them for optimal font sizing. The best advice I’ve seen,
however, is Eric Bailey rallying us to “beat the “Reader Mode” button.
Eric is talking more specifically about preventing clutter in an
interface, but the same holds for font sizing. If the text is tiny or
thin, I’m going to bash that button on your site with no hesitation.
The Kindle reading app on a mobile device with font sizing and style controls. (Large preview)
Wrapping Up
Everything
we’ve covered here in this article is personal irritations I feel when
interacting with different mobile interfaces. I’m sure you have your own
set of annoyances, and if you do, I’d love to read them in the comments
if you’re willing to share. And someone else is likely to have even
more examples.
The point is that we’re in some kind of “post-responsive” era of web design,
one that looks beyond how elements stack in response to the viewport to
consider user preferences, privacy, and providing optimal experiences
at any breakpoint regardless of whatever device is used.
Communication
theory is not just an academic exercise. UX practitioners benefit from
an understanding of what we know about effective communication. Victor
Yocco reviews the components of the Transactional Model of
communication, explaining how we might apply this framework to
preparing, conducting, and analysing our UX research. You will
understand how many UX research best practices align with the model and
get an example of a tool for tracking alignment.
Communication
is in everything we do. We communicate with users through our research,
our design, and, ultimately, the products and services we offer. UX
practitioners and those working on digital product teams benefit from
understanding principles of communication and their application to our
craft. Treating our UX processes as a mode of communication between
users and the digital environment can help unveil in-depth, actionable
insights.
In this article, I’ll focus on UX research. Communication is a core component of UX research,
as it serves to bridge the gap between research insights, design
strategy, and business outcomes. UX researchers, designers, and those
working with UX researchers can apply key aspects of communication
theory to help gather valuable insights, enhance user experiences, and
create more successful products.
Communications
as an academic field encompasses various models and principles that
highlight the dynamics of communication between individuals and groups.
Communication theory examines the transfer of information from one
person or group to another. It explores how messages are transmitted,
encoded, and decoded, acknowledges the potential for interference (or
‘noise’), and accounts for feedback mechanisms in enhancing the
communication process.
In this article, I will focus on the Transactional Model of Communication.
There are many other models and theories in the academic literature on
communication. I have included references at the end of the article for
those interested in learning more.
The Transactional Model of Communication (Figure 1) is a two-way process that emphasizes the simultaneous sending and receiving of messages and feedback.
Importantly, it recognizes that communication is shaped by context and
is an ongoing, evolving process. I’ll use this model and understanding
when applying principles from the model to UX research. You’ll find that
much of what is covered in the Transactional Model would also fall
under general best practices for UX research, suggesting even if we
aren’t communications experts, much of what we should be doing is
supported by research in this field.
Let’s take a deeper dive into the six key factors and their applications within the realm of UX research:
Sender:
In UX research, the sender is typically the researcher who conducts
interviews, facilitates usability tests, or designs surveys. For
example, if you’re administering a user interview, you are the sender
who initiates the communication process by asking questions.
Receiver:
The receiver is the individual who decodes and interprets the messages
sent by the sender. In our context, this could be the user you interview
or the person taking a survey you have created. They receive and
process your questions, providing responses based on their understanding
and experiences.
Message: This is the content
being communicated from the sender to the receiver. In UX research, the
message can take various forms, like a set of survey questions,
interview prompts, or tasks in a usability test.
Channel:
This is the medium through which the communication flows. For instance,
face-to-face interviews, phone interviews, email surveys administered
online, and usability tests conducted via screen sharing are all
different communication channels. You might use multiple channels
simultaneously, for example, communicating over voice while also using a
screen share to show design concepts.
Noise:
Any factor that may interfere with the communication is regarded as
‘noise.’ In UX research, this could be complex jargon that confuses
respondents in a survey, technical issues during a remote usability
test, or environmental distractions during an in-person interview.
Feedback:
The communication received by the receiver, who then provides an
output, is called feedback. For example, the responses given by a user
during an interview or the data collected from a completed survey are
types of feedback or the physical reaction of a usability testing
participant while completing a task.
Applying the Transactional Model of Communication to Preparing for UX Research #
We
can become complacent or feel rushed to create our research protocols. I
think this is natural in the pace of many workplaces and our need to
deliver results quickly. You can apply the lens of the Transactional
Model of Communication to your research preparation without adding much
time. Applying the Transactional Model of Communication to your
preparation should:
Improve Clarity The
model provides a clear representation of communication, empowering the
researcher to plan and conduct studies more effectively.
Minimize misunderstanding By highlighting potential noise sources, user confusion or misunderstandings can be better anticipated and mitigated.
Enhance research participant participation With
your attentive eye on feedback, participants are likely to feel valued,
thus increasing active involvement and quality of input.
You can address the specific elements of the Transactional Model through the following steps while preparing for research:
In
UX research, the sender can often be the UX researcher conducting the
study, while the receiver is usually the research participant.
Understanding this dynamic can help researchers craft questions or tasks
more empathetically and efficiently. You should try to collect some
information on your participant in advance to prepare yourself for
building a rapport.
For example, if you are conducting contextual
inquiry with the field technicians of an HVAC company, you’ll want to
dress appropriately to reflect your understanding of the context in
which your participants (receivers) will be conducting their work.
Showing up dressed in formal attire might be off-putting and create a
negative dynamic between sender and receiver.
The
message in UX research typically is the questions asked or tasks
assigned during the study. Careful consideration of tenor, terminology,
and clarity can aid data accuracy and participant engagement. Whether
you are interviewing or creating a survey, you need to double-check that
your audience will understand your questions and provide meaningful
answers. You can pilot-test your protocol or questionnaire with a few
representative individuals to identify areas that might cause confusion.
Using
the HVAC example again, you might find that field technicians use
certain terminology in a different way than you expect, such as asking
them about what “tools” they use to complete their tasks yields you an
answer that doesn’t reflect digital tools you’d find on a computer or
smartphone, but physical tools like a pipe and wrench.
The
channel selection depends on the method of research. For instance,
face-to-face methods might use physical verbal communication, while
remote methods might rely on emails, video calls, or instant messaging.
The choice of the medium should consider factors like tech
accessibility, ease of communication, reliability, and participant
familiarity with the channel. For example, you introduce an additional
challenge (noise) if you ask someone who has never used an iPhone to
test an app on an iPhone.
Minimizing Noise
Noise
in UX research comes in many forms, from unclear questions inducing
participant confusion to technical issues in remote interviews that
cause interruptions. The key is to foresee potential issues and have
preemptive solutions ready.
Facilitating Feedback
You
should be prepared for how you might collect and act on participant
feedback during the research. Encouraging regular feedback from the user
during UX research ensures their understanding and that they feel
heard. This could range from asking them to ‘think aloud’ as they
perform tasks or encouraging them to email queries or concerns after the
session. You should document any noise that might impact your findings
and account for that in your analysis and reporting.
Track Your Alignment to the Framework
You
can track what you do to align your processes with the Transactional
Model prior to and during research using a spreadsheet. I’ll provide an
example of a spreadsheet I’ve used in the later case study section of
this article. You should create your spreadsheet during the process of
preparing for research, as some of what you do to prepare should align
with the factors of the model.
You can use these tips for
preparation regardless of the specific research method you are
undertaking. Let’s now look closer at a few common methods and get
specific on how you can align your actions with the Transactional Model.
Applying the Transactional Model to Common UX Research Methods
UX
research relies on interaction with users. We can easily incorporate
aspects of the Transactional Model of Communication into our most common
methods. Utilizing the Transactional Model in conducting interviews,
surveys, and usability testing can help provide structure to your
process and increase the quality of insights gathered.
Interviews
Interviews
are a common method used in qualitative UX research. They provide the
perfect method for applying principles from the Transactional Model. In
line with the Transactional Model, the researcher (sender) sends
questions (messages) in-person or over the phone/computer medium
(channel) to the participant (receiver), who provides answers (feedback)
while contending with potential distraction or misunderstanding
(noise). Reflecting on communication as transactional can help remind us
we need to respect the dynamic between ourselves and the person we are
interviewing. Rather than approaching an interview as a unidirectional interrogation, researchers need to view it as a conversation.
Applying
the Transactional Model to conducting interviews means we should
account for a number of facts to allow for high-quality communication.
Note how the following overlap with what we typically call best
practices.
Asking Open-ended Questions
To
truly harness a two-way flow of communication, open-ended questions,
rather than close-ended ones, are crucial. For instance, rather than
asking, “Do you use our mobile application?” ask, “Can you describe your use of our mobile app?”. This encourages the participant to share more expansive and descriptive insights, furthering the dialogue.
Actively Listening
As
the success of an interview relies on the participant’s responses,
active listening is a crucial skill for UX researchers. The researcher
should encourage participants to express their thoughts and feelings
freely. Reflective listening techniques, such as
paraphrasing or summarizing what the participant has shared, can
reinforce to the interviewee that their contributions are being
acknowledged and valued. It also provides an opportunity to clarify
potential noise or misunderstandings that may arise.
Being Responsive
Building
on the simultaneous send-receive nature of the Transactional Model,
researchers must remain responsive during interviews. Providing
non-verbal cues (like nodding) and verbal affirmations (“I see,”
“Interesting”) lets participants know their message is being received
and understood, making them feel comfortable and more willing to share.
Minimizing Noise
We
should always attempt to account for noise in advance, as well as
during our interview sessions. Noise, in the form of misinterpretations
or distractions, can disrupt effective communication. Researchers can
proactively reduce noise by conducting a dry run in advance of the scheduled interviews.
This helps you become more fluent at going through the interview and
also helps identify areas that might need improvement or be
misunderstood by participants. You also reduce noise by creating a
conducive interview environment, minimizing potential distractions, and
asking clarifying questions during the interview whenever necessary.
For
example, if a participant uses a term the researcher doesn’t
understand, the researcher should politely ask for clarification rather
than guessing its meaning and potentially misinterpreting the data.
Additional
forms of noise can include participant confusion or distraction. You
should let participants know to ask if they are unclear on anything you
say or do. It’s a good idea to always ask participants to put their
smartphones on mute. You should only provide information critical to the process when introducing the interview
or tasks. For example, you don’t need to give a full background of the
history of the product you are researching if that isn’t required for
the participant to complete the interview. However, you should let them
know the purpose of the research, gain their consent to participate, and
inform them of how long you expect the session to last.
Strategizing the Flow
Researchers
should build strategic thinking into their interviews to support the
Transaction Model. Starting the interview with less intrusive questions
can help establish rapport and make the participant more comfortable,
while more challenging or sensitive questions can be left for later when
the interviewee feels more at ease.
A well-planned interview
encourages a fluid dialogue and exchange of ideas. This is another area
where conducting a dry run can help to ensure high-quality research. You
and your dry-run participants should recognize areas where questions
aren’t flowing in the best order or don’t make sense in the context of
the interview, allowing you to correct the flow in advance.
While
much of what the Transactional Model informs for interviews already
aligns with common best practices, the model would suggest we need to
have a deeper consideration of factors that we can sometimes give less
consideration when we become overly comfortable with interviewing or are
unaware of the implications of forgetting to address the factors of
context considerations, power dynamics, and post-interview actions.
Context Considerations
You
need to account for both the context of the participant, e.g., their
background, demographic, and psychographic information, as well as the
context of the interview itself. You should make subtle yet meaningful
modifications depending on the channel you are conducting an interview.
For
example, you should utilize video and be aware of your facial and
physical responses if you are conducting an interview using an online
platform, whereas if it’s a phone interview, you will need to rely on
verbal affirmations that you are listening and following along, while
also being mindful not to interrupt the participant while they are
speaking.
Power Dynamics
Researchers
need to be aware of how your role, background, and identity might
influence the power dynamics of the interview. You can attempt to
address power dynamics by sharing research goals transparently and
addressing any potential concerns about bias a participant shares.
We
are responsible for creating a safe and inclusive space for our
interviews. You do this through the use of inclusive language, listening
actively without judgment, and being flexible to accommodate different
ways of knowing and expressing experiences. You should also empower participants as collaborators whenever possible.
You can offer opportunities for participants to share feedback on the
interview process and analysis. Doing this validates participants’
experiences and knowledge and ensures their voices are heard and valued.
You
have a number of options for actions that can close the loop of your
interviews with participants in line with the “feedback” the model
suggests is a critical part of communication. Some tactics you can
consider following your interview include:
Debriefing Dedicate
a few minutes at the end to discuss the participant’s overall
experience, impressions, and suggestions for future interviews.
Short surveys Send a brief survey via email or an online platform to gather feedback on the interview experience.
Follow-up calls Consider
follow-up calls with specific participants to delve deeper into their
feedback and gain additional insight if you find that is warranted.
Thank you emails Include a “feedback” section in your thank you email, encouraging participants to share their thoughts on the interview.
You
also need to do something with the feedback you receive. Researchers
and product teams should make time for reflexivity and critical
self-awareness.
We shouldn’t practice our craft in a silo. Instead, seeking feedback from colleagues and mentors to maintain ethical research practices should be a standard practice for interviews and all UX research methods.
By
considering interviews as an ongoing transaction and exchange of ideas
rather than a unidirectional Q&A, UX researchers can create a more
communicative and engaging environment. You can see how models of
communication have informed best practices for interviews. With a better
knowledge of the Transactional Model, you can go deeper and check your
work against the framework of the model.
Surveys
The
Transactional Model of Communication reminds us to acknowledge the
feedback loop even in seemingly one-way communication methods like
surveys. Instead of merely sending out questions and collecting
responses, we need to provide space for respondents to voice their
thoughts and opinions freely. When we make participants feel heard,
engagement with our surveys should increase, dropouts should decrease,
and response quality should improve.
Like other methods, surveys
involve the researcher(s) creating the instructions and questionnaire
(sender), the survey, including any instructions, disclaimers, and
consent forms (the message), how the survey is administered, e.g.,
online, in person, or pen and paper (the channel), the participant
(receiver), potential misunderstandings or distractions (noise), and
responses (feedback).
Designing the Survey
Understanding
the Transactional Model will help researchers design more effective
surveys. Researchers are encouraged to be aware of both their role as
the sender and to anticipate the participant’s perspective as the
receiver. Begin surveys with clear instructions, explaining why you’re
conducting the survey and how long it’s estimated to take. This
establishes a more communicative relationship with respondents right
from the start. Test these instructions with multiple people prior to
launching the survey.
Crafting Questions
The
questions should be crafted to encourage feedback and not just a simple
yes or no. You should consider asking scaled questions or items that
have been statistically validated to measure certain attributes of
users.
For example, if you were looking deeper at a mobile banking application, rather than asking, “Did you find our product easy to use?” you would want to break that out into multiple aspects of the experience and ask about each with a separate question such as “On
a scale of 1–7, with 1 being extremely difficult and 7 being extremely
easy, how would you rate your experience transferring money from one
account to another?”.
Minimizing Noise
Reducing
‘noise,’ or misunderstandings, is crucial for increasing the
reliability of responses. Your first line of defense in reducing noise
is to make sure you are sampling from the appropriate population you
want to conduct the research with. You need to use a screener that will filter out non-viable participants
prior to including them in the survey. You do this when you correctly
identify the characteristics of the population you want to sample from
and then exclude those falling outside of those parameters.
Additionally,
you should focus on prioritizing finding participants through random
sampling from the population of potential participants versus using a
convenience sample, as this helps to ensure you are collecting reliable
data.
When looking at the survey itself, there are a number of
recommendations to reduce noise. You should ensure questions are easily
understandable, avoid technical jargon, and sequence questions
logically. A question bank should be reviewed and tested before being
finalized for distribution.
For example, question statements like “Do you use and like this feature?”
can confuse respondents because they are actually two separate
questions: do you use the feature, and do you like the feature? You
should separate out questions like this into more than one question.
You
should use visual aids that are relevant whenever possible to enhance
the clarity of the questions. For example, if you are asking questions
about an application’s “Dashboard” screen, you might want to provide a
screenshot of that page so survey takers have a clear understanding of
what you are referencing. You should also avoid the use of jargon if you
are surveying a non-technical population and explain any terminology
that might be unclear to participants taking the survey.
The Transactional Model suggests active participation in communication is necessary for effective communication.
Participants can become distracted or take a survey without intending
to provide thoughtful answers. You should consider adding a question
somewhere in the middle of the survey to check that participants are
paying attention and responding appropriately, particularly for longer
surveys.
This is often done using a simple math problem such as “What is the answer to 1+1?”
Anyone not responding with the answer of “2” might not be adequately
paying attention to the responses they are providing and you’d want to
look closer at their responses, eliminating them from your analysis if
deemed appropriate.
Encouraging Feedback
While
descriptive feedback questions are one way of promoting dialogue, you
can also include areas where respondents can express any additional
thoughts or questions they have outside of the set question list. This
is especially useful in online surveys, where researchers can’t
immediately address participant’s questions or clarify doubts.
You should be mindful that too many open-ended questions can cause fatigue,
so you should limit the number of open-ended questions. I recommend two
to three open-ended questions depending on the length of your overall
survey.
Post-Survey Actions
After
collecting and analyzing the data, you can send follow-up
communications to the respondents. Let them know the changes made based
on their feedback, thank them for their participation, or even share a
summary of the survey results. This fulfills the Transactional Model’s
feedback loop and communicates to the respondent that their input was
received, valued, and acted upon.
You can also meet this
suggestion by providing an email address for participants to follow up
if they desire more information post-survey. You are allowing them to
complete the loop themselves if they desire.
Applying the
transactional model to surveys can breathe new life into the way surveys
are conducted in UX research. It encourages active participation from
respondents, making the process more interactive and engaging while
enhancing the quality of the data collected. You can experiment with
applying some or all of the steps listed above. You will likely find you
are already doing much of what’s mentioned, however being explicit can
allow you to make sure you are thoughtfully applying these principles
from the field communication.
Usability Testing
Usability
testing is another clear example of a research method highlighting
components of the Transactional Model. In the context of usability
testing, the Transactional Model of Communication’s application opens a
pathway for a richer understanding of the user experience by positioning
both the user and the researcher as sender and receiver of
communication simultaneously.
Here are some ways a researcher can use elements of the Transactional Model during usability testing:
Task Assignment as Message Sending
When
a researcher assigns tasks to a user during usability testing, they act
as the sender in the communication process. To ensure the user
accurately receives the message, these tasks need to be clear and
well-articulated. For example, a task like “Register a new account on
the app” sends a clear message to the user about what they need to do.
You
don’t need to tell them how to do the task, as usually, that’s what we
are trying to determine from our testing, but if you are not clear on
what you want them to do, your message will not resonate in the way it
is intended. This is another area where a dry run in advance of the
testing is an optimal solution for making sure tasks are worded clearly.
Observing and Listening as Message Receiving
As
the participant interacts with the application, concept, or design, the
researcher, as the receiver, picks up on verbal and nonverbal cues. For
instance, if a user is clicking around aimlessly or murmuring in
confusion, the researcher can take these as feedback about certain
elements of the design that are unclear or hard to use. You can also ask
the user to explain why they are giving these cues you note as a way to
provide them with feedback on their communication.
Real-time Interaction
The
transactional nature of the model recognizes the importance of
real-time interaction. For example, if during testing, the user is
unsure of what a task means or how to proceed, the researcher can
provide clarification without offering solutions or influencing the
user’s action. This interaction follows the communication flow
prescribed by the transactional model. We lose the ability to do this
during unmoderated testing; however, many design elements are forms of
communication that can serve to direct users or clarify the purpose of
an experience (to be covered more in article two).
Noise
In
usability testing, noise could mean unclear tasks, users’ preconceived
notions, or even issues like slow software response. Acknowledging noise
can help researchers plan and conduct tests better. Again, carrying out
a pilot test can help identify any noise in the main test scenarios,
allowing for necessary tweaks before actual testing. Other forms of
noise can be less obvious but equally intrusive. For example, if you are
conducting a test using a Macbook laptop and your participant is used
to a PC, there is noise you need to account for, given their
unfamiliarity with the laptop you’ve provided.
The fidelity of the
design artifact being tested might introduce another form of noise.
I’ve always advocated testing at any level of fidelity, but you should
note that if you are using “Lorem Ipsum” or black and white designs,
this potentially adds noise.
One of my favorite examples of this
was a time when I was testing a financial services application, and the
designers had put different balances on the screen; however, the total
for all balances had not been added up to the correct total. Virtually
every person tested noted this discrepancy, although it had nothing to
do with the tasks at hand. I had to acknowledge we’d introduced noise to
the testing. As at least one participant noted, they wouldn’t trust a
tool that wasn’t able to total balances correctly.
Encouraging Feedback
Under
the Transactional Model’s guidance, feedback isn’t just final thoughts
after testing; it should be facilitated at each step of the process.
Encouraging ‘think aloud’ protocols, where the user verbalizes their thoughts, reactions, and feelings during testing, ensures a constant flow of useful feedback.
You
are receiving feedback throughout the process of usability testing, and
the model provides guidance on how you should use that feedback to
create a shared meaning with the participants. You will ultimately
summarize this meaning in your report. You’ll later end up uncovering if
this shared meaning was correctly interpreted when you design or
redesign the product based on your findings.
We’ve
now covered how to apply the Transactional Model of Communication to
three common UX Research methods. All research with humans involves
communication. You can break down other UX methods using the Model’s
factors to make sure you engage in high-quality research.
Analyzing and Reporting UX Research Data Through the Lens of the Transactional Model
The
Transactional Model of Communication doesn’t only apply to the data
collection phase (interviews, surveys, or usability testing) of UX
research. Its principles can provide valuable insights during the data
analysis process.
The Transactional Model instructs us to view any communication as an interactive, multi-layered dialogue
— a concept that is particularly useful when unpacking user responses.
Consider the ‘message’ components: In the context of data analysis, the
messages are the users’ responses. As researchers, thinking critically
about how respondents may have internally processed the survey
questions, interview discussion, or usability tasks can yield richer
insights into user motivations.
Just
as the Transactional Model emphasizes the simultaneous interchange of
communication, UX researchers should consider the user’s context while
interpreting data. Decoding the meaning behind a user’s words or actions
involves understanding their background, experiences, and the situation
when they provide responses.
In
the Transactional Model, noise presents a potential barrier to
effective communication. Similarly, researchers must be aware of
snowballing themes or frequently highlighted issues during analysis.
Noise, in this context, could involve patterns of confusion,
misunderstandings, or consistently highlighted problems by users. You
need to account for this, e.g., the example I provided where
participants constantly referred to the incorrect math on static
wireframes.
Remember
that as a UX researcher, your interpretation of user responses will be
influenced by your understandings, biases, or preconceptions, just as
the responses were influenced by the user’s perceptions. By
acknowledging this, researchers can strive to neutralize any subjective
influence and ensure the analysis remains centered on the user’s
perspective. You can ask other researchers to double-check your work to
attempt to account for bias.
For example, if you come up with a
clear theme that users need better guidance in the application you are
testing, another researcher from outside of the project should come to a
similar conclusion if they view the data; if not, you should have a
conversation with them to determine what different perspectives you are
each bringing to the data analysis.
Understanding
your audience is crucial for delivering a persuasive UX research
presentation. Tailoring your communication to resonate with the specific
concerns and interests of your stakeholders can significantly enhance
the impact of your findings. Here are some more details:
Identify Stakeholder Groups Identify
the different groups of stakeholders who will be present in your
audience. This could include designers, developers, product managers,
and executives.
Prioritize Information Prioritize
the information based on what matters most to each stakeholder group.
For example, designers might be more interested in usability issues,
while executives may prioritize business impact.
Adapt Communication Style Adjust
your communication style to align with the communication preferences of
each group. Provide technical details for developers and emphasize user
experience benefits for executives.
Respecting
this Transactional Model’s feedback loop, remember to revisit user
insights after implementing design changes. This ensures you stay
user-focused, continuously validating or adjusting your interpretations
based on users’ evolving feedback. You can do this in a number of ways.
You can reconnect with users to show them updated designs and ask
questions to see if the issues you attempted to resolve were resolved.
Another
way to address this without having to reconnect with the users is to
create a spreadsheet or other document to track all the recommendations
that were made and reconcile the changes with what is then updated in
the design. You should be able to map the changes users requested to
updates or additions to the product roadmap for future updates. This
acknowledges that users were heard and that an attempt to address their
pain points will be documented.
Crucially, the Transactional Model
teaches us that communication is rarely simple or one-dimensional. It
encourages UX researchers to take a more nuanced, context-aware approach
to data analysis, resulting in deeper user understanding and more
accurate, user-validated results.
Tracking Your Application of the Transactional Model to Your Practice
You
might find it useful to track how you align your research planning and
execution to the framework of the Transactional Model. I’ve created a
spreadsheet to outline key factors of the model and used this for some
of my work. Demonstrated below is an example derived from a study
conducted for a banking client that included interviews and usability
testing. I completed this spreadsheet during the process of planning and
conducting interviews. Anonymized data from our study has been
furnished to show an example of how you might populate a similar
spreadsheet with your information.
You can customize the
spreadsheet structure to fit your specific research topic and interview
approach. By documenting your application of the transactional model,
you can gain valuable insights into the dynamic nature of communication
and improve your interview skills for future research.
Stage
Columns
Description
Example
Pre-Interview Planning
Topic/Question (Aligned with research goals)
Identify the research question and design questions that encourage open-ended responses and co-construction of meaning.
Testing
mobile banking app’s bill payment feature. How do you set up a new
payee? How would you make a payment? What are your overall impressions?
Participant Context
Note relevant demographic and personal information to tailor questions and avoid biased assumptions.
35-year-old
working professional, frequent user of the online banking and mobile
application but unfamiliar with using the app for bill pay.
Engagement Strategies
Outline planned strategies for active listening, open-ended questions, clarification prompts, and building rapport.
Open-ended
follow-up questions (“Can you elaborate on XYZ? Or Please explain more
to me what you mean by XYZ.”), active listening cues, positive
reinforcement (“Thank you for sharing those details”).
Shared Understanding
List potential challenges to understanding participant’s perspectives and strategies for ensuring shared meaning.
Initially,
the participant expressed some confusion about the financial jargon I
used. I clarified and provided simpler [non-jargon] explanations,
ensuring we were on the same page.
During Interview
Verbal Cues
Track participant’s language choices, including metaphors, pauses, and emotional expressions.
Participant
used a hesitant tone when describing negative experiences with the bill
payment feature. When questioned, they stated it was “likely their
fault” for not understanding the flow [it isn’t their fault].
Nonverbal Cues
Note participant’s nonverbal communication like body language, facial expressions, and eye contact.
Frowning and crossed arms when discussing specific pain points.
Researcher Reflexivity
Record moments where your own biases or assumptions might influence the interview and potential mitigation strategies.
Recognized
my own familiarity with the app might bias my interpretation of users’
understanding [e.g., going slower than I would have when entering
information]. Asked clarifying questions to avoid imposing my
assumptions.
Power Dynamics
Identify instances where power differentials emerge and actions taken to address them.
Participant
expressed trust in the research but admitted feeling hesitant to
criticize the app directly. I emphasized anonymity and encouraged open
feedback.
Unplanned Questions
List unplanned questions prompted by the participant’s responses that deepen understanding.
What
alternative [non-bank app] methods for paying bills that you use?
(Prompted by participant’s frustration with app bill pay).
Post-Interview Reflection
Meaning Co-construction
Analyze how both parties contributed to building shared meaning and insights.
Through
dialogue, we collaboratively identified specific design flaws in the
bill payment interface and explored additional pain points and areas
that worked well.
Openness and Flexibility
Evaluate how well you adapted to unexpected responses and maintained an open conversation.
Adapted
questioning based on participant’s emotional cues and adjusted language
to minimize technical jargon when that issue was raised.
Participant Feedback
Record any feedback received from participants regarding the interview process and areas for improvement.
Thank
you for the opportunity to be in the study. I’m glad my comments might
help improve the app for others. I’d be happy to participate in future
studies.
Ethical Considerations
Reflect on whether the interview aligned with principles of transparency, reciprocity, and acknowledging power dynamics.
Maintained
anonymity throughout the interview and ensured informed consent was
obtained. Data will be stored and secured as outlined in the research
protocol.
Key Themes/Quotes
Use this column to identify emerging themes or save quotes you might refer to later when creating the report.
Frustration with a confusing interface, lack of intuitive navigation, and desire for more customization options.
Analysis Notes
Use as many lines as needed to add notes for consideration during analysis.
Add notes here.
You
can use the suggested columns from this table as you see fit, adding or
subtracting as needed, particularly if you use a method other than
interviews. I usually add the following additional Columns for
logistical purposes:
Date of Interview,
Participant ID,
Interview Format (e.g., in person, remote, video, phone).
By
incorporating aspects of communication theory into UX research, UX
researchers and those who work with UX researchers can enhance the
effectiveness of their communication strategies, gather more accurate
insights, and create better user experiences. Communication theory
provides a framework for understanding the dynamics of communication,
and its application to UX research enables researchers to tailor their
approaches to specific audiences, employ effective interviewing
techniques, design surveys and questionnaires, establish seamless
communication channels during usability testing, and interpret data more
effectively.
As the field of UX research continues to evolve,
integrating communication theory into research practices will become
increasingly essential for bridging the gap between users and design
teams, ultimately leading to more successful products that resonate with
target audiences.
As a UX professional, it is important to continually explore and integrate new theories and methodologies to enhance your practice.
By leveraging communication theory principles, you can better
understand user needs, improve the user experience, and drive successful
outcomes for digital products and services.
Integrating
communication theory into UX research is an ongoing journey of learning
and implementing best practices. Embracing this approach empowers
researchers to effectively communicate their findings to stakeholders
and foster collaborative decision-making, ultimately driving positive
user experiences and successful design outcomes.
