UX Design

The Tools We Use: The Appcues Design Team Toolkit

.

How our tools shape our work

As designers, we select our design tools and develop our individual and team processes; from that point forward, those tools and processes shape us and our work—whether we’re conscious of it or not.

Certain features of tools shape what you do with them: Do you use a user-flow tool with easy-to-share links and collaboration features? Your process will benefit from the perspectives of your teammates.

this is a screenshot of design tool Stark, showing a designer checking contrast in design files. It shows a design file contrast check
For example, Stark makes it simple to check contrast right in design files. If a tool makes something easier, it’s more likely to happen.

Of course, the tools themselves are less important than the process of which they’re a part. With the right mix of research and iteration, for example, you could design something amazing on sticky notes scanned into Microsoft Paint.

But time and effort are scarce resources: Whatever your reflections on ideal processes may be, if a tool makes some things easy and others things hard, you’ll likely find yourself doing the easy thing when the rubber hits the road and you’re doing the work.

So while tools are not everything—and being good at using a design tool has very little to do with being a good designer—they do matter for the often invisible ways in which they shape our work and process.

Our team's (unfiltered) user experience design workflow and toolkit

Appcues, where I work as a product designer, is a design tool. People use it to create user onboarding, feature announcements, and other experiences on top of their websites or apps, code-free. So the Appcues design team cares about about design tools for the reasons that all designers do, but also as a source of inspiration and learning.

A couple of months back, UX Tools published the results of their 2018 Design Tools Survey, which features responses from over 2,500 designers.

This is a screenshot of UX Tools' 2018 designer toolkit showing the most popular and best ux designer tools for user flows, wireframing, ui design, design systems (sketch), prototyping (invision), handoff (zeplin), monitoring (hotjar), and file management  (google drive)
A summary of UX Tools’ survey results

This high-level view of a designer’s toolkit is a great way to discover new tools and identify trends. But as all designers know, quantitative data can only get you so far. We decided to offer a “zoomed-in” look at one specific team’s toolkit, in all it’s messy glory.

Read on for the design toolkit of a 3-person design team at a 65-person (and growing!) startup.

The Appcues product design toolkit

Brainstorming

The very beginning of a project is critical. It’s where the problem space is defined—all solutions that come thereafter will be influenced by the data used, assumptions made, and directions considered.

During this period, we lean on a wide array of tools:

  • We use Zapier to automatically pipe in data from all over the company. This includes everything from “nuggets” of insight from user research sessions, to sales deals lost, to specific product feedback from anyone on the team (which is submitted via an easy Slack command):
This is an example of an automatic form in Slack for submitting product feeback. the modal title is "submit prodduct feedback" and there are form fields. Information is automatically sent to Airtable.
When a teammate enters “/product-feedback” in Slack, they see this  form that goes right into Airtable so we don’t lose track of valuable insights.
  • ‍We use Airtable to aggregate all the data we collect. Airtable allows us to build digestible views of data, and to quickly search for data relevant to the project at hand. For example, if we’re starting a new project that aims to make it easier for customers to install Appcues, we can search and filter Airtable to identify everything we’ve heard from customers and our team about the installation experience.
This is an example of an Airtable base (called product feedback) with multiple sheet tabs. This is an example ofa product design team data collection tool.
One sheet within our product feedback Airtable base
  • At Appcues, we use Notion for just about everything—from our employee handbook, to business goals, to specific pages that serve as hubs for a project over time. These hub pages are particularly important during the brainstorming phase, because they require the team to synthesize and describe what’s known about a problem, as well as consider what it would mean for a project to succeed. We try to start this document before any interface “solution” is considered.

    Check out “How do you design a design doc?” by John Saito from Dropbox for some great ideas on how to do this well.
  • Paper and whiteboards. Once the problem is understood across the team and we’ve defined what it means for a project to succeed, we’ll start brainstorming—sometimes independently in notebooks and sometimes collaboratively on whiteboards.
this is a photo of a whiteboard brainstorming session from a product design team, with notes and drawings

During the brainstorming phase, specific tools are way less important than processes. 

This spans everything from large, risky, and ambiguous undertakings where we may run a full design sprint, to medium-sized projects—where we may get everyone on the project team in a room to “diverge” on ideas (using a technique like crazy-eights)—all the way to small enhancements, where a couple of people may sketch things out together on a whiteboard.

User flows

Once we understand the problem space and have diverged on approaches, we can start to consider the user experience at a high level—what steps will a user take? Sometimes it can be hard, but we try to be disciplined about not getting too attached to specific ideas for the interface. We’ll focus on the user’s goals and conceptual steps they may take to achieve them.

This year we discovered a tool called Whimsical, which has become our go-to for user flows and other kinds of diagrams.

Flows in Whimsical are easy to create, and look simple but great by default. There are barely any customization features (forget using your own typeface or color palette), and this actually ends up being a great thing, because it focuses you on the experience itself, not on making the world’s most beautiful user flow.

User flows are just tools for thinking, so as long as they are clear and understandable, the visuals are really secondary.

Whimsical also makes it easy to invite others to your flows and to export all or part of them, so collaboration is a snap. (Seriously, big fans).

this is an example of a design flowchart chart in whimsical. the title reads "install plan" installation flow. this is a gif of a designer working in whimsical. .
Whimsical’s simple flowchart canvas, with a great set of sharing and collaboration features.


Another flow tool is Flowkit, which is a Sketch (or Figma) library of flow chart pieces. It’s a great way to quickly throw together diagrams without leaving your primary tool, though isn’t quite as powerful as Whimsical.

This is a gif image of flowkit elements being inserted through sketch runner. This is a visual of a ux designer at work.
Inserting Flowkit elements through Sketch Runner

One user flow tool we are excited to try in 2019 is Overflow. It’s purpose-built for elegantly presenting the flow a user will take through an experience, which has the potential to help designers frame experiences and “tell the story” of their design.

Wireframes

In the past, wireframing was a step wherein you would figure out the details of an interface without worrying too much about the visuals, because nailing the visuals was too time-intensive. 

For many design teams (ours included) this is no longer the case. We have a robust design system, with everything from page layouts to icons to buttons, which means putting high-fidelity screens together is a snap.

This is an image of wireframing being done in in sketch. Components in sketch make it easy to create high-fidelity screens.
Components in Sketch make it easy to quickly compose high-fidelity screens

However, there are still times when a lower-fidelity “wireframe” screen makes sense. If you are trying to gather feedback on conceptual directions (i.e. if you’re still in the “what?” phase, not yet at the “how?” phase), a screen that look too polished can actually be a hindrance. If the visuals are too sleek, people may focus their feedback on visual details. People may also assume that the high-level approach is already agreed upon and not open for feedback.  

For these times, we use Whimsical’s wireframe tool, or Sketch or Figma and intentionally hold back on visual quality.

this is a gif image of a designer using whimsical design tool's wireframing tool to create simple screens with drag and drop elements
Whimsical’s wireframe tool makes it easy to create simple screens and has pre-built interface components (it “just works”—notice the ability to change the button state to “disabled” in the GIF above)

Interface design, design system, and file management

Sketch is where we spend most of our time. It’s the industry standard for a reason—it was designed for interface design, and it shows. There are three reasons Sketch is our main tool (at least for the moment):

  • Symbol libraries / design system: We could spend an entire article talking about how we organize our design system for use by designers and developers  Put simply, all of our symbols live in a Sketch library. We use Abstract to manage our Sketch files—including our design system—and to review each other’s work.
this is a screenshot of symbol library/design system tool abstract used to  manage sketch design files
Our style guide file in Abstract
  • Plugins! Sketch’s open ecosystem is great, because we can customize our workflows to be just right. Here are each of our plugins of choice:
this is a screenshot of sketch plugins. Sketch has an open ecosystem which allows for many plugins like unsplash stark grid master toggle craft confetti zeplin and more
  • Tight integration with InVision’s  Craft plugin suite. This makes it easy to wire together screens into clickable prototypes.

Near the end of 2018, we began to explore Figma as a replacement to Sketch. Judging from the UX Tools’ survey, this makes us part of a larger trend among designers. Its multiplayer mode, in-tool prototyping, and open ecosystem are some of the things that set it apart from Sketch and have us seriously considering a move to Figma.

Tools for prototyping

Choosing the right tool for prototyping is critical. Every time we prototype an experience, we ask ourselves what we want to learn from it. The answer to that question informs the tool we select.

Most of the time, a click-through prototype in InVision or in Figma’s prototyping tool gets the job done. We use these to gather feedback from our teammates, and from our users  during user testing.

Sometimes we need more than that though, and may turn to building all or part of the experience in code. For example, when we were working on Appcues’ Checklists in 2018, one of the designers on our team built a prototype in code, because the micro-interactions and feel were integral to the experience.

this is a gif image of a ux designer at work. it shows a designer using code to prototype a new user onboarding experience solution feature
Prototyping with code

This year , we’re hoping to spend more time prototyping in Framer X. Framer X is a different kind of design tool. They describe it in their documentation as “more like Unity than like Photoshop. An IDE for design, if you will.” 

Something like Framer X, where designers can compose interfaces using actual components that already exist in their app (and build highly interactive and state-aware prototypes) is probably the future of design tools. Soon, people will be designing with actual components, not Sketch symbols.

this is a tweet from jon gold abuot Framer x design tool. It say "totally totally mindblown by @framer x. this is the design tool you have been waiting for"
If someone who spends as much time thinking about design tools as Jon Gold does is "mindblown", then I’m definitely intrigued. 

Collaborating with developers

One step in the UX Tools survey was the “handoff.” At Appcues, we don’t really think in terms of handoffs—we believe that design is collaborative and iterative. That being said, we do provide developers with assets to work from, with the awareness that designs are living documents that will shift and adapt as we learn—whether through the process of building, user research, late-breaking ideas, or paired design and development sessions.

For this, we use InVision’s Inspect tool and Figma’s code inspection tool. One nice thing about Figma is that you can share an entire canvas with developers and annotate and organize specific elements, as opposed to just sharing screens (which is the way InVision Inspect & Zeplin work):

This is a gif image of figma's code inspection tool showing a designer inspecting code. There is a large titlel that reads "states of dynamic content" and a designer is clicking throgh ui elements
In Figma, you can share the entire canvas with developers, which makes it easy to call attention to things like dynamic content, error states, and flows. And the code inspector shows the name of styles and components from the style guide, so you can use terminology that developers will recognize to refer to different elements.

Our goal is to make this information sharing as seamless as possible. One way we do this is by aligning the words we use as designers with the words developers use. For example, we align our layer style names with the color names in the component library that the developers use. That way, we’re all speaking the same language.

Experience monitoring

We do a lot of active user research at Appcues. As discussed earlier, we use Airtable (with lots of awesome Zapier integrations) to organize this process. A lot of our process is inspired by the Zapier team’s generous and in-depth posts about how they do things.

We also monitor the experience of our product in more passive and quantitative ways. At the beginning of each project we define the instrumentation we will need to get the quantitative data we want. 

We then use Amplitude, a product analytics tool, to gather and understand that data.

We also use FullStory, which is a powerful tool that replays users’ sessions in Appcues and helps us understand how folks interact with Appcues “out in the wild.”

this is an image of fullstory's rage clicks monitoring. It shows rage clicks, which are clicks that users make out of frustration. this is an example of fullstory user session data reporting.
One example of data we get from FullStory: Rage Clicks help us identify places Appcues may be lagging or otherwise not working how people expect.  

We also use our own NPS survey tool. NPS surveys aren’t perfect, but they are a great way to track sentiment over time, and also to gather lightweight qualitative feedback. When an Appcues user fills out an NPS survey, their response pipes into Slack, so all of our teammates get a pulse on how users are feeling.

this is a sample of an automatically generated nps response report in slack. it shows nps customer feedback that has been automatically piped in to a slack channel
NPS Survey results piped into a customer feedback Slack channel

What do you think?

As our team grows, our product matures, and design tools evolve, our design toolkit will shift. But as of right now, these are the tools we use! What tools do you and your team use? 

We’d love to hear from you—feedback and questions are all fair game—design@appcues.com.

...

PS: If you like what you read and have ideas on how to make our toolkit even stronger, we’re hiring designers!

Emily is a product designer at Appcues. She uses design tools to design tools.

Try out Appcues