One of the main role of the researcher, is to provide quality, reliable
data to the product team. However, it is not quite as easy as it may
seem. Researchers, for lack of appropriate information or skill, may be
at risk of generating data lacking in quality. There are multiple
strategies that can be taken to ensure the highest quality of the data
being collected, including careful review of the research protocol and a
general skeptical approach to one’s research methodology. In this post,
I’ll introduce the underlying reason why a good researcher should
always initially cast a critical eye on the data he is being fed, and
apply this to his own data. I will then discuss some common threats to
good data collection I have encountered in recent weeks, and in
particular the threats of bad recruitment.
In this blog, I am going to talk about the craziness of supporting multiple development teams. I am one UX researcher responsible for interjecting user centered design and design thinking, among other UX practices within an agile development process. I'll take a different approach and reflect on seeing across the different teams as their individual efforts combine to make up user experiences that will support everyday developer practices. It all starts with chaos.
I am using the term chaos metaphorically. The particular definition of chaos (three exist) I am referring to is the more general definition: the initial formless state of the universe (from wikipedia). How chaos represents UX is that initially, at the beginning of a project, my job exists as a formless state until I ascertain how the teams will approach the different themes and scenarios decided upon by leadership. Nine sprint teams exist and I potentially had to support them all. But with some discovery it turns out that it makes sense for me to support seven of them because the other two don't have much new UX. On the other hand, the seven other teams began to decide what they were going to build and I wanted to ensure that they received UX support early on.
One of the first activities was to get early feedback to the teams that were still formulating their ideas and concepts. I've blogged
previously about creating methodology to support design iterations
early and often. I was able to get early feedback on six teams and helpful feedback for one of the teams that was further ahead and had bits to show. They were extremely flexible and made iterations throughout the study. This team ended up making six changes throughout. In conducting studies with the seven teams, I see opportunities for consistency at the interaction level. This is important because the interaction scheme is one of the most difficult to get consistent across teams who support different activities. We've got a nice solution to help support various activities in a similar way. Although I cannot go into detail, I will say that it's an interaction scheme that supports four types of developer activities, and we're pretty excited about it.