As I mentioned in this post about our hands-on semester, my Web III class is working through a large-scale application development project for a client on campus. We were very fortunate to have an experienced design sprinter (Thanks, Kris!) come to class and lead us through the process. I believe that the sprint process was very effective, and gave the students a very fim foundation on which they will be able to design and build their application.
What is a Design Sprint?
According to the folks at GV,
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.
Google’s Sprint Kit promotional material offers a similar definition:
The Design Sprint is a proven methodology for solving problems through designing, prototyping, and testing ideas with users. Design Sprints quickly align teams under a shared vision with clearly defined goals and deliverables. Ultimately, it is a tool for developing a hypothesis, prototyping an idea, and testing it rapidly with as little investment as possible in as real an environment as possible.
There are many different versions of this definition out there, and perhaps as many organizations that claim they invented the process. The process has been used by plenty of very visible applications such as Uber, Spotify, Slack, Facebook, Google, and more. If it’s good enough for them, it’s good enough for us! Here’s how our modified 3-day process unfolded…
Day 1: The Golden Thread
The team met with the clients and got to ask a whole bunch of questions. The client gave us a typical “day in the life,” laying out a roadmap of their processes, pain points, optimal use-cases, and a sort of wish list for the future. Working individually and together, the team developed their own process road map, including original ideas for ways to “solve” the client’s problems.
We all came back together and compared notes… this allowed us to develop the “golden thread” or the ideal, optimal process narrative that will help guide the rest of the sprint. The golden thread in this case refers to the best possible solution for the most appropriate end user; specifically designed to eliminate financial, technological, or other limitations that often prevent teams from even suggesting a certain solution.
Bruce at PSODA suggests that “The golden thread of an application is the main pathway (or process) through that system. This can also be defined as the absolute minimum functionality that must be implemented before the system can perform its basic function.”
Day 2: Whiteboarding
Once our team arrived at the golden thread, and confirmed our work with the client liaison, the students got to work on developing preliminary sketches and rough wireframes for the application. Part of this was done as a homework assignment… the students arrived to class on day two with some sketches they had done over the weekend.
We hung up each student’s sketch on the wall, and took time reviewing, discussing, and evaluating everyone’s ideas. Each student then “voted” on winning ideas, mockups, and elements. We were then able to combine certain aspects of the application to form an even stronger iteration. For example, one student developed a particularly strong user experience concept for navigation, and we all decided that it would be the most effective for the application.
This whiteboarding process is a great way for students to explore their creative and technological impulses in a risk-free context. Kris and I made sure to set clear expectations going in to day 2 and really encouraged everyone to push their limits, take risks, and let go of perfection for a moment. I think the students responded in fine fashion, though it can be a challenge for students who are so used to performing for a grade.
Day 3: High Fidelity Designs
Once the team had completed their whiteboard/mockup designs, each student was assigned a “screen” to further develop. For example, one student did the application landing page, another did the project management page, yet another developed a Gantt chart, and others chipped in with shared UI elements, icons, and supporting graphics. The ultimate goal at this stage was to develop a pixel-perfect example of what the application might look like once its developed.
The designs were then presented to the client liaison for review and feedback. Students took the feedback, tweaked the designs, and will present them to the full client team this week.
The unofficial 4th day of the sprint was spent putting the finishing touches on the high fidelity designs and preparing our client presentation. Students worked together to divvy up the necessary work, assign roles, and assist one another with creating content for the slide deck. We only got to run the presentation once, but it was really great for the first go-round.
We present to the whole client team on Thursday!
The design sprint has been an incredible learning experience for me, and I hope, for the students. In casual conversation, they seem to be enjoying the process, and appreciate getting to work directly with “real” clients on an actual, functional project. I look forward to the next stage of this adventure, and will be writing more as we progress. Stay tuned!
As always, thanks for reading,