Collecting
-
@asktog’s thorough revised and expanded first principles of interaction design.
-
On Expertise, Mistakes, and Baking Bread
A nice little post form @jseiden about making and recognising mistakes, leaning and bread making.
-
Aaker Brand Personality Dimension
An interesting introduction into Aaker’s five dimensions of brand personality.
-
Reconciling the Differences in Our Data: A Mixed-Methods Research Story
Caryn Kieszling and Sera Mirchandani show us how we can avoid conflict and provide better recommendations when we unite qual and quant with a mixed-methods approach.
-
Five dysfunctions of ‘democratised’ research. Part 3 – Research as a weapon
The third part in @leisa’s blog post series about scaling research. This post covering when team relationships go sour and research is ‘weaponised’.
Why articulating the design is important.
Another reason to see research being used as weaponry is to compensate for a lack of confidence or ability in discussing the design decisions that have been made.
In a team where the designer is able to articulate the rationale and objectives for their design decisions, and there is trust and respect amongst team members, the need to ‘test and prove’ every decision is reduced.
Research as a weapon.
Feeling the need to ‘prove’ every design decision quickly leads to a validation mindset – thinking, ‘I must demonstrate that what I am proposing is the right thing, the best thing. I must win arguments in my team with ‘data”.
If we focus entirely on validation and ‘proof’, we risk moving away from a learning, discovery mindset.
Stoking the fire of conflict.
Validation research can provide short term results to help move teams forward, but it can reinforce a combative relationship between designers and product managers.
-
Elevate your research objectives - Write better research objectives to get better insights
@productherapist explains how to refine your research objectives to gain better results from your research.
What are research objectives?
Objectives boil down to the main reasons you are doing the research; they are the specific ideas you want to learn more about during the research and the questions you want answered during the research. Essentially, the objectives drive the entire project, since they are the questions we want answered.
-
User research plans - who cares and how to write one
@productherapist’s solid advice, and template, for writing a research plan for more focused research and more actionable results.
-
Five dysfunctions of ‘democratised’ research. Part 2 – Researching in our silos leads to false positives
@leisa’s second post about the common dysfunctions about ‘democratised’ research, this focusing on researching in silos, the query effect and false positives.
How do we fall victim to the query effect?
By focussing our research around the specific thing our team is responsible for, we increase our vulnerability to the query effect. That little feature is everything to our product team and we want to understand everything our users might think or feel about it, but are we perhaps less inclined to question our team’s own existence in our research?
What is a false positive?
Research that is focussed too tightly on a product or a feature increases the risk of a false positive result. A false positive is a research result which wrongly indicates that a particular condition or attribute is present.
Why are false positives a problem?
False positives are problematic for at least two reasons. Firstly they can lead teams to believe that there is a greater success rate or demand for the product or feature they are researching than is actually the case when experienced in a more realistic context. And secondly, they can lead to a lack of trust in research – teams are frustrated because they have done all this research and it didn’t help them to succeed. This is not a good outcome for anyone.
How do we avoid positives and gain more relevant insight?
The role of the trained and experienced researcher is to not only have expertise in methodology but also to help guide teams to set focus at the right level, to avoid misleading ourselves with data. To ensure we not only gather data, but we are confident we are gathering data on the things that really matter. Even if that requires us to do research on things our team doesn’t own and cannot fix or to collaborate with others in our organisation. In many cases, the additional scope and effort can be essential to achieving a valid outcome from research that teams can trust to use to move forward.
-
Goals Don’t Replace Systems - And Vice Versa
@DariusForoux talks about the differences of goals and systems and how they support each other.
- A goal tells you where you’re going tomorrow
- A system tells you what to do today
-
The Horizon of Inquiry – To find time for research, don’t fight the flow—fit into it
@mulegirl shares a model of fitting research into the flow of continuous work.
The key is not to optimize for your comfort, but to rethink how research integrates with the rest of your product work or other business decisions.
Continuous learning is no different from continuous shipping. Big releases take longer and big questions do too. We’re just used to thinking of the endpoint of research as a report rather than a decision—an artifact rather than an action.
Generative: What problem might we solve? Descriptive: What is happening currently/happened historically? Evaluative: How well is our solution working? Causal: Why is [x] happening/Why did [x] happen?
The lower the overhead of identifying research questions, planning the study, and recruiting participants (if necessary) the more realistic it will be to accommodate interviews, competitive research, or usability testing within a development cycle. Develop good habits and document the steps.
You can try timeboxing small research projects. Say for example “What can we learn about [x] by the end of the day?” We do this all the time in our daily lives when planning vacations or making major purchases. It’s the exact same process with a bit more rigor and collaboration.
Every organization has cycles, whether it’s the school year, the fundraising calendar, quarterly reporting, or a continuous series of iterative product development sprints. You can’t fight time, so work with it. When you think a bit ahead and map your questions onto your calendar, you’ll soon hit your stride of continuous learning.