Strategic & Reactionary User Research

본 아티클은 아래의 영상을 한국어로 번역한 글이다.

https://youtu.be/Kj16KEqHsy4

 

 

---

 

 

When initiated, research can be either strategic or reactionary. Strategic research is most efficient and effective. It happens when a team deliberately derives a list of items that should be researched. These items can come from different sources, like tracked UX debt, issues customers have contacted support about, designs related to top tasks, or that important customer requested, and any new designs that are planned to be created. The list often takes the form of a research roadmap. The team, including leaders, developers, product, and other stakeholders, plus designers and researchers, prioritize the list of planned research topics and make them part of the product plan, or backlog, or schedule.

 

초기에 리서치는 전략적이거나 반동적일 수 있다. 전략적 리서치는 가장 효율적이고 효과적이다. 전략적 리서치는 팀이 의도적으로 연구해야 할 항목들의 리스트를 도출할 때 일어난다. 이러한 항목들은 추적된 UX debt, 사용자가 문의한 지원에 대한 이슈들, 주요 과업과 관련된 설계 또는 중요한 사용자들이 요구하는 설계, 그리고 새로 만들 계획인 모든 설계와 같은 다른 출처들로부터 발생할 수 있다. 그 리스트는 종종 리서치 로드맵의 형태를 취한다. 리더, 개발자, 제품, 그리고 기타 이해 관계자들, 또한 디자이너, 리서처를 포함한 팀은 계획된 리서치 주제 리스트의 우선 순위를 매기고 이를 제품 계획 또는 백로그 또는 일정의 일부로 만든다.

 

 

The schedule includes time to recruit the right participants and plan, run, and analyze research. Then design iteratively based on research insights. It's really important to embed the time beyond just planning and doing research to include the time in people's schedule to also change the design direction or prototypes based on research findings.

 

일정에는 적절한 참가자들을 모집하고, 리서치를 설계하고, 실행하고, 분석하는 시간을 포함한다. 그리고 나서 리서치 인사이트를 기반으로 반복적으로 디자인하라. 단순히 리서치를 계획하고 수행하는 것을 넘어서 사람들의 일정에 리서치 발견점을 기반으로 디자인 방향이나 프로토타입을 바꿀 시간 또한 포함하는 것이 매우 중요하다.

 

 

 

The second kind of research is reactionary and is what I've seen more frequently. Reactionary research happens when someone like a designer or a developer has created a prototype, then has the idea that it should be researched, and so asks a researcher to study it. Or maybe a design makes it into the MVP and a researcher suggests it be researched.

 

리서치의 두번째 종류는 반동적이다. 그리고 이것은 내가 더욱 빈번하게 봤던 것이다. 반동적 리서치는 다자이너나 개발자와 같은 누군가가 프로토타입을 만들고, 그리고 나서 그것이 연구되어야 한다고 생각하고, 그래서 리서처에서 그것을 연구하는 것을 요청할 때 일어난다. 아니면 한 설계가 MVP로 선정되어 리서처가 연구할 것을 제안할 수도 있다.

 

 

 

 

Reactionary research occurs basically in any case where design exists in some form, and researchers are then involved to try and get some user eyes and hands on it. Basically, there's been no plan to research the design. Reactionary research can happen on any project. We can't plan everything, after all, but this scenario is often challenging and unhealthy for development teams. Why? Well, by the time the researcher is involved, it may be too late for them to organize the research method that's needed to answer the research questions at hand or recruit the right participants for that study. Or sometimes the prototype that was created is an issue and it doesn't have the right fidelity visual content or interaction to research it well. And there isn't time to rectify this. And that's not all, if in-house researchers are all scheduled, they may refer the research requester to an expensive external consultant to do the research, forcing the business to spend more than they need to.

 

반동적 연구는 기본적으로 디자인이 어떤 형태로든 존재하는 경우에 발생하며, 리서처는 그것 위의 사용자의 눈이나 손을 얻기 위해 참여한다. 기본적으로, 디자인을 연구하는 계획은 없다. 반동적 연구는 어느 프로젝트에서나 할 수 있다. 결국 우리는 모든것을 계획할 수 없다. 그러나  이 시나리오는 종종 개발팀에게 도전적이고 건강하지 않다. 왜 그럴까? 글쎄, 리서처가 참여할 쯤에는 그들이 당면한 리서치 질문에 답을 하기 위해 필요한 리서치 방법을 구성하거나 그 연구를 위한 적절한 참가자들을 모집하기에 너무 늦을 수 있다. 혹은 때때로 만들어진 프로토타입이 문제가 있고 리서치가 잘 되기 위한 적절한 비주얼 콘텐츠 혹은 인터랙션을 가지지 않는다. 그리고 이것을 바로잡을 시간이 없다. 그리고 뿐만 아니라, 인하우스 리서처들이 모두 일정이 잡혀있는 경우, 리서치 요청자를 비싼 외부 컨설턴트에게 의뢰하여 연구를 수행하도록 하여 기업이 필요 이상의 비용을 지출하도록 할 수 있다.

 

 

 

 

Maybe the worst thing that happens with unexpected research requests is that they're completely denied due to a researcher's schedule. So important areas go un-researched. Then subpar designs get released, which is bad for users and bad for businesses. You can treat your researchers like short order cooks, but you're gonna get the research equivalent of runny eggs and burnt toast. Or you can maximize their knowledge by doing some preparation, valuing your people who do research and enabling them and encouraging them to take an active early strategic role in planning user research.

 

아마도 예상치 못한 연구 요청이 있을 때 발생하는 최악의 일은 리서처의 일정 때문에 완전히 거부되는 것이다. 그래서 중요한 영역이 연구되지 않는 것이다. 그리고 나서 사용자에게도 나쁘고 사업에게도 나쁜 수준 이하의 디자인이 출시되는 것이다. 당신은 리서처를 '짧은 주문의 요리'처럼 다룰 수 있지만, 연구 결과는 흐르는 계란과 탄 토스트와 맞먹는다. 아니면 당신은 약간의 준비를 하고 리서치를 수행하는 당신의 사람들을 소중하게 생각하고, 그들을 가능하게 하고, 사용자 리서치를 계획하는 데 있어 적극적인 초기 전략적 역할을 수행하도록 격려함으로써 그들의 지식을 극대화할 수 있다.

 

 

 

 

Summary: Like tech debt, UX debt piles up over time and, if left unaddressed, leads to compounding user problems and costly cleanup efforts. Agile teams can modify their processes to track and resolve UX debt.

 

 

---

 

*word

  - deliberately : 고의로, 의도적으로

  - derives : 파생하다, 도출하다

  - iteratively : 반복적으로

  - after all : 결국

  - at hand : 당면한

  - rectify : 바로잡다, 시정하다

  - be scheduled : 일정이 잡혀있다

  - subpar : 수준 이하의

  - equivalent : 동등한, 맞먹는

 

*UX debt란? https://www.nngroup.com/articles/ux-debt/

UX Debt: How to Identify, Prioritize, and Resolve