,
25 tweets,
5 min read
Read on Twitter
My experience in a few product teams in different places recently makes me wonder if we're going through a phase of 'scientism' en.wikipedia.org/wiki/Scientism (thread…)
2/ Agile+devops seem to be working. Teams are getting better at iteration, orgs getting better at delivery, and coping with uncertainty.
3/ But… some orgs are becoming biased towards building shallow things quickly, over creating real change for people.
4/ Examples: no discovery phase. Senior product leaders who reject qual research. Some who've never done/seen it. Inadequate framing of the problem. Teams that don't know why they're working on something.
5/ Enormous, erroneous assumptions built into products; ones that would actually take longer to iterate out of, instead of understanding and framing the problem first.
6/ Scientism: "the dogmatic endorsement of scientific methodology and the reduction of all knowledge to only that which is measured or confirmatory.’ It’s that last half I’d focus on: the reductive element.
7/ I’ve been wondering why this trend is occuring, and although I think it’s multi-factorial, here are a few guesses.
8/ i. The emergence of 'measuring everything blindly’ is a late 20th Century trend, and one that has caused significant damage to our societies and our psyches...
9/ e.g. cops chasing targets and arresting people for nothing. See Adam Curtis’ ‘The Trap’, or Compstat (as seen in The Wire - good podcast here: gimletmedia.com/reply-all/127-… )
10/ ii. Methods like Lean and Agile, the rise of the product role; design sprints; these trends have resulted in an obsession with reducing uncertainty, increasing speed, numbers and efficiency; they are indirectly driving out other types of knowledge forming as valid.
11/ Note, it isn’t that I reject those trends - I do use them; but... they’re being used dogmatically, rather than selectively. Lean, in particular, smells like science, so you can give yourself and leaders a nice pampering sense of 'uncertainty removed!'.
12/ iii. I think a lot of people haven’t seen user research + discovery done well. This is a twofold problem: you have to execute the research well, but you also have to spend more time than you think is necessary synthesising and telling the story.
13/ On that last one: people who do this well tend to be more experienced. So you can have a shit-hot, bright young team, but they’re a bit less likely to be able to interrogate the deeper issue, or frame it well. Orgs aren't helping them practise this either.
14/ That old adage is so true for design discovery: “if you can’t explain it in a few words, you probably don’t understand it.”
15/ A while ago, I had a UX designer tell me that they had only ever found success in fast iteration (from the word go). But... at the same time, the product they were working on had *massive* and faulty assumptions built in (not of their doing).
16/ For a good example of deeper qual work to eliminate faulty assumptions and provide deeper understanding, see: themoderniststudio.com/2019/01/07/the…
17/ It’s kind of ironic that one of the strongest examples of design success in recent times is GDS. Their method seems to be based on a deep understanding of user needs, via user research (and less so, data). They were one of the first orgs to hire researchers in large numbers.
18/ The benefits to citizens+org are palpable, and affecting thousands every day. They’re the reason that it’s now dead-easy to renew a passport. (Side note: I learned a lot about how to do qual from @leisa - h/t also to @CharlotteEmilyM!)
19/ But user research isn’t the only example: I read once that Instagram was conceived when the founders wrote and re-wrote a value proposition statement about how people take and share photos.
20/ Understanding and framing the problem adequately, even without qual research, did something iterating and measuring could never inspire.
21/ I’m not totally sure what the answer to all of this is. I’ve been telling the $300m dollar button story (thanks @jmspool - articles.uie.com/three_hund_mil…!).
22/ It nicely ties qual and quant together. Quant tells you the what ("we’re losing $300m on a single button!") but not the why (“I’m not here to be in a relationship”).
23/ I’m not saying no quant, far from it. But 1. Quant can’t tell you why, so it’s not the most important source of truth 2. Framing is everything - it has a compound effect on all subsequent work: medium.com/creating-a-ux-…
24/ These things are especially true if you’re either in the early stages, or if your team can’t easily explain, consistently and in clear terms, what value the product should offer.
25/ my final 2p: sometimes you have to slow down to speed up.
