I’m currently working on a participatory design project with a group from one my classes (User-Centred Design — a full post on this project will come soon!). I also recently joined another project through CivicTechTO, a great local meet-up that aims to solve civic problems with technology solutions.
One problem both groups seems to be encountering is how to translate design research into actionable requirements. We’ve got a lot of design research from consulting with users and stakeholders and creating artefacts like user journeys and interview reports, but we haven’t distilled it in order to create meaning to pass the baton to other teams and facilitate an agile design cycle.
This leads to a lot of group discussion. On the one hand, some team members are concerned with how to best focus in on one aspect of the research in order to move the project forward; on the other hand, others are concerned that the research we have is not yet refined enough to start moving forward and that doing so would be premature.
This dilemma got me wondering: is there a more productive way to build our research outputs, such that they translate more immediately into requirements? In other words, does cleaning up our research for requirements gathering have to be an added step, or can we get the work started?
In the project team for my User-Centred Design class, we decided to start to make our research requirements-ready by creating highly refined user stories for the two of the users we felt we had significant research on. A couple of our teammates took on the task of focusing in on one of our users each, reviewing all our research, and coming up with a concise table with two simple columns: “User should be able to X,” “So they can X.” These were accompanied by high-level personas including the three central tasks of the user. This effectively creates a set of scenarios to inform requirements development.
As is almost always the case, more user research is needed to enrich our user stories; but this gives our client the opportunity to move forward on some aspects of development without compromising our research cycle.
When working on our design research, it’s easy enough to just throw ideas into documents and throw documents into a shared folder; but without continuously reviewing our research and building upon a thorough, yet concise presentation of it, we ultimately create more work for ourselves. Rather than needing to review everything in order to create a distilled version to inform requirements when all is said and done (or at least getting there), we should begin to distil and refine our research for requirements from the start.