This week was spent doing a shortened version of the Google Design Sprint, a way of working that challenges designers to work quickly over a week to create a new product or feature, so that time isn’t wasted over developing something that won’t work. For this, we were tasked with designing Sprinting a digital product to help A+E departments.
To start with, we individually wrote How Might We questions (HMWs) for areas to look at within A+E. The challenge we found here was being specific enough to target a certain direction without over-committing to a certain concept, while also not being too vague as to not provide any direction for the sprint. Doing this individually but in groups helped me a lot as I’ve struggled with HMWs before due to the vagueness challenge of HMW, but I feel I’ve a better understanding of how to do these now with some direction but still leaving room for exploration.
After bringing our HMWs together, we discussed them and shared our thoughts of each others HMWs. We then chose one to take forward for the sprint.
We decided on “HMW lower the numbers attending A+E with insufficient injuries?” however also included a couple of other HMWs as secondary ones our main one. The secondary ones were some of the ones I did that were too specific to be a main question, but provided direction and ideas for things to consider around the main HMW.
The process of selecting our HMW was something I found really useful as with uni projects being mainly solo projects we don’t get the opportunity to work on a project whose initial direction is created by someone else. I also found the idea of using a main HMW with similar secondary HMW to aid the main to be really beneficial and allow for a motivated project from the start.
With our HMW selected, we next moved onto to looking at our users. This was interesting at first because of the nature of question, the users or people we were designing for were essentially the people causing the issues in the system, rather than the system causing issues for the user. To realise our users properly, we created a range of users, from people unnecessarily slowing the system, to people who are speeding the system up but should actual be a cause of the slowing. Using a spectrum of users was really useful here and allowed use to target particular use cases better and address issues for both people who are slowing the system down and speeding the system up. This way of identifying users is something I’ll keep in mind and hope to use again in the future.
With users identified, we each picked a user from our spectrum and created a persona and empathy map for them.
The first persona is for someone having to use A+E who already largely knows what is wrong with them, so there may be opportunity for them to have a faster process.