prototyping – Dave Briggs

I’m barely posting any links into Raindrop. I just like linking to them here, on my blog. But I worry they get lost. Not that I ever seem to look for them.

I newslettered.

Some nice bits in Matt Mullenweg’s bag.

Public Digital’s data strategy playbook. Plenty of good stuff to learn from in here.

A literal twist on the classic Minesweeper game.

How product teams are using prototyping in the public sector:

A few teams were very mature in their prototyping practices. When they needed to move fast, try out loads of ideas and surface issues quickly, they used low-fidelity prototypes in paper, Powerpoint, and Mural or Miro. These helped them test out different journeys and flows. They progressed to Figma and Prototype Kit when they needed more fidelity or to test out technical approaches.

More good stuff from Steve: all of this post is worth reading, but the section on Cycles, not sprints is great:

For research and development work (like discovery and alpha), you need a little bit longer to get your head into a domain and have time to play around making scrappy prototypes. For build work, a two-week sprint isn’t really two weeks. With all the ceremonies required for co-ordination and sharing information – which is a lot more labour-intensive in remote-first settings – you lose a couple of days with two-week sprints.

Sprint goals suck too. It’s far too easy to push it along and limp from fortnight to fortnight, never really considering whether you should stop the workstream. It’s better to think about your appetite for doing something, and then to focus on getting valuable iterations out there rather than committing to a whole thing.

Robert Brook:

I’m more interested in tactics than strategy. Other people can do strategy – they certainly want to and they’re better at it than I am. My tactical interest in in tools, services and methods that support delivery. Actual things. Stuff.

I consider prototyping to be a key part of this approach. The division between prototyping and production used to be clear – it’s much less so now.

James Governor:

Effective prototyping is essential for corporate pace layering of IT assets and governance. But if someone is telling you the prototype they want to build can’t actually be put into production well, that’s bait and switch isn’t it? Beware consultants bearing prototypes. If you have a good in-house development team on the other hand they will actually learn from building the prototype. And with any luck they’ll be able to put it into production. IT prototypes should not be like Concept Cars – but more like a sketch that can be filled in, added to, and made into “the finished article”. A prototype should be more like a scaffold and less like a facade.