Discovery notes Week 03
22nd to 26th April 2019
Slow day. Other things to sort beyond work.
Reviewed the new end of service feedback questions.
Wrote up some thoughts on a few issues.
Agreed to do a talk about GDS assessment to the graduate BA community.
Most of the morning was a resetting exercise following the workshop the week before.
It can be tough to get talking about data with people. It’s abstract.
So we’re prototyping to explore.
Discovery so far has been slower than hoped. Some of that’s due to changes based on feedback from a lab and workshop. Some of it other things.
Caught up with a graduate researcher to see how he was going on.
Spent the time before and after lunch mapping out an exploratory service.
We’re going to explore attitudes to data with a data donor service.
One of the provocative questions underlining the prototype was:
“You’d be happy if you or your loved one benefited from medical research, so would you be happy to donate your data to help this?”
- how happy people are to share data
- what changes if they data is donated
- what happens when people look at matching data with projects that would like it to be shared with. And those they wouldn’t
- what people need to know to understand research studies and make a decision about them
- what we’d need to show to give people a sense of positive feeling about donating
- what people would want in a way or a happy ending
Wrote a presentation about 5 lessons from doing GDS assessments. For the huddle.
Couple of issues here or there. Mostly spent time sketching a flow with Sam in response to the service we mapped out the day before.
Reviewed some work of Rhiannon’s. Asked for her decision on what of the three options was her preferred thing to take forward.
Did some annual review meetings. Always important for people to know what they’re responsible for. What good looks like and what’s important to achieve.
Back on sketching out the basic flow.
Then to the huddle.
Didn’t end up giving my GDS presentation.
Talked about how we document designs and design decisions. Then an interesting issue from Ben Cullimore about highlighting that the NHS website medicines A to Z may not include every medicine.
Prototyping prototyping prototyping.
Divided up the work with Sam.
Talked to Ben about benefit realisation and OKRs (objectives and key results).
Joined in a discussion on slack about documenting design decisions.
Poked Mat Johnson to share his tweet in slack as well as the twitters.
Utterly #lazyweb - swiftly and simply documenting and recording design decisions to create a usable record. What do you do? Any good posts I should look at?— Mat Johnson (@demotive) April 25, 2019
70 comments later I think it was a good thing to do.
It’s key to split up what it is you’re trying to document:
- How things act and look (now, should)
- Changes to designs
- Reasons for decisions
These are overlapping things but to me do have differences.
A reason for a change doesn’t need the whole service to be mapped out and every potential change shown.
But for a team meeting or planning session it might.
You have to find a consistent, efficient way to do this.
My design team, we do hypothesis driven design.
The goal being to log why we’re making certain changes.
I used to put all hypotheses in the prototype. And some colleagues said it was useful. But watching them read it it was the major one or two before entry into a prototype.
It also got quite laborious to do it.
For the opt-out service I’ve created hundreds of prototypes. Documenting all things on our Jira board and the prototype become tedious and inefficient.
If you’re writing lots of text in a prototype, you’re better off with a CMS or word document.
Within corporate environments there comes the question of shareability. If that document goes to confluence or SharePoint it might as well be buried in the garden.
But then, a prototype with a password and one designer to update it doesn’t sound like a great sharing mechanism either.
So, you have to find your way.
But the way forward isn’t doing nothing. Complicated systems need documenting. Teams need help being kept on the same page.
- Document your work as you go
- Write hypotheses
- Make it easy to understand your work
- Make it easy to have a discussion about your work