Hypothesis driven products

Something we are doing now, in a very considered way.

How to implement hypothesis driven development

From a design perspective, tieing things to expected outcomes and behaviours that can (and will) be measured sure is a nice way of focusing decisions and building credibility.

The ‘ole “fulfil a client requirement listed in bullet-points” thing must die. No one, not even the client, is ever truly satisfied with that approach.

Analysis (and theory*)

I’ve been reading Sam Ladner’s Practical Ethnography. It’s full of gems that I plan to summarise, but Chapter 9 is especially good. Especially this bit: “It is theory, not method, that differentiates good research from poor research”.

Sam Ladner writes that theory will help guide you through your mess of notes and photos and observations.

For example,

  • Goffman’s theory of the presentation of the self
  • Butler’s notion that gender is a performance
  • Bourdieu’s idea of cultural capital.

So many new ideas to follow, and so much happiness that we can all come out of the closet and acknowledge that theory has practical applications when interpreting data.

A bit of Foucalt, anyone?

*An aside: Once I went and spoke to a designer research academic about perhaps moving back into academia.

“You keep talking about theory”, she said, at one point, in quite a sharp tone. “But it’s theories. There’s not just *one* theory“.

I think that was the moment I realised I could never return to academia because academia is fundamentally ridiculous.

How to split out a super large excel spreadsheet

I am working with an excel spreadsheet of about 132,000 rows.

Or, rather, I am not working with that excel spreadsheet because every time I try and manipulate the data excel crashes.

Manually splitting the spreadsheet into smaller, tinier spreadsheets was not something I was going to entertain.

Then I found this fantastic, super-awesome macro. How to split a file.  Go get it! Thank me later.


How we work together (research and design) or who do you think you are?

At work, we’ve been trialling a way of working in a product team where we have a dedicated researcher (me) as well as a dedicated designer (my design buddy).

I think the question we’re really working out the answer to at the moment is “just who do these research people think they are” and also “why exactly do we need them?”.

We’re still in the process of nutting that out.

These are the things I’m thinking at the moment, as a result of this trial 

1.  The researcher and the designer need to work side-by-side.

2. Researchers bring a particular mindset to a problem. In Practical Ethnography Sam Ladner describes this as the “emic mindset” (or, the perspective of the person using the product).

3. When it’s just you trying to cover both the research and the design (fairly usual practice when you’re working in a less established design team) switching between the two mindsets is hard. Even if you’re good at both, it’s two very different ways of working.

4. Not everyone is good at everything. If you are working alongside someone with complementary skills, your product will benefit.

5. The researcher doesn’t really just do research. The designer doesn’t really just do design. At a talk recently Leisa Reicheldt estimated that, for user researchers, about 30% of time spent is on the core practice, 70% of the time is spent talking (talking to each other, in meetings, presentations, discussions with the product team, the broader community of practice, that guy in the hallway … )

6. Good research helps frame the design problem in a way that can be quantified by the business, as well as enacted on by the designer.

7. People are worried that the researchers will become “too academic” and “critical of the designer’s choices” and generally be a pain in the bum. I have many thoughts about that, but most of them boil down to “hire people who can play nicely. Don’t hire arseholes. Not sure about the academic thing.”


Interesting techniques for rolling the user research onto the product roadmap.

How to build a product roadmap based on user research


Mapping the research insights
Mapping the research insights

I found the approach to mapping the relevant insights quite useful.

As well as this set of principles further down in the article:



My advice is to select your projects in that order: