Understanding the Problem
Requirement Briefings
The primary purpose of a requirements briefing is to provide designers and other stakeholders with a clear understanding of what needs to be achieved in a design project.
I prefer to accompany the briefing document with a 30-45 minute session between Design, Business Analysts, and Product Owners to verbally align on the product expectations and clarify early any points of confusion in real time.
General Requirement Structure
Objectives - product/feature goal
Success Metrics - criteria for measuring the effectivness of a proposed design
Assumptions - information that can be taken for granted
Milestones - checkpoints to be aware of along the creative process
Requirements - The list of criteria that the product/feature is expected to fullfill
Open Questions - criteria or elements within the product/feature that have yet to be confirmed
Out of Scope - Known criteria or elements that are not to be addressed within the given story
Informal Learning Sessions
When diving into a story, it’s almost always necessary to collect information beyond the requirements brief. Scheduling a 1:1 with a SME helps to kick start that process. Sessions like this can take place as often as necessary, and they can be effective both as a research starting point or as a learning aid to accompany any other information material I may have already studied.
Rapid Design Sprint
The goal of a Rapid Design Sprint is to leverage the combined knowledge of a cross-functional team in one “room”, to understand and solve for product requirements.
I follow an adaptation of Google's rapid design Sprint for taking a concept "From idea to User-tested prototype in 3 weeks". The full process is broken into 5 business day periods which can be planned back-to-back or spread out and interspersed between other work days over a longer period of time.
The story being walked through in this case study was centered around incorporating draft saving capabilities into a wikipedia-style database.
The details behind this project are protected. The images included on this page have been chosen and scrubbed so as to illustrate the Design Sprint process without giving away sensitive information.
Prep Work
Sprints follow a general structure of activities, each one building on the outcomes of the last to create a cohesive understanding of what the problem is, why it exists, and the available avenues for solutions.
Creating and referencing visual representations of known information can help to keep activities and conversations on track during the sprint process.
I start by illustrating known user flows and unspoken mental models
Storyboarding
This stage is all about verifying foundational knowledge. I spend this time checking my understanding of the user’s problem, existing process, and/or needs against those of the rest of the group in order to settle on one shared understanding.
Annotations and comments are made by placing stickies directly on the visual references wherever they seem most intuitively relevant
Have users select a colour to represent their contributions on the whiteboard. This will be their signifier for the entirety of the Sprint
Establishing signifiers like this makes for easy scannability when it comes to understanding the context behind each comment, as well as keeping track of who might be a good initial point of contact for any follow up questions.
Identifying Known Issues
After establishing a common baseline understanding of the context, I ask the team to shift their analytical focus from objective understanding of process toward calling out any potential points of friction. These concerns can range from complicated needs to general annoyances to system contradictions.
The goal is to come up with any ways that a user might deviate from the “happy path” or even break our understanding of the system.
Need
A lack of something desirable ot useful for completing a task
Pain Point
A persistent or recurring problem that gets in the way
Happy Path
The desired experience, given that every piece of the situation occurs as expected.
Establishing definitions of design jargon can help to make sure that semantics dont get in the way of progress
Once problems areas have been established within the context of the user flow, those cards are organized and grouped based on common themes. This board will serve as a type of requirement documentation for the upcoming sketching phase of the Sprint.
The overarching idea of large clusters can be summarized on a companion sticky for easy recall.
If the problems board becomes too ladened or overwhelming to work off of, the team can take the extra step of voting on priority.
External Inspiration
This stage is an opportunity for team members to find examples of other products that solve the issues outlined in the last stage. The idea is to collect screenshots from other platforms as visual aids supporting possible solution avenues.
Each visual should be accompanied by the name of the platform it was pulled from and some bullets explaining what elements of the suggestion the team member would like to emulate.
I encourage team members to branch out into unrelated industries. Inspiration can and should come from widely differing source.
Rapid Prototyping
Outside of the scheduled workshop sessions, myself and any other designers involved would create lo-fi sketches of possible solutions to the problems gathered, referencing and incorporating current solutions and the inspirations brought forward by the team.
Design flows should be laid out to be as self-explanatory as possible, but I include notes in, on, and around the visual whenever more information is required
Lo-fi Design
Low-fidelity; rough draft versions of
designs created to better understand how a solution concept might work.
Design Review
Here I invite the team to explore and comment on the preliminary sketches with a view to understanding what portions of the concept are on the right track, what parts may need to be reimagined, and what might be missing entirely.
Once again, each sticky is placed directly on the part of the sketch being referenced in the comment. The comments are taken into account and updates are made to the design draft as the prototype is built out for user testing.
User Testing
Because of the time and resource constraints, user testing during a Design Sprint can’t always explore ideas as extensively as the requirement set might demand, but at the designer and researcher’s discretion, these sessions can serve as a robust starting point for the feature stories that may evolve from the Sprint findings.
I like to write test plans, collaborating with research wherever possible, to see how users interact with an prototype version of the lo-fi sketches, testing the the bones of the design and seeking to understand whether the Sprint team has made the correct assumptions around expected behaviors and the intuitiveness of the proposed information architecture.
Prototype space
Share Findings and Follow-ups
I finish Design sprints with a report out session both for Design Sprint participants and for stakeholders who didn’t have the opportunity to be involved in the process. The session summarizes the main points of the Sprint from agreed foundational understanding through user test findings, as well as providing findings-based recommendations and projected next steps.
Report Out Structure
Initial Understanding
Prioritized problem
Prototype Design
User Test Plan
User Test Findings
Recommendations
Next Steps
Results
Finalized designs aren’t part of the workshop process. Those outcomes are shared as during stakeholder meetings and hand-off ceremonies. Examples of these can be found under Sharing the Knowledge