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:
- Defining Product Vision
- Research and Validation
- Understanding Design Systems
- Rapid Ideation
- Understanding Users and Relationships
- Preparing to Design
- Design and Build
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.
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.
Research and Validation
The Research Plan
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.
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.
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.
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
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.
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.
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:
- Journey Mapping
- Stakeholder Interviews
- Sketching and Crazy 8s
- Dot Voting
- User Testing
Design Sprints at Digital Telepathy
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
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 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 __________.
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.
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:
- Objects are nouns; things with descriptors. These are oftentimes things like users, documents, or files.
- Attributes are pieces of content associated with an object, which are user-updateable. In the case of a user as an object, the attributes could be name, email address, and phone number.
- Metadata is system-generated information. So if the object is a file, the metadata would include file size, date created, last modified, and file type.
- Relationships are used to identify how each object relates to one another.
Preparing to Design
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.
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:
- Form fields
- Text styles
- Unique Modules
Design and Build
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 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.
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!