Research findings over the long term

My rough and patchy notes from the Cross Government Research meet-up that happened on Tuesday 12 April 2016 at DVLA in Swansea.

Dave Ellender

Stop important stories from being forgotten

  • create a spreadsheet of user stories
  • give each story a star rating
  • star rating = how many times this problem was seen
  • use this rating to help prioritise backlog
  • product owners can really relate to the star rating
  • if design fixes don’t meet the user need, this method helps to push issues back to the top of the agenda

John Waterworth

Make research data traceable

  • create one folder per round
  • e.g. date - R12 - name of study
  • keep all materials in there
  • participant naming: R12-P3-name-of-file.jpg
  • prune video files (keep key recordings, delete everything else)
  • watch out for accidental deletion (especially when using shared folders on Google Drive or Dropbox)

Sharing and keeping findings

  • show and tell what you’ve learnt (this builds up a “corporate memory”)
  • show 5 to 10 findings per showcase
  • each slide should have: a heading, 3 points and an image
  • share the slides around afterwards
  • build up a library of slides overtime
  • helps you to understand and remember
  • create a summary slide at the end of each phase to round-up important findings

Share at every opportunity

  • blog posts
  • make a comic
  • make posters
  • create “big picture” journey maps
  • create things that stay after you’ve gone (this is tricky)

Vicky Teinaki

Documenting changes in agile teams

  • things get buried in confluence
  • create living documents
  • Google Drive FTW
  • spreadsheets don’t work too well
  • try Google presentations (these are visual, malleable, trackable)
  • in Google videos, you can link to timestamps
  • create a stack of successes as you go
  • use them for decision making
  • these will help bring new staff up to speed
  • it’s a hub, it doesn’t have to include everything
  • everything must be shareable

Tara Land

User needs

  • user needs should not become too granular
  • real user needs are stable (they don’t change much overtime)
  • they come from the lived experience of real people
  • read Indy Young’s Mental Models book

Further reading