Only drug dealers and software companies call their customers ‘users’

Before we dive into the basics and methods of research, let’s take a step back and talk about the principles that drive the work.<h2>User-Centered</h2><h3>Not as cliché as it sounds.</h3>When designing complex software platforms, we have to consistently remember that we are not the user. Before we dive into what user-centered means, let’s talk about the word user. It’s such a loaded word. I personally hate it.<BLOCKQUOTE>Only drug dealers and software companies call their customers ‘users’ — Edward Tufte</BLOCKQUOTE>When we mention users in this field guide and at our work inside design teams, we are referring to the complex human at the end of our software.None of the product designers, managers, engineers or even our support teams are our users. (Unless you are actually designing in-house software for those people.) In the vast majority of situations, none your team members are experts in the users’ industry.Designing for these people starts with respect. It means creating an open, inclusive, and empathetic platform to collaborate with users. It means we need to be conscious of our biases. Design-centric businesses&nbsp;succeeded because we focus on the experience of our users, listen to their feedback, and collaboratively develop mental models.When we say we are user-centered it also means designing for the right users.At Flexport, we identified 56&nbsp;different personas, and the list keeps growing as the&nbsp;product space grows. At Inkling, we had over 15 clear personas. Enterprise software is apt to have more personas and more complexity. However, no matter if you have three, twelve, or forty-five user types, remember when we say user-centered we mean which user.&nbsp;Designing software for these disparate people requires a clear, unwavering understanding of the core personas you are focusing on.<h2>Iterative</h2><h3>The process is in process.</h3>Every design and research&nbsp;process will change. Each project requires different sets of tools, techniques, and resources. As we continue to spend more time with&nbsp;various business stakeholders, users, and external partners, our process will need to evolve.Remember that this field guide and any process you put in place will require adjustment. Re-evaluate often. Try new tools out. Explore new methods and techniques. Just keep organized and documenting along the way.<h2>Evidence-Based</h2><h3>Pics or it didn’t happen.</h3>Use concrete evidence to guide our decisions. This includes specific examples, quotes from users,&nbsp;session recordings, and other physical evidence.By using digital prototypes, paper prototypes, and tangible research artifacts, we can improve our personas and backup specific design decisions. This evidence will become more critical as any&nbsp;design language and system expands.<h2>Lean</h2><h3>Goldilocks: not too much, not too little.</h3>Often user research can be seen as the enemy of agile development cycles. It’s not.Design research can be prioritized to help the most critical users, focus on areas we know the least, and work alongside a rapid development cycle. We can use simple techniques to get the core mental model correct and test more once the initial versions have been built.Design research is the best friend, not the enemy of, moving fast.<h2>Holistic</h2><h3>Take a step back and a deep breath every now and again</h3>Design research is most successful when we can make sure we aren’t missing the forest for the trees. Our day-to-day might be filled with user interviews, usability tests, and new feature discovery. Research helps dedicate time to consider the impact of the product, not just the success of the feature we’re building in this sprint.Research is a core component of our&nbsp;long-term strategy — helping synthesize our knowledge from exploratory conversations, quantitative data, and feedback from our decisions — across all product teams.

product

Product & Design

Before we dive into the basics and methods of research, let’s take a step back and talk about the principles that drive the work.

When designing complex software platforms, we have to consistently remember that we are not the user. Before we dive into what user-centered means, let’s talk about the word user. It’s such a loaded word. I personally hate it.

Only drug dealers and software companies call their customers ‘users’ — Edward Tufte

When we mention users in this field guide and at our work inside design teams, we are referring to the complex human at the end of our software.

None of the product designers, managers, engineers or even our support teams are our users . (Unless you are actually designing in-house software for those people.) In the vast majority of situations, none your team members are experts in the users’ industry.

Designing for these people starts with respect. It means creating an open, inclusive, and empathetic platform to collaborate with users. It means we need to be conscious of our biases. Design-centric businesses succeeded because we focus on the experience of our users, listen to their feedback, and collaboratively develop mental models.

When we say we are user-centered it also means designing for the right users.

At Flexport, we identified 56 different personas, and the list keeps growing as the product space grows. At Inkling, we had over 15 clear personas. Enterprise software is apt to have more personas and more complexity. However, no matter if you have three, twelve, or forty-five user types, remember when we say user-centered we mean which user.  Designing software for these disparate people requires a clear, unwavering understanding of the core personas you are focusing on.

Every design and research process will change. Each project requires different sets of tools, techniques, and resources. As we continue to spend more time with various business stakeholders, users, and external partners, our process will need to evolve.

Remember that this field guide and any process you put in place will require adjustment. Re-evaluate often. Try new tools out. Explore new methods and techniques. Just keep organized and documenting along the way.

Use concrete evidence to guide our decisions. This includes specific examples, quotes from users, session recordings, and other physical evidence.

By using digital prototypes, paper prototypes, and tangible research artifacts, we can improve our personas and backup specific design decisions. This evidence will become more critical as any design language and system expands.

Goldilocks: not too much, not too little.

Often user research can be seen as the enemy of agile development cycles. It’s not.

Design research can be prioritized to help the most critical users, focus on areas we know the least, and work alongside a rapid development cycle. We can use simple techniques to get the core mental model correct and test more once the initial versions have been built.

Design research is the best friend, not the enemy of, moving fast.

Take a step back and a deep breath every now and again

Design research is most successful when we can make sure we aren’t missing the forest for the trees. Our day-to-day might be filled with user interviews, usability tests, and new feature discovery. Research helps dedicate time to consider the impact of the product, not just the success of the feature we’re building in this sprint.

Research is a core component of our long-term strategy — helping synthesize our knowledge from exploratory conversations, quantitative data, and feedback from our decisions — across all product teams.

Focus on people

EDWARD TUFTE

Liviu Lica's ideas are part of this journey:

Related collections

Similar ideas