As a Researcher at Lookback, I now have the advantage of being able to revisit sessions since they’re recorded (). Here’s how I take my notes using Lookback:

Focus mode

Sometimes it’s a party in the observer room. When everyone’s actively taking notes and chatting, I get easily distracted. In Focus Mode, I can only see my own session feed items, unless someone @mentions me in the chat. 

Since I don’t normally take many notes myself throughout the session, this also helps me focus (get it?) for when I review the session later. 

In playback I find it quite nice to turn everything else off, and just focus on my own notes and highlights. It’s like seeing the session for the first time for me!

Gif of Lookback’s Focus Mode feature

Timestamps and Editing Notes

Note taking during the live session

Note taking typically happens both during the live session and during playback. Either myself or my designated notetaker will use our predefined code during the live session in order to quickly mark that this point in the session is important to revisit.

Note taking in playback

Once I get to playback, I take the time to review the session and really flesh out my notes. I can look for the time stamped codes that were taken during the session, add in more detail, and edit the timestamp, if necessary. Here I’ll also add in new notes. I’ll also spend some time highlighting important moments in the session to share with my colleagues. More on that process below.

Transcriptions

As soon as I’m done with a session, I also generate a transcription. I capture verbatim quotes here. This is how I do the bulk of my note taking. In Lookback, all I have to do is generate transcriptions during the session like so: 

I don’t even have to wait in the session. I can go work on something else until the transcription is ready, and I’ll receive an email notification as soon as it’s available.

Exporting 

Once I’m all done capturing all of the quotes from my Participant, I export my notes to our database. The database is where the magic of analysis begins to happen. Since I take my notes in a fairly raw format, I always have a place to quickly identify exactly what was said. 

Highlights

After the team analyzes all of our sessions, we create highlights using the time stamped notes we took before. I use the quote that I captured in my original note to be used as a caption when we share our highlight clips and reels to the wider Lookback Team. To capture the right length, I’ll play the video and use the t shortcut to start and stop my highlight.

Once I’ve got my highlights ready to go, I either download the individual highlight or a highlight reel. From here they’ll be embedded in our report. In a pinch, I’ll just share the highlight link with the team. 

How do you and your team take notes using Lookback? Whatever your process is, I hope that Lookback has made note taking easier for you. 

Happy Researching!

Don’t make everything a note

Listen, not everything needs to be a note. Creating a note for every little thing just becomes noise to sift through when you’re trying to find the good stuff. Don’t do this to yourself. Here’s a couple of ways you can figure out how to prioritize:

Take a look at the discussion guide or test plan

Reading the discussion guide prior to the session adds context and flavor as to what you’re going to be listening in on. The discussion guide typically includes lines of questioning and topics of discussion. This can give you a loose idea of what to listen for. 

Make a plan

Having the whole team involved in research is glorious and triumphant, but it can also be…messy. Come up with shorthand or codes to standardize your notes. Here’s an example of codes that we came up with for anyone observing our sessions: 

Designate a Note Taker

This is a new note taking strategy for me. As a Counselor, I was THE note taker, unless I was co-facilitating a group session. Now that I’m a UX Researcher, this is one of my go-to strategies. With this strategy, I can focus on the Participant in front of me (well, on the screen).

Typically, another member of the Research Team is available to come take notes for me. However, I want the whole team to feel comfortable taking notes on what they hear and observe.  

Here’s how I invite the larger Lookback  team to join me, as well as encourage them to take notes:

Be Open 

Sometimes you hear a piece of information that isn’t relevant to the current session, but would be useful to someone else in the organization. Just because it’s out of scope of the session doesn’t mean it isn’t important. Write it down and get it into the right hands.

Solo Note Taking Tips 

What happens when you’re on your own in a session? Well, I have a few strategies to keep in mind. In Counseling, note taking during the session wasn’t the ideal choice. I was trained to have as little between me and the client as possible; no tables, clipboards, or notepads. While collaborative note taking with the client is an option, life didn’t always work out that way  

Here’s some tips that I’ve learned over the years:

Stay present

Staying present and focused on my clients helped me to pay attention in the session. As small as jotting down a couple of notes may seem, it’s still dividing your attention. I carry the same focus in UX, only taking notes of the most critical pieces of information.

It works for me, and I find that I remember much more after the session the more focused I was. Present-moment awareness is a skill, so if you find yourself distracted, acknowledge the moment, let it pass, and get back to business. Practice and repeat!

Take notes immediately after (brain dump)

Let’s be honest, my brain gets pretty fried after a long day of talking to people. The last thing that I want to do (or honestly able to do) is to remember all of the details from tons of sessions… 

If you can, give yourself a time buffer between listening sessions in order to take some quick notes. The session will be fresh in your mind, so you can still recall quite a bit. I often had days where I had back to back sessions as a Counselor. I made a conscious effort to jot down the really important stuff between sessions, which made things much easier when I went to polish them up later. 

Use a hashtag system for quick notes 

If it’s really important or I don’t have a time buffer, I’ll jot down a couple of keywords. This helps make my notes much more scannable, and helps to help jog my memory later.  Remember those codes from earlier? Yeah, I’ll use them if I’m on my own too. Here they are again: 

With Lookback, you can leverage time stamped notes in the moment to use quick hashtags to indicate something’s happening in the moment. You can fill in more detail when you come back to review the session. More about that in my final article in this series, “Note taking using Lookback.”

What tips and tricks have you learned for effective note taking? Let us know if any of these tips and tricks have been helpful to you and your team.

Happy researching!

One thing I know about is notes. I’ve written loads of them over the years, and I’d like to share with you how my background influences my note taking in UX. That’s why I’ve written a 3 part series on note taking in the hopes that you may learn something from my experience too.

The Foundation: DAP Notes

The most common note taking format that I used was the DAP format, which stands for Data, Assessment, and Plan. I would write up these types of notes daily for each of my sessions. Here’s how I typically structured my notes using this format:

Data 

• What did the client say (direct quotes, thoughts, their own observations)
• What were your observations (behavior, appearance, mood, affect)?
• What did the counselor do?
• What goals were addressed during the session?

Assessment 

• What’s the counselor’s understanding of the situation?
• What’s the current hypothesis?
• How has the client been responding to the treatment plan?

Plan 

• Does the treatment plan need to be revised based on the client’s response?
• What will the counselor do next?
• What needs to be done between now and the next session?
• Any referrals to be made or follow up to be made?

Although I’m no longer counseling, I still use this format as a guide for my research sessions. Though in my note taking for UX, I focus more on the Data portion. The Assessment and Plan portions are fairly similar in spirit, but these are typically addressed in concert with the rest of the team at a later time. 

Elements of a good note

Good notes always made it easier for me to track client progress, make assessments, and to share with necessary stakeholders. In UX, good notes have set me up for good analysis. Let’s talk a little bit more about what I think makes a good note:

They’re objective

Stick to the facts of what happened and what was said. This is particularly important if you’re taking notes during a session. You’ll have plenty of time to dig deeper during your analysis. 

Like I mentioned before, as a Counselor I favored the DAP note format. In the data section, I talked about what happened during the session.  This is the place where I covered our topics for the day, direct quotes, and my observations. The Data section was for the facts or ‘what’ of the session. 

I needed to document things without my assessment or analysis. This made it easier to go back into my notes, identify more patterns, and keep a good log of what was happening in my session. Keeping the data clean and clear gave me an objective set of facts to return too, leaving space for me to re-analyze when needed. 

They’re easy to understand

One thing that I picked up from my counseling days was that my notes weren’t just for me; Psychiatrists, supervisors, judges, state auditors, and sometimes the clients themselves were often perusers of my notes.

I kept my notes as jargon free as possible. I often framed it as, ‘if I weren’t there to explain what was happening, would the reader understand what happened?’ I still try to do this as much as possible. 

They’re useful

We take notes because we’re going to do something with them. As a Counselor, I used notes to keep track of my client’s progress, communicate with other stakeholders, and to plan treatment. 

As a Researcher, my notes and my recordings are the building blocks that I use for analysis. I take notes of what’s necessary and I keep them fairly verbatim to what the Participant said. 

This leaves me a fairly clean record to return to when I start my analysis. Sometimes I find that my assessment was off, and having those notes to go back to is incredibly useful to me. 

What do you consider to be a good note? Remember, a good note helps to set the foundation for good analysis. Next up is “The Art of Note Taking” where I share tips and tricks on how to take notes.

Happy Researching!

1. UX Maturity 

In thinking about how research exists and expands at companies, we kicked off the conversation UX Maturity. While the group are experts in design, how research tends to be adopted within organizations is similar to how Design as a function is adopted and supported throughout organizations as well.

DESIGN. The first step toward UX maturity.

With Design in place, Designers play a duo-role where design + research are part of their function. As this dual function — conduct usability studies, test designs, leverage tools to connect with customers and the general public, and establish a close partnership with Product.

When the demand on design and research hits a threshold, there’s a new focus on hiring for expertise.

UXR. With Design established and supported as a practice, Research is the next talent to bring on. Maturity within the field of UXR comes in 2 phases:

Phase 1 – Team of 1

Here, a single UX Researcher is focused on:

• Building their practice
• Conducting all research
• Building relationships
• Identifying champions
• Creating partnerships with Design and Product
• Empowering teams with knowledge to inspire action

Phase 2 – UX Research Maturity

Here, the team is working together on:

• Usability and now, strategic research efforts
• Democratizing research to empower others to conduct their own usability studies
• Building relationships across teams
• Extending their influence across the organization
• Deepening partnerships with Design and Product
• Empowering more teams with knowledge to inspire action

Ops. Now that Design and UX Research have met with maturity, a new function grows out of that to support the entire UXR function. Research (or Design) Ops vary from company to company, however with the inclusion of these roles, you may see them taking on:

• Managing the recruitment process or agencies
• Scheduling and coordinating research projects
• Auditing research toolkit regularly to optimize for team needs
• Being the go-to to onboard teams on new tools + what to use and when

2. Blending Quantitative with Qualitative

You need both in building or having a mature Research Organization. We need to know what is happening, however when we are able to help explain why it’s happening it will help build belief across your teams.

There are many different models for collaboration. Some include:

Dual-Track Agile

Research plays an important role within both the Discovery and Delivery phase of the product development lifecycle. We thought this write up from Silicon Valley Product Group sums it up nicely.

CEO as Champion

At Zapier, customer interaction/user exposure is embraced company-wide, starting from the top. Employees dedicate a percentage of their time each week to engage with customers on “ research ride alongs”, via live chats and other user-focused programs. The goal is for everyone on the team to learn about customer needs. UXR teams focus on the future-oriented research and Design + Product lead shorter timescale projects (e.g. usability studies, feature-focused interviews).

Multidisciplinary Research Practice
We were in awe of Slack’s Christina Janzer & Michael Massimi at the 2019 UXR Conference.

While there are many aspects of an organization to consider when entering into UXR from your graduate program, we hope that these three areas help you along your path.

Happy researching!

This change is effective for all new trials and subscriptions as of today. 

In this blog post I wanted to share our thinking and our reasoning behind the change. For more details on exactly how the new pricing works please see our FAQ.

Why are we making this change?

There are two main reasons. 

First, we want to support team wide collaboration and engagement with research. And our old pricing is standing in the way of that.

When we first introduced paid plans for Lookback in 2016, a majority of our users were UX researchers who used Lookback for recording and analysing UX research sessions. There were not a lot of non-researchers on the platform and most sharing of insight happened elsewhere. So it made sense to go with a pay-per-seat model. If you were a researcher, you paid for a collaborator seat that let you do all the things. If you weren’t, the limited free observer seat was fine. 

Today, a vast majority of our customers are collaborating in Lookback across the whole product team. We no longer see the clear distinction between “all in” researchers and peripheral stakeholders. Instead we see cross-team-learning from immersive customer conversations. The researchers are still heroes in the product, because running and moderating a session is a difficult art. But the stakeholders are more than passive viewers, they are engaged with the experience, they are generating insights, and they are collaborating between themselves as they are experiencing the participant experience about the thing they built.

And this is great! This is what we dreamed about when we started building Lookback. We have always believed that product team engagement with UX research is crucial. With the current Lookback platform, and Lookback LiveShare in particular, we see that our customers are getting that engagement from their stakeholders and we want to support it in every way we can. With our new pricing you can now invite your whole team without worrying about costs or licenses!

Secondly, we want to simplify the pricing, make it more predictable and easy to understand. We want everyone to have the best version of Lookback, regardless of plan. This is why we are removing almost all feature differences between the tiers. You will no longer get fewer valuable features on the cheaper tiers, just less usage. The value exchange is now based on volume of research and need for insights. We don’t limit the number of projects or types of research because we want you to get to your insights, no matter the method.

In our own research we also found that different teams value different methods of research and different types of customer conversations differently. Some prefer moderated sessions, others depend on unmoderated sessions. So we decided to just charge the same price regardless of what kind of research you do. Every session counts equally towards the cap, you decide how you want to use it.

We have designed this new model with the customer experience top of mind, and we believe that a vast majority of our customers will find the new pricing fair and better aligned with the value they get out of the platform. But if these kind of assessments were perfect, there wouldn’t be a need for a product like Lookback, so we’ll do our research on the experience and we’ll involve you all in the transition plans. 

That’s an overview of our thinking. For the ins and outs, including how we arrived at session caps for the different plans and how it affects current customers, please check out our FAQ for all the details.

Happy researching! 

Henrik and the Lookback team 

High-level capabilities

• Qualitative research
• Mixed-method research
• Usability testing
• 1:1 / in-depth interviews
• Desktop testing
• Mobile testing
  • native app, mobile website
• Prototype testing
• Ability to test own user base
• Preference testing (A/B)
• Generative research
• Evaluative research
• Iterative research (built to compliment agile product development)
• Accessibility

Testing methods

• Remote Moderated
• Remote Unmoderated
• Task-based testing (on desktop)
• In-person testing

Testing approaches

• Diary Studies
• Remote Card Sorting
• Tree testing (navigation testing)

Features

• Private projects
• Record interactions (taps and clicks)
• Broadcast sessions for observers: stream and post-session
• Screen reader support
• Transcriptions (beta)
• Timestamped notes
• Highlights  (Reels coming soon)
• Invite Observers
• @mention your team
• Virtual waiting room for participants
• Virtual observation for observers

FAQ

How are you different from traditional video conferencing tools? Simply put, we are built for research!

Do you have a recruit/pool feature? No, but we partner with User Interviews, TestingTime, Ethn.io, Respondent, HubUX. No matter which recruiting methods you use, just drop in the URL from your Lookback Round into your participant invite email. More info here.

Can we test our own user base? Yes, just send the Participate link created in each unique Round.

Can we record interactions (taps and clicks)? Yes, you can record taps using Lookback’s Participate app on mobile, and record mouse clicks via the Participate Chrome extension.

Can I send scheduled links to participants? No, Lookback doesn’t provide scheduling but it is an easy URL drop-in to other scheduling tools, like Google Calendar or Calendly.

Can we use our own branding? No white-labeling of Lookback Participate is available currently, but our Participate app is minimalistic, takes less than one minute to onboard and meets accessibility standards for web and native apps.

Can we hold group sessions? Your observers can join in live or recorded sessions live or the recorded session and collaborate. Group chats via goteam.video are available for free.

Can you manage incentives? No, we do not manage incentives.

Can we use tagging? You can create highlights and group them into the same project as a way of organizing the same theme. You can @tag your colleagues in live sessions or on video playback. Grouping by hashtag is on the roadmap for this year.

Do you do any participant screening? No, but you are free to use any screeners of your choice.

Do you offer screener templates? No, this is not something we offer out of the box. But our experienced Research team is always available to help you create the best processes and templates to accomplish your research needs.

Do you support live-intercept testing? This is not currently a feature of Lookback.

Do you offer dictation support? This is not something we intentionally support at the moment.

Resources

Demo videos of each research type. Our latest LiveShare demo is here.

GoTeam: chat with Participants before a session, or convene your team post session for debriefs – get a room, and you’re set!

Templated Invite Emails: whether iOS, Android, or desktop — just enter your details, and we’ve helped with the rest.

Participant Guides: additional tips on how to prepare for a session, ensure the best connection, and troubleshooting.

Pro Tips: best practices for the Participant, Moderator, and Observer.

Observer Guide: how to prepare and participate during live research.

Help Center that houses all of our self-serve content.

Questions about what we support? Write us at support@lookback.io

Happy Researching!

This post describes how we at Lookback

• developed a new color system for our web and mobile apps.
• incorporated accessibility considerations on colors from the WCAG into our workflow.

Our technical workflow for accessible colors

Last Spring, we set out to create a better color system for Lookback’s software products. The initiative came from both technical and accessibility standpoints.

In our web products, we’ve never really had a color system in the traditional sense of the word: canonical, centralized, and flexible. Colors have been added or best case reused from design mockups as we’ve progressed with the product. At least, colors lived as variables in the CSS preprocessor SCSS, but in a ton of locations where color values were modified on the fly with “adjuster functions” such as darken, lighten, and so on, to get slightly different hues and shades. Long story short: it became increasingly difficult to manage the sprawl of colors in the frontend code.

Accessibility wise, it didn’t require any fancy external consultants to make us realize we didn’t have proper contrast levels in our products. The Chrome DevTools has a quick and dirty way of inspecting contrast levels for elements in a web page:

We ended up having bad contrast almost everywhere. Fixing this would require not just spot fixes, but a systematic overhaul of the color system. This neatly tied into the tech goals described above. Thus, we set out to fix this!

More on contrast level checking further below.

Creating a system

We use Figma for all our design creation and collaboration. Best of all: Figma supports shared component and color libraries. This means you can define a set of named colors and share those with your collaborators across files. Thanks to that, updating the link colors across all files is merely becoming a single update in the library. This is not a new idea, but an immensely powerful one.

We started out by reading a ton about previous work in this area. There’s a lot of theory behind color systems from a scientific perspective, but we opted for a balance in our system’s “correctness”.

Starting off, the post “Building Your Color Palette” from Refactoring UI helped us get off the ground in our thinking. We followed the flow:

1. Find accent colors.
2. For each accent color, pick a base color.
3. For each base color, find the edges.
4. Fill in the gaps in between base and edges.

For each color in steps 2-4, we made sure to check the contrast levels against a dark or light foreground color.

Here’s a system we landed in:

You see the base colors in the center row, named xxxx-50. Edge colors are xxx-10 and xxxx-100.

The process of picking colors

Step 3 above felt a bit daunting to us. How would we know we had picked the “correct” shade? And how to pick out the base colors to base the whole scale on?

“Designing Systematic Colors” by UX Planet provided a lot of inspiration for a methodical approach, and other small gotchas in terms of accessibility, color scales, and the holistic system. A recommended read.

Our process was less scientific that the one outlined in UX Planet’s post. Since a color system works like a matrix, the scales need to match in both the horizontal and vertical axis. It’s easy to get paralyzed by the sheer amount of paths to take here, but we bluntly started out with one of our accent colors: blue.

Some takeaways in this stage:

• The 100 color can be almost black but with a tint of the accent color. Similarly, the 10 color can be almost white but with a tint of color.
• The colors in the upper range should have a lot more saturation than the ones in the lower parts.
• Balance the need for subtle change for each step (like when you need a slightly different color for a hover effect) and the uniformity of the whole scale. There shouldn’t be too many “uneven” jumps.
• We opted for a slight tint of blue in our greyscale, simply because it looked better – plain grey is usually quite boring.

After picking out the scale of 10 to 100 with input from UX Planet, we created a “testbed” for the scale. This was to simulate real world interface elements:

You notice we built for dark mode interfaces from the start here, something we recommend doing. All colors in the screenshot above are from the single blue scale. In light mode, the button uses blue-60 as base, and in dark mode it’s blue-40. In this testbed, we tweaked the shades and hues even further to make the elements have a harmonic feel. We repeated this process for all colors:

By switching between the testbeds and the color matrix, doing tweaks, we could identify rough edges in the scales, and finally a complete color system popped out.

Things to note in this process:

• It’s about coordinating shades across all colors in the system. Switching a button’s color from blue-60 to green-60 shouldn’t produce a dramatic shift in the button’s color shade. That’s why it helps eyeing the horizontal rows in the color system, while also comparing across testbeds.
• In each step, you must ensure that the contrast levels are fine. More on that below.
• In our color system above, you see we switch to white foreground text on the color swatches from 60 and above. We simply disallow dark foregrounds against backgrounds of 60-100 in our system, and vice versa with light foregrounds against backgrounds 10-50, due to contrast levels.

Making a testbed for each color helped a lot. It’s easy to get “lost in the system” when just staring at a grid of colors. Using them in real life is another thing. Actually seeing how they match each other in the interface is crucial. Also, it doesn’t stop here: you mustn’t be afraid of going back to the system and do tweaks if it turns out some colors don’t work out in the final products.

Due to the interactivity of user interfaces, more parameters come into play as well. States on a component, like hovering a button, could be taken into consideration when designing the color system. For us, we decided early on to not be that strict when it comes to those states. For buttons, for instance, we opted for modifying colors on the fly when a button is hovered, pressed, disabled, and so on. The difficulty came when we wanted subtle change in color for a state. Or color scales (10 steps) simply wasn’t fine enough to express finer states. This is something to think about when designing.

Contrast levels and accessibility

We’ve mentioned contrast a few times so far. One of the initial reasons for revamping our color system was due to lack of strong contrast in the user interface: for links, buttons, and copy.

Why is enough contrast important? Because people with low vision, color blindness, or other visual impairments won’t be able to read or use your interface if there’s low contrast. There are a lot of tools for testing your interface with various kinds of visual impairments, which is a really eye opening experience.

A lot of smart people have thought about all of this, and have collected a ton of material on accessibility as the Web Content Accessibility Guidelines (WCAG). The latest set of guidelines is even an ISO standard.

Low color contrast on the web is a widespread issue, but alas so easily fixable. The organization WebAIM publishes an annual report on the accessibility of the top million web pages, named “The WebAIM Million”. The February 2020 numbers are quite depressing, to be blunt. 86.3% of the web pages analyzed failed the WCAG color contrast recommendations for text. Low contrast was the most common failure type. This is clearly a low hanging fruit to fix.

WCAG defines a set of criterias for color contrast, named Criterion 1.4.3 and Criterion 1.4.6. These two describe the levels of contrast which makes the color pass the guidelines. These are:

• Level AA: a contrast ratio of 4.5:1 for regular text, and 3:1 for large text.
• Level AAA: a contrast ratio of 7:1 for regular text, and 4.5:1 for large text.

As you can see, Level AAA is stricter. The article “Contrast and Color Accessibility” by WebAIM does a good job of explaining these concepts in a hands-on way. Also, “Color Contrast, Beyond the Basics” by 24 Accessibility dives deeper in understanding the WCAG color guidelines for common interface elements such as checkboxes, navigation menus, and maps.

At Lookback, we have set the baseline at AA compliance, but aim for AAA.

Back to the process. For each color in our system, we checked that it had at least AA level of contrast. WebAIM has a great tool for it.

Example: with the color grey-60, we put the color code into a contrast checker tool as the background, and used a white foreground. With the color blue-50, we used a black foreground color in the contrast checker tool. This cut off point was arbitrarily put in the middle of the scale. This means that any colors below the -60 scale must be paired with a dark enough foreground or background. A color above -50 must have a light background or foreground.

It was a bit annoying to get a fail on the contrast for a specific color we just had settled on. When that happened, we simply had to pick the closest AA compliant color. It might feel weird if you’ve designed interfaces for a decade, and now you’re forced to not pick the one true color you had in mind. But in the end, this is for the greater good. In almost all cases, we just needed to do small bumps to make the color in question a bit darker.

Here are some neat color contrast tools:

• https://colourcontrast.cc
• https://coolors.co/contrast-checker
• https://developer.paciellogroup.com/resources/contrastanalyser/ (Mac and Windows app). Good for quickly checking colors on the screen.
• Stark is a set of accessibility tools for common design apps, like Figma.

Checking the contrast of a button’s text color against its background in the Lookback dashboard with the Color Contrast Analyzer app.

Note that we had to make sure to manually check interface elements for contrast failures as we implemented designs as code. Google Chrome’s DevTools has an inline color contrast checker when you inspect an element too:

Here you see that the inspected text fulfills the AA guidelines with the contrast level of 11.12:1.

Design and development process

With the color system finished (if it can ever be “finished”?), we could jump to the next step: getting the colors into the product code! Lookback maintains apps for the web, iOS, and Android. Sharing colors between these platforms would be the ideal solution: update a color once, and see the results everywhere without having to manually update the color codes in the source code.

Our colors lived in Figma, and luckily, they provide a web API! Upon inspection, we realized we could programmatically fetch the raw color codes out of the Figma document and put them into the source code as CSS or JSON. We created a GitHub repository to hold this script, CSS source code, and the colors in Javascript and JSON formats. You’ll find links to source code at the bottom of this post.

Automated tests for contrast violations

To ensure we’d catch any WCAG color violations before code is deployed for customers, we set up an automated test suite in the repository which would check all colors for violations. We used a tool called Pa11y for this. In our tests, Pa11y will be given a generated HTML page with all colors in our system, and fail the suite if some colors have bad contrast. This step provides an extra safe guard if we’d miss checking contrasts when picking colors in Figma.

Distributing the colors

Now when we had a solid color palette and a way to get those colors down into code, we needed a way to get them out in actual apps.

We started with CSS.

After running the Figma fetch script, we had all the colors as a big dictionary looking like this:

'blue-10': '#f6fbfd',
'blue-20': '#e5f7ff',
'blue-30': '#a4e3ff',
'blue-40': '#60ceff',
...

There are a bunch of ways to use these in CSS. Some technical readers might’ve used LESS or SCSS. In recent years, CSS Custom Properties have gained popularity and become adopted by more browsers. That means we could just distribute the color variables in a .css file and they could be used anywhere in the CSS.

We ended up with all the colors as custom properties in the CSS like this:

:root {
  --blue-10: #f6fbfd;
  --blue-20: #e5f7ff;
  --blue-30: #a4e3ff;
  --blue-40: #60ceff;

  /* ... */
}

Again, we wrote a script which takes all the colors from the large dictionary above and converts them to CSS Custom Properties and inserts them into the final distributable .css file. Distributing to CSS done!

Distributing to JSON was easy: we just stringified the dictionary of colors and put it into a .json file. With .json and .css files ready to go, we … drumroll … wrote another script for putting the distributable files online in an Amazon S3 bucket. Storing them there meant the iOS and Android codebases could do a HTTP request and fetch the .json file with all colors, and include in their respective source code.

Any web app could just embed the CSS and use the colors:

<link rel=”stylesheet” href=”https://cdn.foo.com/latest/lookbook.dist.css”

<style>
  body {
    color: var(--blue-80);
  }
</style>

No more magic, random color values in the CSS. Just safe, accessible color variables.

Conclusion

Summarized, all this becomes quite a nice pipeline for working with colors:

1. Designer does adjustments to the shared color library in Figma.
2. Developer runs the fetch script to update the colors in the repository.
3. After running the automated accessibility tests, the developer issues a new release which puts the CSS and JSON files in the Amazon S3 bucket.
4. Web clients get the CSS with the new colors. iOS and Android clients run their fetch scripts to get new colors from the JSON file.
5. New colors are rolled out in each platform’s release process.

Testing accessibility can be a detailed, manual process. But at least with colors, it can be made automated.

Improvements to this setup would be to have semantic color variable names. For instance, we’ve used the color swatch “blue-60” for all links in our web apps, and the same for the background colors on all buttons across platforms. Our color repository could provide these definitions centrally, like this:

// colors.json
{
  "primaryButtonBg": "blue-60",
  "linkColor": "blue-60",
}

This could help unify the platforms so they wouldn’t have their own definitions.

Feel free to inspect the colors repository on GitHub to see the structure.

Links

• Our script for fetching colors from a Figma document.
• The repository holding our CSS foundation, including colors.

The same is true for how users or participants experience our app when testing with or without a moderator.

One of the most common questions we get from researchers is

“what does the mobile participant experience look like?” 

Here we’ll walk through the mobile UX so you can get an idea of what your participants go through to get to your test:

This workflow is always being optimized and simplified, yet aligned with what is and isn’t allowed by the device makers – so it’s in flux but always improving.

Happy researching!

Lookback has been a proud sponsor of the UXRconf since the very first conference, and this year we are fortunate enough to be able to support the conference as title sponsor. 

There is a very simple reason for this unbroken commitment. The team behind the conference is amazing. They care deeply about the right things, they leverage their UXR skills to make sure they understand what users need, and they keep creating very valuable, human-centered, and accessible experiences for the global UX research community. 

Today’s announcement to go fully remote in response to the COVID-19 pandemic is just another great decision from the UXRConf team. We agree with every aspect of their analysis that led up to the decision, and we are really excited about their ambitious and creative plan for the remote conference. 

These are challenging times, but it is also an opportunity to rethink how we do things like conferences. We are very much looking forward to working with the UXRConf team in developing this new experience and we hope to see you all at Anywhere this summer! 

All the best and we hope everyone stays healthy and safe, 

Henrik and the Lookback team

We know it can take some effort to make a case and get budget approval for new tools. However, the feedback of when our customers simplify the tools in their research process is overwhelmingly positive. 

“I like that research is consolidated all in one area. And Lookback is that reliable tool, all in the cloud, all in one place,” said UX Researcher Juan Atachagua. 

Here are some advantages of using a dedicated research platform for research. While the first four mainly apply to the people conducting the research, there are ancillary benefits for teams that user testing supports, below.

Virtual waiting room

You don’t have to worry about someone joining a new session early while one is still in progress. With Lookback, there’s only one participant on one call at a time. The same URL still routes any future participants to be held in their own, specific “waiting room” to be invited to the session when the moderator is ready to begin.

No more asking “can someone please mute?”

Lookback creates a “virtual observation room” where your team can collaborate and ask questions without interrupting the session. No more background noise of a microphoned room or an unknowingly noisy colleague.

Other tools ping or alert when others join, while Lookback created the “behind the glass” lab-style experience, for anywhere participants and observing stakeholders are located in the world.

All-in-one

You get a full picture of the user’s screen, their screen gestures and facial and verbal reactions simultaneously. It takes some serious hacking and splicing to get all four visual and audio components otherwise.

via GIPHY

UXR principles

Our participant experience is meant for user testing, and was built with UXR guiding principles. Our Participate app has minimal “branding” that might confuse the user. We also adhere to native and web accessibility standards and accessibility readers can generally be used.

Research Operations + Leadership 

Consent and permissions

You can link to NDAs and get consent from the test plan. Lookback automatically asks the user for permission to record each session, (screen, camera and audio) and does so. Researchers don’t have to remember to record the session, or worry that the entire session isn’t recorded.

Knowledge management 

The resulting session and all of the supporting insights (highlights, notes, chat and transcription) are nested together and stored securely in one place, so that one platform can be the reference point for all teams who need access to the insights.

This means you don’t have to use multiple tools and hyperlinks to various places where your work is stored. There are no “hard copy” versioning issues, just send stakeholders one link to see the latest work.

Product + Design teams 

Iterative process 

Our Rounds workflow is in lockstep with the product development life cycle. Anyone can conduct research on a single topic, including multiple iterations, and all the video content and notes are saved in one place.

Mobile testing is unparalleled

We were designed for reliable and simple mobile app testing. Klarna, the popular e-commerce payment processor, shared that,

“taking a ‘mobile-first’ approach to product design, we found Lookback to be the best tool for conducting and sharing user research. It is truly amazing how seamlessly it blends remote and in-person, moderated and unmoderated setups and different platforms. And the recent addition of Rounds takes this experience to a whole new level.” 

Don’t have a researcher? That’s OK!

Lookback has hundreds of customers where their organizations don’t currently have active research departments. We have designers, product managers and support teams that utilize Lookback to get usability feedback from their customers. Lookback isn’t just for the trained researcher, it’s intuitive for anyone that is interested in user testing or feedback.