ThoughtWorks
  • 联系我们
  • Español
  • Português
  • Deutsch
  • English
概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

    智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 低摩擦的运营模式

    提升组织的变革响应力

    企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

    合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
概况

特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
  • Español
  • Português
  • Deutsch
  • English
ThoughtWorks菜单
  • 关闭   ✕
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们
  • 返回
  • 关闭   ✕
  • 概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

  • 低摩擦的运营模式

    提升组织的变革响应力

  • 智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

  • 企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 返回
  • 关闭   ✕
  • 概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
  • 返回
  • 关闭   ✕
  • 概况
  • 特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

  • 数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

  • 所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

  • 返回
  • 关闭   ✕
  • 概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

  • 返回
  • 关闭   ✕
  • 概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
体验设计技术

Six tactics to maximize UX research in agile

Kuppy Tanaporn Benjapolakul Kuppy Tanaporn Benjapolakul

Published: Nov 11, 2019

This article is written for those who are familiar with the agile work environment and user experience (UX) research. If you are new to design terms like ‘design discovery’ or ‘UX research’, I recommend reading this article as well.

Most designers I meet struggle to work in an agile team because they don’t know how to do great research. Research is an essential part of the discovery and a key factor in designing a great product or service. Without research, the designer has to guess what the best customer experience is, or get the stakeholder requirements, which most of the time leads to a poor product for the user or the business.

When designers work in an agile environment, they are expected to deliver the visual user interface (UI) so that the developer can build the functional aspects of the application. Designers therefore become a bottleneck if they spend too much time on research.

Ways to Maximize Design Research

Businesses make money from customers, and customers pay for things that make their lives better. Simple logic yet hard to accomplish. The designer’s role is, therefore, to make the product meet the customers’ needs, context and usability.  This makes research essential; it helps designers uncover customer insights, validate ease for use, and more so that they can help clients deliver their promise to customers through great user experience. Here are some tactics I’ve learnt over the years to help you maximise your research.
 

1. Start your research as early as possible.

Make the most out of the little time you have before the upcoming iteration.
  • If you’re starting a new project, your devs can not begin coding on their first day as they need time to set up their infrastructure first. Take this opportunity to talk to your Business Analyst (BA), Project Manager (PM) and Product Owner (PO) to understand what assumptions you need to find out and validate, and understand why it might impact the design.
     
  • ​Your BA and PO are key to helping you get more time to do research as they plan the upcoming story which should start with something generic and focus on the beginning of the user journey. For example, for creating a login, you won’t need a lot of time for research because the best practices are widely available on the internet.
     
  • Make sure the first research you pick helps you shape the overall high-level user journey AND the upcoming ‘research-priority’ story. I will cover what makes something a ‘research-priority’ later in this article.


2. Reframe your research deadline: Designers don’t do research in two-week sprints.

  • If your team is doing scrum based on two-week sprints, this means that a specific user story needs to be completed within this time period. However, designers don’t design the UI based on a single user story - they design for the entire experience. So you shouldn’t limit your plan for your discovery activity based on the length of your sprints.
     
  • ​After you have a high-level journey and a rough deadline of the iteration story, you can develop your research plan for the whole flow of that feature. Your first research will focus on validating the user journey, then you should focus on the specific interaction (UI) for the upcoming iteration/sprint deadline.
​For best practice, if your first story is a basic login flow you can skip the user research and do desk research instead as there’s no need to reinvent the wheel! By doing desk research you can also help save time and resources. This research deadline follows the iteration deadline because you’ve first uncovered the unknowns from desk research so that you can start the UI design. After you’ve completed the UI design, you should do a usability test with your colleague.

However, if the second story is “As a user, I want to see notification of XXX,” it’s difficult to know when the best moment is to send a user notification as well as how it is sent (e.g. email notification). It’s difficult to be sure about the user flow at all. So now you have to research to find out “What is the best way to design notifications for the user?” In this instance, this deadline should not follow the iteration deadline because the findings from your research might form a different solution which will affect the story prioritization.
  • If you want to have time to research this, it’s your responsibility to plan this more than one sprint ahead. If there are a lot more unknowns e.g.”‘Do the notifications bring value to the user?” then you might need more iterations to complete your research.
     
  • However, if you’re close to your deadline then you might have to deliver based on your ‘best guess’ (I know, this is a designer’s worst nightmare!) and learn from what you have delivered. And based on what you’ve learnt, propose a solution to the decision maker and give them a strong reason. Add to the backlog with your stakeholder agreement. Remember that using an agile approach helps us shape the work by learning fast and iterating!
     

3. Research goal over research method.

Never start with the research methodology. Always start with the research goal then decide on how to get the result. For example, let’s say that your research goal is to help the user find feature X.

 When you start with the ‘research method’, you might end up performing a usability test  to determine which prototype is easier to find feature X. To do this, you’ll need too develop a lot of different prototypes, which might be a complete waste of time.

However, if you decide to start with the ‘research goal’, you’ll instead focus on finding answers to a question like,  “Where is the best place for feature X to be discovered for a one-time user?” Now you can think of a much better way to validate this goal; for example, you could create a quick poll to find out which menu tab users think feature X should be in. 

Here’s also an interesting explanation from Matthew Godfrey, which illustrates how different purposes for the research impacts our research scope.


4. Prioritize well by researching what has the biggest impact and is least time-consuming.

You can’t do research to uncover 100% of the unknown in the flow but you can research the most critical part of the flow to uncover 80% of the unknown.

You have a lot of things in your design which you can validate so list out all of the unknowns into individual research items. Map out your design and list all of the flows and features. For example, let’s say you have a check-out flow for an eCommerce website; List out the flow then take a look at what features are involved (see the diagram below).

Example of a flow and the list of features within it. You should list as much as possible.

Prioritize the list of items starting with two criteria; on the left-hand side, consider the “impact” (i.e. if something goes wrong, how big is the impact?) and on the right-hand side, consider the “time” (i.e. how long will it take me to do the research?). In the left-hand side column, allocate a numerical score (or colour) to each item based on how significant the impact is if things do go wrong (see the diagram below). I recommend you start from the left-hand column because you need to first consider what needs to be researched and how in order to determine how long it will take you.



Here’s what the flow diagram will now look like:



Let’s say that you've come up with the impact for each feature this way. You might say that “cash on delivery and internet banking” have “lower impact” because this flow has already been used and performed well. However, you might consider a “list of items” has a “high impact” because if users select the quantity incorrectly because of a bad user experience it could have a significant consequence.

Now go ahead and add the second criteria “time”. You will find it easier to spot which area makes sense to pick up first. So if you have only one day to do research, pick up the top right corner! 


​
But be careful you don’t forget to look at the top left corner. These are items that are important but time-consuming. To tackle these, you have to plan ahead and use the tactics I mentioned earlier to maximize your time.


5. If you are not solo UX in the team, have a research leader.

When everyone has their own UI to develop designers will usually work individually. From my personal experience, working as a solo designer means that you have less support for your research, which leads to less confidence in your UI, and overall decreased productivity. Instead, there should be a research leader who should give some defined UI work to a teammate so that they can focus on discovering the unknowns. 

If your project is using the waterfall approach, having one less UI designer and one more design researcher is way more beneficial to the team. We know for a fact that having done the research ahead to uncover significant unknowns enables us to deliver the UI work so much faster.

The concept is to have someone own the responsibility for the design research and have enough capacity to cover important hypotheses. This will be something you have to set up with your team. . Determine how much capacity this person should have to use between research and UI delivery.

A research leader’s responsibility should include:
  • Continually harvesting the unknown list from the design team. They can use a workshop or go to each UX designer and ask what flow/interaction they feel unconfident about.
     
  • Prioritize the list against the criteria and plan the research (as previously covered above).
     
  • Research effectively. Just because you have more time doesn’t mean you can conduct a lengthy interview. Always practice Lean.
     
  • Make sure you balance your research work with UI work since you still have to feed the pipeline yourself.
The teammate still has to research but they don’t have to invest as much time and energy to manage the entire process. They have to get involved because at the end, all of the designers deliver the UI for the devs. So make sure your teammate is involved during their UI research so that they can go back and continue their UI development.
​

6. You might not need a real end-user to test your design.

Some validations don’t need a real end-user to be your respondent. So learn to determine when you  do need real users and when you don’t.

You need to validate with a real end-user when:
  • You need a specific end-user’s context to understand the research artifacts (e.g. customer service portal); and
     
  • The goal is to empathize with the user’s context and needs. (e.g. how do sick elderly people in homecare in Bangkok value XYZ features?)
​For example, let’s say that you are designing a B2B service website for big corporate HR. You would like to validate:
  • “What kind of pricing content leads to more conversion rates?” In this case, you have to validate with HR or someone with a similar context. You can not validate this with a first job seeker who works as a copywriter because they won't have the right experience and/or knowledge to know what they want to see in a pricing content.
     
  • “Do the copy for buttons X and Y make sense when together on this page?” In this case,you can ask your teammate next to you to help validate. You don’t need someone with an HR background unless the copy for the button  is very specific to the HR industry. But, if you know the end user’s goal, motivation or context is very clear from the previous research then you can test with anyone similar. Give the respondent the context background (role play) before research. Note:the result may not be as precise as validating with an end-user but you can do this in an emergency.

​Key takeaways
  1. Plan to do the research upfront. Be responsible  for knowing the iteration plan and allocating research time ahead.
  2. Design research should not necessarily be limited to on the iteration deadline. UI does.
  3. Start with the research goal, not the method.  The goal should dictate the method, not the other way around.
  4. Prioritize what to research by using two criteria including (1) the impact if something fails and (2) time spent to do the research. —  prioritize the items which are the most important and less time-consuming. However, make sure you plan for those that have high impact and are time-consuming.
  5. Have a research leader if you have more than one designer in a team.
  6. You might not need a real end-user to test your design. Check what context you would like to research.


 

Technology Hub

An in-depth exploration of enterprise technology and engineering excellence.

Explore
相关博客
体验设计

Faster, better, stronger: Building a high quality product

Finn Lorbeer
了解更多
体验设计

Understanding how Design Thinking, Lean and Agile Work Together

Jonny Schneider
了解更多
体验设计

Good design is about more than just customers

Ben Melbourne
了解更多
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

媒体与第三方机构垂询 | 政策声明 | Modern Slavery statement ThoughtWorks| 辅助功能 | © 2021 ThoughtWorks, Inc.