Working at a UX studio is an exciting, rewarding, and challenging job. Not only do we have to become subject matter experts in the field of UX, we have to become problem-solvers in the industries for which we are building products. Building those products involves a lot of people, quickly becoming an immensely collaborative process that includes designers, developers, product owners, strategists, stakeholders, and most importantly, users. At Digital Telepathy, we work with enterprises in the technology, cloud-management, cyber-security, and communications fields. This stuff gets complex real fast.

We’ve refined our process with a methodical set of tools that apply to any industry, making the job less daunting, more scientific, more collaborative, and lots of fun. The techniques that follow are pretty close to a sequence of linear exercises, but any one of these tools can be used at different points in the design process. Consider this a toolkit to pull from; a set of methods to give you the confidence and know-how to go out and build something amazing.

This is a list post. We’ll give you a brief summary of what each tool is and why it’s useful, an example of each, and we’ll include relevant links and resources for deeper learning.

This is a long post. But an awesome reference guide! You don’t have to read this in order, feel free to bounce around and discover what might help you at the moment. So before you start scrolling, here’s a taste of what we’ll cover:

Okay, here we go!

Defining Product Vision

The Future Press Release

An effective method to realizing a product vision is working backwards by writing a press release. Imagine as if the product is released into the wild. Now write a press release that introduces the product to the public, why it exists, what problem it solves, and why it matters to prospective users. This can be an individual exercise or can involve team members and stakeholders. Future press releases are fantastic for collaboration and alignment, serving as a beacon for the life of the project. You can learn all about how to write a product vision press release on our blog.

 

The Manifesto

Another variation of defining vision lives in the form of a manifesto. For a product that does not exist yet, we start with the vision of why our stakeholders think it should exist in the first place. We dig into the value proposition, what problem this will solve, the background, and what value this brings to the customer. Forcing the stakeholder to thoughtfully write this out helps us understand their thought process.

 

Resources

Your Complete Guide to Setting Your Product Vision & Value Proposition
Writing Product Vision
The Business Model Canvas
Design the Beginning
Objective-Based Design

 

Research and Validation

The Research Plan

Image credit: Smashing Magazine.

Stakeholder input is incredibly valuable. And necessary, because there’s a good chance that we wouldn’t be working on the project if it weren’t for them. But the information can’t only come from their perspective. After all, we’re designing for users. So crafting a thoughtful approach to getting user input is critical to identify where the friction exists and to validate that the proposed product is the right solution for the need. Check out a thorough walk-through of how to write a research plan here.

 

Asking the Right Questions

There’s a psychology to asking questions that aren’t leading or biased. A framework like the above is a good starting point for framing questions so that we get valuable and honest feedback from our users.

 

Synthesizing the Data


After the interviews are done, we synthesize the data to identify insights in the form of themes, relationships, patterns, and opportunities. This topic could be a blog post of its own. And it’s actually a workshop we run at DT. For more information on how we run our training programs, go here.

 

User Testing

Testing can happen at many points throughout the design process. If the product exists, then we test to find friction. If the product is still in ideation, then we run a design sprint to concept and build a prototype we can put in front of users. If the product is built, then we never stop testing as we’ll always find ways to make it better. We get the most value out of testing in-person, but we’ve often relied on paid remote testing to save time and get a larger quantity of feedback. Our go-to is UserTesting.com but there are plenty of similar tools out there. So get free trials and experiment to find the tool that suits you best.

 

Heuristic Evaluations

A heuristic evaluation is key to identifying usability issues. It’s important to differentiate between usability and user testing. When running a heuristic evaluation, experts analyze a product to identify areas where the pure functionality and usability of the product may have issues. The results are fairly binary.

When running a user test, we look for more behavioral patterns of the users. This helps identify their intent and their thought process. A product may pass all heuristic principles but may not meet the needs of the user.

 

Resources

The UX Research Plan That Stakeholders Love
How to Turn Customer Interviews into Enterprise Sales
How to Conduct Yourself in a UX Research Session
A 5-Step Process For Conducting User Research
Using Trello for User Research Synthesis
10 Usability Heuristics for User Interface Design

 

Understanding Design Systems

Platform Audit

We don’t always build products from scratch. Sometimes clients will come to us with a bloated and tangled web of existing products. In those cases, we’ll perform an audit of every section of the platform to identify feature overlap.

 

Ecosystem Mapping

We’ll also create what we call an ecosystem map to illustrate the connections it makes across users and platforms. Think of this as a mind map of sorts. This is most beneficial when traditional site mapping of IA would take too long, is too tactical, and doesn’t solve the higher level problem of connecting the user to the product. The above example was used to connect the relationships between a web portal, a mobile app, and the three personas using the tools.

 

Competitive and Comparative Audits

A competitive audit can be useful in seeing what’s already out there in the market. We’ll use audits to document all features a product contains, then screenshot the features and drop them into an InVision Board to make the audit all the more visual. This is quite beneficial when it comes time to execute. Competitive audits take time, as many competitors don’t show complete demos or allow account creation on their marketing sites. So you’ll need to team up and build in the time to schedule demos, document, and synthesize the information.

 

Resources

The Step-by-Step Guide to an Effective UX Audit
How to Check Out the Competition
Conducting Competitive Research

 

Rapid Ideation

Design Sprints

Whether it’s a new feature to an existing product, or a new product altogether, we’ll execute a one-week Design Sprint to prototype and vet whether the product we’re seeking to build is worth spending the months it will take to build it. We’ll test at the end of the sprint to see if it solves the problem for the user. If we’re looking for product market fit, the prototype can be shared with prospective users over a longer period of time to get feedback before the actual build begins.

Pro Tip: Any of the exercises contained within a Design Sprint can be used throughout the product design process. These include:

 

Resources

Design Sprints at Digital Telepathy
The Sprintcation
The Sprint Book by Google Ventures
How to Pick the Most Important Challenges for Your Design Sprint
How to Assemble Your Design Sprint Team
The Product Design Sprint
Frequently Asked Questions About Design Sprints

 

Understanding Users and Relationships

Proto-Personas

To be honest, personas can be waste of time. For situational context, job stories are proven to be extremely effective (we’ll talk about this next). But when we need to identify multiple users that will be interacting with the same product in different ways, an afternoon proto-persona exercise is useful. We don’t always need to go as deep as identifying their shopping behaviors or making up fictional names for their 2.5 kids, but we do need to identify their objectives and behaviors.

 

Job Stories

Job stories were popularized and blogged about by the good folks at Intercom. A job story is a description of a feature from a jobs-to-be-done perspective. It’s an effective technique for defining a problem without being prescriptive of a solution. This inspires creativity, encourages collaboration across the team, and brings alignment to the organization. The framework of a job story is built off of a user story. The structure of a user story is:

As _____, I want to _______, so that I can __________.

By replacing the “As a”, with “When I”, we identify the problem from a situational perspective rather than persona-based. Focusing on the “what” and not the “who”, it helps us solve for specific problems that users encounter by identifying their motivations, actions, and outcomes. The framework is:

When I _____, I want to _______, so that I can __________.

For example:

When I am viewing my dashboard, I want to check my account balance, so that I quickly know how much money I have left without leaving the dashboard.

 

Object-Oriented UX

Using the Object-Oriented UX (OOUX) framework, we identify objects, their attributes, metadata, and relationships. This exercise helps us understand what “things” need to be designed for and how they relate to each other. It takes the guesswork out of what goes on a page. Simply put:

 

Resources

How to Make Proto-Personas and Get Everyone on the Same Page
The Proto-Personas Toolkit
Designing features using Job Stories
OOUX: A Foundation for Interaction Design

 

Preparing to Design

Whiteboard Flows

Using job stories as our anchor, and OOUX to identify content and relationships, we go to the whiteboard to begin solving problems. There’s a science to this method using color, shapes, and job stories. Check out our post about whiteboard wireframing, it’s pretty cool.

 

Component Audit

If the whiteboards are high enough in fidelity, we can begin to understand what types of components are going to make up the design system. It’s about identifying patterns to inform style guides and pattern libraries. We’ll assign priorities to the components if development is happening in tandem, we’ll name the components, refer to screenshots of whiteboards or existing components, assign a status to completion of these components, and identify where in the product these components will live. A few things to consider are:

 

Resources

Design Better Concepts With DT’s Whiteboard Conception Language
Why Developers and Designers Should Work Together
The Anatomy of a Trello Card

 

Design and Build

Design Exploration

Now that we know what types of components will make up the design system, we can explore visual styles and structure. It’s important not to get too detailed, creating just enough to know what aesthetic you are working towards. This is a time for rapid ideation; quantity leads to quality.

Some may argue that wireframes should come before this, but if you’ve done a thoughtful job of whiteboarding and auditing components, you can often explore and create an atomic design system before piecing it all together in layout, effectively bypassing the wireframing process.

 

Prototyping

Prototyping is an increasingly critical piece of the design puzzle. It helps communicate vision to stakeholders and illustrates motion to developers. With the crazy amount of tools available, we don’t limit ourselves to any one in particular. Rather, we evaluate the experience we are trying to communicate, and then pick the best tool for it. Some of our go-tos include Sketch + InVision, Axure, Principal, Flinto, and Framer. For a comprehensive guide to help you determine the best tool for the task at hand, check out this handy guide.

 

Living Style Guides & Component Design

We often use a style guide based off of a 12 column horizontal grid, built both in Bootstrap and Sketch, allowing for a seamless design system to be applied at enterprise scale. We’ll determine type sizes based on relative em size, using a typescale calculator. And the popular 8px grid can still be applied to the aforementioned approach. As for tools, we mostly use Sketch, play around with Adobe XD and Figma, and enjoy watching the fierce competition to be the end-all and be-all design and prototyping tool. May the best tool win.

 

Putting it All Together

The process of layout is often something that designers jump right into, whether it’s with a design language or with wireframes. But layouts for complex products are a lot less daunting when taking a methodical approach like ours. So use the information leading up to this, take direction from the whiteboards, use the component library, and these layouts will come together like magic.

 

Resources

Atomic Design Methodology
Designer’s Toolkit: Prototyping Tools
Type Scale Calculator
The 8-Point Grid
Bootstrap for Designers
What Designers Need to Know About Bootstrap

 

A product is never done, it only evolves.

Through the cyclical process of analyzing data, getting user feedback, and testing, you’ll know where to go next. New problems will arise, and new features will be born. But any of the techniques above can help you approach those challenges with more confidence and clarity. I imagine that you’ve used many of the techniques above, but if you haven’t tried them all at least once, I highly recommend it. I now approach every product as an opportunity to pull from this bag of tricks. And I’ve found that the more I use, the better results I get. Now go, make something amazing!

Comments
  • Claude

    Amazing resource that I’ll keep in my bookmarks for many many years. Great format and easy to go through, again, great post Brad!

    • Thanks, Claude! I love watching your journey as you continue to make amazing things.

  • Tyson Kingsbury

    absolutely blown away by the information all gathered here. Can’t thank you enough. I’ll be keeping this in my bookmarks for a long time as well 🙂

    • Thanks for the great feedback, Tyson! Happy to help 🙂

  • Stephen Payne

    Well done man! Great resource, thanks for publishing

  • Karabo Ngoatle

    This is a treasure chest of good valuable information, thank you for sharing and educating the masses out here.

  • Such a great post! Kudos for making something so informative and to the point yet so succinct!

    I work for a design agency in Manchester (UK) We utilise a lot of the processes outlined above so that’s great to see.

    This year we’re experiminiting moving form the whiteboard sketches to really quick low fi wires and design rather than the historic high fi wires per device. This should open up more time for us to prototype! (fingers crossed). I’ll be sure to check out the prototyping tool comparison resources!

    Thanks again and great post!

    • Thanks, Kyle! I love your approach and have seen it work first-hand. With the right design language you can render hi-fi wireframes obsolete. I’d love to see what you guys come up with!

  • it is so nice of you!