Tales of Designer Initiation: The UX Design Boot Camp
Published: June 24, 2011
The stakes were high and the timelines short; we had just two weeks to prepare before going in front of the judges. As sweat beaded on our brows, our mentors continually encouraged us: “You can do it! Just a few more!” Sounds like your typical boot camp, right? Not quite. This time, those mentors were designers, and they asked us to iterate on our design again and again before pitching it to a panel of executives. This phenomenally challenging, yet productive UX Design Boot Camp exercise is the norm for new members joining our design team. Like the most avid participants in a reality TV show, we not only survived, but thrived throughout our brief project. Because it was such a positive exercise, we just had to share our experience with the UX community!
Our objective during the UX Design Boot Camp was to design a user interface for a new product concept in only two weeks. Four new team members paired up to form two teams that would work on separate design projects. Deliberately vague, the description of the design problem for each pair comprised fewer than five sentences.
Hoping to pull a creative masterpiece out of us, the organizers wanted to see what we could come up with quickly and placed no development or design constraints on us. They told us to go into out-of-the-office mode on all our regular project work. The UX Design Boot Camp was our only responsibility.
Each team’s final deliverable was to be a playback presentation of the design—that is, a pitch that included the target persona, top scenarios, and high-level designs, which we were to carefully craft for an executive audience. Plus, we were to present three interim playbacks to our mentors before the final presentation. During our two-week project, our mentors had scheduled a playback every two or three days.
For most of us, this was our first assignment on this team, so the boot camp offered us a chance to get to know our partners, the other designers on the team, and our products fast! Those who had already been through this experience warned us that our project would be both frustrating and fun and instructed us to go to our assigned advisor—one of the boot-camp veterans—if we had questions or needed clarifications.
After soaking up all this information, we were both excited and nervous. Excited because this project provided a cool diversion from our usual day jobs and an opportunity for uninterrupted design work; nervous because the final playback to management would include our vice president, whom we had not yet officially met. In addition, because the problem statement was relevant to our marketplace, we knew they would be interested in hearing our innovative ideas and potentially getting them into the product. Talk about pressure to give a good first impression and deliver something of value!
The first thing we realized was that we weren’t going to have time to do everything we would typically do during a project. Given the time constraint, we had to get over that quickly! Each team followed a schedule that was similar to that shown in Figure 1, covering all of the main activities one would usually expect on a design project. But we completed some activities much more quickly than usual. Early on, each team made decisions regarding what activities to trade off and had to stick with its choices to avoid spinning in circles.
Figure 1—Our abbreviated UX design lifecycle
The first phase of our project included competitive analysis and persona research. Both teams used the Web to evaluate what currently existed in the marketplace. We consulted internal support and other customer-facing teams to get a handle on current customer problems in the space. A set of personas already existed for our domain, so the teams expanded on these to suit each project. The team members shared their research with one another, quickly striking off some ideas and promoting others. After a couple of hours, each team had hashed out a solid solution framework, defining the major problems, target personas, and a proposed design space.
Interestingly, both teams adopted a mantra or tagline that summarized their project. For example, the mantra for a team designing a social enterprise application was Tag it, stream it, channel it. Not only did the mantra help keep the team members on the same page; it also provided the basis for their executive pitch.
The core of this project was its design phase. Because this was, after all, a design boot camp, we spent the bulk of our time was sketching, wireframing, and iterating through a series of mockups.
One team started to mind map and sketch ideas on paper. They used their mind map to collect all of their ideas about the primary task flow, then as a reference document to guide their sketches later on. The other team immediately started sketching the base framework for the user interface. Although the two teams engaged in different design activities, interestingly, both consistently fell into pair design mode. Drawing on techniques from software engineering’s eXtreme programming and usability evaluation’s co-discovery method, working in pairs can be powerful. One partner is the driver, controlling the input device and annotating the canvas, while the other partner serves as the navigator, guiding the driver through the design. This approach limits the overlap in their work, because both partners focus on a single task. It also draws out each partner’s ideas.
By the end of the second day, the base frameworks were in place. As both teams moved forward, they found it productive to alternate between co-design and a divide-and-conquer approach. Each partner took ownership of a set of screens and worked on them alone, then offered feedback on one another’s screens. One team combined the use of Balsamiq with sketching with a Sharpie on paper, while the other team chose to use Balsamiq as their sole sketching tool. It came down to personal preference. Some prefer the creative space of a piece of paper, while others like the extra structure desktop tools offer. Regardless of the technique they used, it was important to explore a large number of ideas and avoid expanding on just a single design solution too early in the project.
During the first week, the members of each team met at least twice a day to review each other’s work. This helped ensure partners would not take their designs in disparate directions. The benefit of team’s initially creating mockups in Balsamiq was that they could make changes on the fly. Something to keep in mind when it’s your turn!
By the second week, partners were using the same tool for medium-fidelity mockups. This is important because a playback looks much more polished if all of the designs flow and look the same. Plus, when both partners use the same tool, it’s much easier to share and iterate on each other’s designs.
Our discussions and reviews took on different characteristics during that second week. Rather than focusing on high-level task flows, the discussions progressed to detailed design choices regarding controls. So, regardless of where we were in the design process, it was key to be in constant communication with our partner.
The aim of the first three playbacks was to get feedback from the wider design team. In preparing for the first two playbacks, each pair emphasized different aspects: One team spent more time refining its presentation, while the other team focused on its design, because they had interpreted the core goals and playback objectives slightly differently. As a result, the feedback for the first team focused on how to improve their designs, while that for the second team was on improving its presentation. Because the designs and the presentation of those designs were equally important in the end, it was a challenge to balance improving both aspects throughout the exercise.
It took all three preliminary playbacks to fine-tune each presentation adequately for the final playback. The first lesson was to throw away the unnecessary elements of corporate templates. Because this was an internal project, we didn’t need the branding. Now that we had regained 20% of our screen real estate, the next lesson was to reduce the amount of text and, instead, use illustrations wherever possible. The final lesson was to focus on a few key scenarios and walk through a realistic story showcasing the designs.
It did not seem important to achieve such finesse in our first playback, but looking back on the experience, it was evident that it took all three of our previous attempts to get it right. As a result, our final playback was much tighter, more effective, and much easier to follow, taking up only 30 minutes of an hour-long meeting. We had plenty of time afterward for an engaging discussion and feedback on which exciting pieces we should really go after. That’s the kind of value you want to get out of a meeting!
Once the dust had settled and we had returned to our day jobs, we continued to realize the benefits of having gone through the UX Design Boot Camp. Its biggest impact was that the shared experience accelerated the process of getting to know each other. In the past, weeks might have gone by before new team members would have had the chance to interact. Moreover, members of other teams—such as key players from marketing, product management, and development—joined our final pitch and got to know us, too. Finally, some ideas from the boot camp continue to inspire others. For example, the design solution one of the teams created has already become a new product offering!
Having the opportunity to take a break from our day jobs meant we could come back to our daily responsibilities fresh. Just as, when you come back from vacation, you have increased energy and optimism, returning from boot camp offered the same benefits. We moved forward with renewed energy, and our team is excited about the design possibilities that lie ahead.
What good is any project if you can’t look back on it and identify things that you’d do differently? The next time we run a boot camp, we’ll suggest a few changes:
- Define playback goals clearly. We know, we know, pretty straightforward, right? Sure, but when you must finish a project so quickly, there is a knee-jerk reaction to just get going. However, if everyone isn’t on the same page right out of the gate, precious time can be wasted. Each playback, not just the final one, should have a clearly defined set of goals, so teams do not struggle with shaping their own and scheduling their activities. Once the organizers have shared these goals, they should take the time for each participant to repeat the instructions to avoid any misconceptions.
- Provide helpful examples. Because the organizers had run this activity many times in the past—in addition to having been participants!—they had a clear idea about the typical set of project deliverables. On the other hand, the participants were all new to the process, so they had no past experience on which to draw. While there definitely is value in stimulating new ideas, it is still helpful to establish some baseline expectations. Show participants some timelines, techniques, and tools from past projects, so both stakeholders and participants have a more consistent view of the final deliverable they expect.
- Deliver relevant and focused feedback. At the end of each playback, organizers had an opportunity to give participants feedback. For the most part, the feedback was really helpful in steering the next phase of the work. However, because the feedback also included comments on techniques and detailed design work, it also gave rise to confusion. If the feedback a team receives is not directly relevant to what they need to deliver next, it can really knock them off course, which can have serious consequences on a two-week project. For example, if a team is designing a login screen, getting feedback on how to better sketch that screen or receiving encouragement to try another technique can be distracting. Is the design insufficient? Do the moderators want you to learn a new technique? While all constructive feedback is ultimately helpful, some types of feedback might be more appropriate at the end of a project.
This boot camp was a new experience for us, but it may not be a unique idea. Perhaps your organization has tried giving you certain days or times to do something outside the box. The idea here is similar: take a break from the daily grind, refresh your mind, and potentially, discover the next golden idea!
If you have never participated in anything like our UX Design Boot Camp, though it may sound like a fantastic exercise, how can you make it happen in your workplace? The good news is you need only a short period of time, your manager’s support, and a little flexibility from your development team. It might be difficult to believe that you could be off a project for two entire weeks, but you can! If you’re part of a large design team, try scheduling boot camps at different times, so others can cover essential project work. Long after your boot camp is over, your organization will continue to benefit from your new ideas, and hopefully, gain inspiration from them, too.