Building a Research Culture
How I changed my own mind about what “research” is and should be
This post is a reprint from my newsletter at Frontalobe.Substack.com
Rejection after rejection, I began to suspect that I was doing something wrong. I identified my tendency to impose my idea of “research” as the main culprit. I realised that my idea of “research” was different from “research” in the UX industry complex. It took four big rejections from applications-that-matter (what a waste!) to help me reach this point.
We were all speaking about “research” in different wavelengths even if we were using the same words in job descriptions, during job interviews, and other similar activities. An example here is the statement from an actual job description:
“you’ll conduct primary research; exploring the emotions, behaviours, and motivations of our users, and then work with teams of designers, Product Managers, engineers…”
While the team members, recruiters, and I were talking about the same thing — words such as “exploring the emotions of our users,” “conduct primary research” — these actually refer to different mindsets and frameworks. The industry interpretation is somewhat alien coming from an academic point of view.
This lightbulb moment came about simultaneously. Aside from doing interviews with different recruiters, designers, and managers from different companies, I was also engaged in a project with Dr. Erin B. Taylor on building healthy research cultures. What were two different life domains quickly converged into a singular problem — the misunderstanding of research practiced by specialists and practitioners in the industry.
This post discusses my personal breakthrough from misalignment to understanding. I re-formulated my own mindset from the “I” (lone research expert) to a “We” (all are experts or researchers). This shift in process helps everyone to scale their teams and organisations towards UX research maturity.
This post is divided into three parts.
I first briefly look at my own roots and my research mindset development from my institutional and university training. I use the linear flow in the double diamond design visual model as a conceptual similarity to the simplified academic scientific method.
In the second part, I turn to the DevOps groups that tackle the lone expert problem. This is more commonly known as the “hero culture.” This is a software development pattern using a lone expert or gifted player to troubleshoot problems to the detriment of building group accountability. This is seen more commonly in the open-source community.
In the final part, I propose a new research visual model that can help career switchers shift their personal mindset for the industry context.
Part 1: The “I” Mindset
The “I” in Research. The “hero culture,” or the lone expert, in the research world, is seen as having the exclusive training, skill, talent, or capability to undertake problem-solving. After all, this is the premise in university training — to hone individual skills of problem identification, investigation, and finally, insight conclusion and communication. By yourself.
The way it works is you must first figure out the solution on your own prior to sharing it with others. This research mindset is typically expressed as an outward fanning of the individual thinking and working process to other specialists (see figure below).
The simplified model visualises the “I” research mindset as containing two concentric cores (grey circles). The central core houses an individual’s competencies. These include both socialised and specialist training in methods, frameworks, and theories in their disciplines. The secondary circle is where investigation, analysis, and conceptualisation occurs. Of course, these domains are not strictly separate. I wanted to highlight here that “I” research resides within the person and body of a researcher. The typical flow is that only when the two core processes have been done, then, it it becomes feasible to present the results to the wider community (green circle). This linear flow of knowledge epistemology (knowledge formation) is reproduced in other settings.
The “I” mindset traditionally leans on a heavily siloed approach because the identity and work process of research is housed inside the individual bodies and brains of researchers. Knowledge is expressed in the solid lines of the individual core. It is a linear movement as it opens outward to the stakeholders and audience only once this initial process is done. Research collaboration among researchers especially in anthropology is quite rare but increasingly demanded with writing grants requirements. However, collaboration, if ever there is, potentially occurs at the process level once the initial core research is done.
What happens when this “I” research mindset reproduces in the industrial setting? This two-stage process from “I” before the “We” produces a lot of miscommunication and misunderstanding of what “research” really is. I’ll use the double diamond model as a visual anchor to this part two discussion and identify how the confusion occurs between specialists and practitioners occur in industry practice.
Part 2: Challenges in the “I” Mindset in Industry
Context: Locating Research in Industry. I use the double diamond diagram as a visual overlay of the “I” research mindset in industry practice. This model is from 2007 in which the British Design Council reconstructed the process by which product designers successfully built and launched what turned out to be iconic eleven products. Chief Design Officer, Cat Drew (2019) of the UK Design Council revisited the model and how it became an important tool to explain the design process to non-researchers. This is what makes the double diamond significant as a common reference. I use this as a generic visual framework (1) to communicate the design process (2) and to locate where researchers are in companies and teams.
This diagram is useful to examine how “research” is understood by industry practitioners based on researchers’ positions in the product or service development work process. One of the ways you can assess a company’s understanding is by reading the job descriptions for roles in UX Research, User Experience Researcher, UX Designer (and variations of that title) and how these slot into variations of the design process.
In this diagram, researchers may be located in the (design) solutions space — as usability testers and validating products. Or, researchers may be tasked in the problem space (research) in the areas of discovery and problem definition. Having this visual placement will help you clarify what “kind,” “type” of research, and “where” you are in the process that people are talking about. These visual and conceptual references have helped me build a “shared language” by recognising and enquiring how researchers and designers work together.
Where’s the “I” here? This diagram illustrates how researchers and team members can misinterpret what “research” is in this process. Without changing the “I” mindset, a researcher may think the discovery and exploratory phases rely on them as individual persons working on their own. While this makes roles clear between two parties, the “I” research approach misleads the team and the researcher. The members might think that the this process process is inherently a siloed and bounded domain relying on a lone expert.
This approach slots in well with the “I” research model — you collaborate with designers after one’s micro-level thinking process. This mindset is ego-focused and resists further collaboration. Collaboration with informants or participants are accepted within anthropology. However, very little actual research collaboration occurs at the analytical level. This is especially tricky in a discipline like anthropology in which research data and insight formation, are embodied into the bodies of researchers.
Part 2A: Consequences of the “I” Model
Linearity — One of the outcomes of the “I” research approach is a linear flow of knowledge and process. I want to zero on this because it has several cascading consequences for the teams and organisational culture. One of the most severe outcomes is what I call positional injustice. This is the structural, but also the emotional feeling generated from exclusion in the creation process. For instance, software developer Leon Gauhman (2018) asserts that the software team is relegated “behind” in a linear process of a double diamond model. He argues that software development work requires being in the front or co-creating at the early stages.
Positional injustice, especially from the mental model of a linear process, fails the research process for clients. Kate Ivey-Williams (2017) calls this “death by double diamond.” She laments the typical outcome in her service design practice wherein clients fail to execute her insights. Since the “model” puts service designers in front, then the shared impression is that the design process is done and implemented. She has seen that this flat model results in a waterfall type of development rather than an intuitive system of learning and doing.
The consequences of linearity are clear. It breeds the feeling of positional injustice among team members who lacked the creative input of any design process. It also affects clients who misinterpret a simplified visual model of the design process. Despite the research component being on the “front” of the process, clients might have a false impression that things are “done.”
Positional injustice is a result of the epistemology of individual based research. It is manifested visually in the old double diamond model. If there is only the lone expert with no system or culture to propagate expertise across teams, then designers or developers end up frustrated by being excluded at the design “font-end.” Furthermore, the lack of visual tool to express the shared process is a challenge.
New Iterative Double Diamond Model. The Design Council has since corrected the linear double diamond with an iterative process in 2019. They explicitly added arrows to indicate circularity, notations for collaborative design principles, and methods into the process. However, it remains to be seen whether the new yet clunky visual model will catch on as with the old one.
Part 3: Building a “We”
Two Questions: How do we form a traffic of collaboration between individuals? How do we shift our inherently individual-based mindsets and epistemologies? I turn to the software development groups and designers for solutions in the research space.
DevOps and Design Sprint. DevOps is shorthand for the culture of collaboration among different siloed units in an organisation that creates and maintains software. There has been a concerted effort to systematically create transparent, and accountable software development operations. This has been referred to as a culture of observability and putting into the spotlight the outcome of epistemic (in)justice (see Cat Swetel and Jabe Bloom). These industry practitioners have been grappling with similar problems with burnout and the “hero culture” plaguing developers among teams.
Hero Culture as Crisis Mitigation Culture. The “hero culture” refers to the the elite few like the Cult of the Dead Cow (cDc)who swoop in to solve problems in cybersecurity or select few who maintain the open-source code community (see Nadia Eghbal 2016). Some of the common consequences of hero cultures have been documented in the report Berlin Maintainerati (2019) among open source maintainers. These included individual burnout, abusive work practices, and inclusivity rather than a systemic onboarding and delegation of tasks to other actors in the community.
From Crisis “I” to System “We:” Fusing Researchers, Designers, Product Managers, with Software Developers. When it comes to teamwork, fusing different thinking and working models becomes the next frontier. Product development with software developers at the helm also struggles to fuse together user insights into their work process. Practitioners are realising that the process is messier and the opposite of the rigid diamond model. Jens-Fabian Goetzmann (2019) realised this in his job as a product manager working with product designers. He described the process as akin to the design squiggle of Damien Newman.
Software companies look to models used by top firms such as Google’s UX Design Sprint to institute a more robust and inclusive practical design and have reinterpreted them to their own practice and clients.
For instance, Dylan de Heer (2018) proposes a circular reinterpretation of a software development practice. In his diagram, the UX Design sprint forms the core and is embedded within the double diamond principles of discovery, define, ideate, and develop. Within each of the four components are the twin elements of tools and methods. In the research/discovery phase, he has outlined some of the co-creation tools used such as user journey mapping and empathy mapping among others.
The circular model makes it hard to visualise how different components such as the interaction between non-developer team members.
This is where a more linear interpretation by UX designer Skjoldbroder makes the relational process visually clearer by integrating the double diamond with the Design Sprint. In his diagram, he added the design sprint as a learning and testing phase in between the double diamond. His process flow model visualises the different roles of a team and the cooperative process that happens among members.
The two models attempt to envision and fuse a work process that recognises the different work and thinking processes of two different groups: the “researchers” and the “non-researchers.” The common link between these two groups is the shared design process goals which aim to solve a problem. “Research” is simply understanding how to look for answers to questions and not a specialist exercise. “Research” is actually a task done by all members of the team. In this way, thinking of research as simply just in the “front-end” or “back-end” or scrapped altogether due to cost-cutting is an example of the individual expert mindset. This same mindset can skew your understanding and reading of the job description of UX or user experience researchers.
Part 4: Changing the “Me”
If I want to change the conversation in research, it has to start with me.
One of the first important steps is to do a mindset audit. What common assumptions do I have? The first big step for me is to let go of the idea of the lone research expert. This is my first roadblock to building a research culture — research defined as an individually skilled researcher versus everyone enskilled as researchers. This requires that I break down the core and secondary levels of the research process. Of course, a lot of the initial process do require lone thinking but this need not be the only way.
This is not easy.
The mindset shift requires that I consider breaking down the solid lines into dashed lines around domains that were once highly valued in an individual practice.
Problems of Scale. We were taught that the core area of methods and frameworks is what is considered valuable and a “trade secret.” In an organisation that has low research maturity, a research practitioner may feel that he or she must cultivate and sustain their individual hero persona and guard it fastidiously, to prove their value and uniqueness. In doing so, this walled-in approach may benefit individuals in the short term but hurt teams, the organisation at large, and ultimately, oneself in the long-term because any insights and processes cannot scale.
To scale up research processes, the practitioner has to replicate him or herself by training others. One has to give up control and monopoly of skills around “research” and seeing it as a “trade secret.” By reproducing and teaching others to become researchers themselves, it relieves the practitioner from being overburdened and will communicate the value of research. The other employees will now be taught how to seek answers to their questions and perhaps, consult with the practitioner. This is a move towards research as building participatory and transparent processes. Research democratisation occurs right from the beginning similar to the DevOps community and not towards the end.
Communication. Moving to the “We” epistemology around insights sharing requires broadening the “research” methods to include co-creation workshops. These techniques democratise the research process by building stakeholders’ trust, empathy, and investment into the research problem and insights creation. Research as workshops greatly reduces distrust with specialists, relieves misunderstanding of “research,” and potentially achieves consensus and acceptance among the stakeholders.
The breaking down of barriers does not diminish individual practice but adds an extra step in a researcher’s toolkit. Workshops and other means of sharing results becomes part of inner core work. The cultivation of skills and inner practice retains its individual approach but requires an active community of like-minded practitioners to nurture. In a sense, all that happened is the reduction of “I” into inner core research and expanded the “We” research as the new norm.
For a research practitioner transitioning into industry, my former training and epistemology (how to acquire knowledge) were leaking into my job interviews and with frustrating results. However, once I identified that this was the cause, I was humbled by the realisation. I have since shifted my mindset about research and have since advanced in the job interview process. I now understand what the recruiter and interviewers were asking of me. With that out of the way, I can now concentrate on building a shared language by learning new “We” skills.
Postscript: There are other models that outline working, thinking processes, relationships, and concepts made by Hugh Dubberly of Dubberly Design Office. It is a great art and intellectual library! Thanks, Hugh for building and sharing!
