ThoughtWorks
  • Contato
  • Español
  • Deutsch
  • English
  • 中文
Visão geral
  • Cultura de engenharia, mentalidade de entrega

    Adote uma abordagem moderna ao desenvolvimento de software e entregue valor mais rapidamente

    Inteligência para tomada de decisões

    Explore seus dados para descobrir novas fontes de valor

  • Modelo de operação sem atritos

    Evolua a capacidade da sua organização de responder a mudanças

    Estratégia de plataforma

    Crie plataformas de tecnologia que se adaptam à sua estratégia de negócios

  • Design de experiência e inovação de produtos

    Planeje, execute e evolua rapidamente produtos e experiências excepcionais

    Parcerias

    Extraindo valor da nossa rede de parceiras para potencializar os resultados que entregamos a nossas clientes

Visão geral
  • Setor automotivo
  • Cleantech, energia e utilidade pública
  • Serviços financeiros e seguros
  • Saúde
  • Mídia
  • Organizações sem fins lucrativos
  • Setor público
  • Varejo e e-commerce
  • Viagem e transporte
Visão geral

Destaques

  • Tecnologia

    Uma análise abrangente de tecnologias e práticas de engenharia nas empresas

  • Negócios

    Mantenha-se em dia com as mais recentes tendências da indústria

  • Cultura

    Um espaço para conteúdo sobre desenvolvimento profissional e nossa visão sobre justiça social e inclusão

Ferramentas e Publicações Digitais

  • Technology Radar

    Um guia com opiniões firmes sobre as fronteiras da tecnologia

  • Perspectives

    Uma publicação para líderes digitais

  • Modelo de Fluência Digital

    Um modelo para priorizar as competências digitais necessárias para se navegar a incerteza

  • Decoder

    Um guia de A a Z sobre tecnologia para lideranças executivas

Todos os Insights

  • Artigos

    Visões de especialistas para ajudar seu negócio a crescer

  • Blogs

    Pontos de vista pessoais de ThoughtWorkers de todo o mundo

  • Livros

    Explore nossa vasta biblioteca

  • Podcasts

    Discussões instigantes sobre as últimas novidades em negócios e tecnologia

Visão geral
  • Processo de aplicação

    O que esperar de uma entrevista conosco

  • Pessoas em início ou mudança de carreira

    Comece sua jornada na tecnologia aqui

  • Vagas abertas

    Encontre oportunidades na sua região

  • Conecte-se

    Assine nossa newsletter mensal

Visão geral
  • Conferências e eventos
  • Diversidade e Inclusão
  • Notícias
  • Código aberto
  • Nossas lideranças
  • Transformação social
  • Español
  • Deutsch
  • English
  • 中文
ThoughtWorksMenu
  • Fechar   ✕
  • O que fazemos
  • Com quem trabalhamos
  • Insights
  • Carreiras
  • Sobre
  • Contato
  • Voltar
  • Fechar   ✕
  • Visão geral
  • Cultura de engenharia, mentalidade de entrega

    Adote uma abordagem moderna ao desenvolvimento de software e entregue valor mais rapidamente

  • Design de experiência e inovação de produtos

    Planeje, execute e evolua rapidamente produtos e experiências excepcionais

  • Modelo de operação sem atritos

    Evolua a capacidade da sua organização de responder a mudanças

  • Inteligência para tomada de decisões

    Explore seus dados para descobrir novas fontes de valor

  • Parcerias

    Extraindo valor da nossa rede de parceiras para potencializar os resultados que entregamos a nossas clientes

  • Estratégia de plataforma

    Crie plataformas de tecnologia que se adaptam à sua estratégia de negócios

  • Voltar
  • Fechar   ✕
  • Visão geral
  • Setor automotivo
  • Cleantech, energia e utilidade pública
  • Serviços financeiros e seguros
  • Saúde
  • Mídia
  • Organizações sem fins lucrativos
  • Setor público
  • Varejo e e-commerce
  • Viagem e transporte
  • Voltar
  • Fechar   ✕
  • Visão geral
  • Destaques

  • Tecnologia

    Uma análise abrangente de tecnologias e práticas de engenharia nas empresas

  • Negócios

    Mantenha-se em dia com as mais recentes tendências da indústria

  • Cultura

    Um espaço para conteúdo sobre desenvolvimento profissional e nossa visão sobre justiça social e inclusão

  • Ferramentas e Publicações Digitais

  • Technology Radar

    Um guia com opiniões firmes sobre as fronteiras da tecnologia

  • Perspectives

    Uma publicação para líderes digitais

  • Modelo de Fluência Digital

    Um modelo para priorizar as competências digitais necessárias para se navegar a incerteza

  • Decoder

    Um guia de A a Z sobre tecnologia para lideranças executivas

  • Todos os Insights

  • Artigos

    Visões de especialistas para ajudar seu negócio a crescer

  • Blogs

    Pontos de vista pessoais de ThoughtWorkers de todo o mundo

  • Livros

    Explore nossa vasta biblioteca

  • Podcasts

    Discussões instigantes sobre as últimas novidades em negócios e tecnologia

  • Voltar
  • Fechar   ✕
  • Visão geral
  • Processo de aplicação

    O que esperar de uma entrevista conosco

  • Pessoas em início ou mudança de carreira

    Comece sua jornada na tecnologia aqui

  • Vagas abertas

    Encontre oportunidades na sua região

  • Conecte-se

    Assine nossa newsletter mensal

  • Voltar
  • Fechar   ✕
  • Visão geral
  • Conferências e eventos
  • Diversidade e Inclusão
  • Notícias
  • Código aberto
  • Nossas lideranças
  • Transformação social
Blogs
Selecione um tema
Ver todos os tópicosFechar
Tecnologia 
Gestão de Projetos Agil Nuvem Entrega Contínua Ciência e Engenharia de Dados Defendendo a Internet Livre Arquitetura Evolutiva Design de Experiência IoT Linguagens, Ferramentas & Frameworks Modernização de sistemas legados Machine Learning & Artificial Intelligence Microsserviços Plataformas Segurança Testes de Software Estratégia de Tecnologia 
O negócio 
Serviços Financeiros Saúde Global Inovação Varejo Transformação 
Carreiras 
Dicas de Carreira Diversidade e Inclusão Transformação social 
Blogs

Topics

Escolha um tópico
  • Tecnologia
    Tecnologia
  • Tecnologia Visão Geral
  • Gestão de Projetos Agil
  • Nuvem
  • Entrega Contínua
  • Ciência e Engenharia de Dados
  • Defendendo a Internet Livre
  • Arquitetura Evolutiva
  • Design de Experiência
  • IoT
  • Linguagens, Ferramentas & Frameworks
  • Modernização de sistemas legados
  • Machine Learning & Artificial Intelligence
  • Microsserviços
  • Plataformas
  • Segurança
  • Testes de Software
  • Estratégia de Tecnologia
  • O negócio
    O negócio
  • O negócio Visão Geral
  • Serviços Financeiros
  • Saúde Global
  • Inovação
  • Varejo
  • Transformação
  • Carreiras
    Carreiras
  • Carreiras Visão Geral
  • Dicas de Carreira
  • Diversidade e Inclusão
  • Transformação social
Design de ExperiênciaTecnologia

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
Posts relacionados
Design de Experiência

Faster, better, stronger: Building a high quality product

Finn Lorbeer
Saiba mais
Design de Experiência

Entendendo como Design Thinking, Lean e Agile trabalham em conjunto

Jonny Schneider
Saiba mais
Design de Experiência

Good design is about more than just customers

Ben Melbourne
Saiba mais
  • O que fazemos
  • Com quem trabalhamos
  • Insights
  • Carreiras
  • Sobre
  • Contato

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

Mídia e relações públicas | Política de privacidade | Modern Slavery statement ThoughtWorks| Acessibilidade | © 2021 ThoughtWorks, Inc.