Teaching Design By Doing Design

Artwork: Jackson Mila

Pop quiz: What’s the scariest part about a design project?

If you guessed the end, you win a cookie.

Being right never looked so delicious

If you think about it, what other point would you pick? The beginning is clearly the best, the project is nothing but possibilities and excitement and opportunities to do something cool. Then you get into it, and some of the fun fades but you’re heads down talking to users and solving problems and that feels pretty good too. Then you get to the end. Sure, there are those projects where you just can’t wait for them to end. We’ve all been there. But I’m talking about the normal projects, where you are working for a client, it’s time to hand it over, and then you just…..walk away. And here’s the scary part about that: you just poured your heart and soul into it and you know the second you leave that project, they will start making decisions that will begin to dissolve the cohesiveness of your meticulously crafted design. In a year’s time, it might not even be recognizable as your design anymore.

For the longest time, I used to be mad at the clients when this happened, like it was a personal affront to me.

“How could they not know after all those discussions we had that throwing everything into a hamburger menu is always the wrong solution?”

And yet, time and again, project after project, the same thing happened over and over and over.

There’s got to be a better way.

The fact is, most of our projects don’t end when our involvement ends. This always leaves clients in a precarious situation: They must operationalize a project that they are usually ill-equipped to support because of a lack of staff, resources, or skills.

The typical way a client addresses this issue: They bring in new staff or shift existing resources to the project just before we roll off. We then go through a short period of “knowledge transfer” and prep for handoff.

Sound familiar?

This approach is the status quo for many consultancies and agencies. And it is this process that is ultimately undoing your design. Here’s why: Transferring knowledge is not the same as transferring skill. One involves knowing what was done, the other involves being able to apply it.

This year I had the chance to challenge the status quo and explore a way to do skill transfer instead of knowledge transfer, by teaching design throughout the project — a unique blend of doing design and active mentoring. Here’s what I learned from that experience.

Fundamentally, we created an entirely new type of project with the client. In this new project structure, the client supplied the resources and staffing needed to take over a project right from the start. We then mentored client team members over the entire length of the project. In short, we were the teachers, they were the students, and the classroom was the live project.

Our “class project” involved creating a new mobile app to address a unique business challenge for a large logistics client. A key goal of that project included upskilling the client’s team to become both knowledgeable and skillful enough to successfully run the project after we roll off, with little to no degradation in project output. In other words, we would create the thing while simultaneously teaching them how to do it.

While our “students” had some baseline design and development skills, they had little to no experience with building mobile apps. Our job was to “teach them the way.”

Every member of our team paired up with a client peer team member. The client supplied a peer project lead, product owner, designers, developers, and QAs. In addition to mentoring them on specific roles, we also taught them the Agile methodology to help correct existing issues in their current development cycle.

To support the mentoring goal, we needed to be able to track their mentoring progress. We first tried a Trello board that broke down skill goals into smaller lesson units. Each unit was its own card on the board. The columns of the board were set as Not Started, In Progress, followed by columns labeled 1 through 5. The mentor would move a card to In Progress when the student first got instruction or was mentored about that topic. It stayed In Progress until the end of the sprint, at which point, the mentor would move it into a 1–5 column, which served as a grade for how well the team member demonstrated that skill.

The Trello board for tracking mentoring progress. Cards moved from Not Started to In Progress, then were assigned a 1–5 grade at the end of the sprint.

At the end of each sprint, we took a screen shot of the board. Successive screen shots would show the progress of a student over time. At the start of the next sprint, the mentor could decide to pull one or more new units in for the student to work on, or pull a previously graded skill back to In Progress for the next sprint if the mentor felt it was critical enough to warrant continued development. This process made the student’s learning both continuous yet measurable at discrete intervals.

The grading rubric lived right in the card so the mentor, the student, and the stakeholders had transparency in how each person was being graded. We set up these boards so only the mentor, student, project lead, and key stakeholders could see them.

Each card served as a self-contained mentoring unit, complete with objective, resources, and grading rubric

While the Trello boards worked great for tracking progress, they made reporting across the entire team difficult. There was no easy way to aggregate all the reports into something concise. That prompted us to shift the boards to JIRA as it provided better reporting capabilities.

In JIRA, we used epics to organize mentoring units into intro-, junior-, mid-, and senior-level topics. Because JIRA can only report on items that are “Done”, we ditched the 1–5 scoring columns and used the traditional columns of “Not Started”, “In Progress”, and “Done”.

Despite initial confusion about what “Done” really meant, we gained the ability to better plan out mentoring lessons by organizing them into future sprints. This made forecasting the expected student learning trajectory much easier.

Our project started off with employee experience discovery with stakeholders and users. We uncovered the main pain points and gained consensus on both a north star and success metrics for the project. However, we added several extra weeks before development started to deal with unexpected items that might come up given the unique structure of this project.

An early project activity proved critical: Measuring the current skill level of every student, so we knew the starting baseline. We conducted a 30-minute interview with each student. For design students, we also included a design test because we felt the interview wasn’t enough to accurately evaluate their competencies.

Using the design test results and interview insights, we set up a reasonable trajectory for mentoring topics. We also set expectations with the client that learning may move slowly, and that one or more students may not be 100% ready before our expected roll off date.

Once the actual development phase kicked off, the project progressed in typical 2-week Agile sprints with all the usual ceremonies. At the end of each sprint, in addition to the development output we also shared a mentoring “scorecard” that highlighted how each student’s skills have progressed.

We also scheduled daily mentoring sessions to supply consistent instruction and feedback to the students. As the project rolled on, we dealt with unexpected challenges in the typical Agile fashion: We did a retrospective at the end of each sprint and made adjustments for the next one.

While our whole team learned many new ideas and strategies to tackle a project like this, I’m going to focus on design-specific insights.

The first and most important thing we learned: teaching and mentoring are two completely different things. Mentoring is taking someone who has a base level of skill and helping them learn new things in a personalized, 1-on-1 way. Teaching is taking someone with no base level of skill, and instructing them, helping them, and validating they’ve actually learned what was taught. Understanding a student’s base skill level is vitally important: It determines where we start with lessons, how long it takes them to learn them, how effective they can be on a project, and how much of our effort it will take. We also learned that teaching is a completely different skillset than mentoring. There were times when a student was not “getting it”, and it was difficult for us to know if it was a flaw in our instructional technique or an issue with the student not applying themselves.

Second, teaching design on a live project can prove challenging because it can be hard to find work that is both available and appropriate from a pedagogical perspective. We attempted several approaches to address this. Initially, we gave students some “off project” exercises (e.g. design a calendar layout to practice alignment tools and techniques). However, we also wanted them to work on the live project as quickly as possible, so they had complete knowledge of design decisions as well as the underlying rationale. To accomplish this, we found smaller “nice-to-have” stories that weren’t on the critical path for development. That gave the students more time to work through multiple iterations of a design.

Having the right balance of “off project” work with “on project” work made the process more repeatable and helped us maintain a more consistent design throughput.

That said, eventually the design needed to be ready for development, and in some cases we stepped in to “take over” those design tasks. We used the “take over” process as another teachable moment by doing a live redesign from the student’s current design to where we felt it needed to be. We performed those collaborative sessions in steps, saving progress along the way and naming each subsequent artboard with the design principle used (e.g. consistency, 80/20 rule, alignment, visual weight, information hierarchy, etc.).

This approach worked much better than just a “before and after” snapshot because it had the benefit of leaving a “paper trail” of our thought process from start to finish that they could refer to later.

Not surprisingly, we found student availability has a great effect on the outcome. When they can’t provide 100% availability and have to manage additional projects, they may get swamped with more work than they can handle. In addition to limiting their availability to absorb and learn new things, the time they spend doing their current work can reinforce old behaviors — effectively undoing our efforts to teach them a new way to think. For that reason, we definitely recommend making all client team members 100% dedicated to the project. It’s worth the investment.

A more insidious challenge arose in the form of prior project knowledge a.k.a. the curse of knowledge. The longer a student was involved with a legacy system or operating process, the harder it was for them to detach themselves from what they already knew which prevented them from seeing things from a fresh perspective.

This effect manifested itself in many ways, but most notably, the deep domain knowledge contributed to an inability to “leave things out”. In other words, the student would typically assume that everything in the current system required inclusion into the mobile version (a cardinal mobile design sin). We spent an extraordinary amount of time trying to mentor people with very strongly held pre-conceptions, which became frustrating and ultimately self-defeating. This is another reason why we used “off project” lessons that helped separate mentees from their curse of knowledge and allowed them to more effectively internalize new design principles.

Related to that, we also learned that some design principles carry more weight than others. For example, a focus on consistency and alignment created an overall higher-value output than more structured and theoretical things such as hypothesis-driven design or color theory. While I don’t advocate ignoring theory altogether, to teach students the most design in the shortest time required a tightly focused, directly applicable curriculum.

Knowing when to let the student take ownership of a story required experimentation and iteration. Initially, students deferred to our expertise, but at some point they must shift to owning the final design. This turns out to be more difficult than it might seem, because of competing priorities. On one hand, you want them to learn, but on the other hand, we need to deliver a final design that meets user needs and our expectations for what constitutes good design. In some respects, this is a learning moment for us as mentors: learning to be OK with the final output not being perfect, especially when you see things that could’ve easily been improved. For me personally, this was easily the most challenging part of the entire process.

In terms of effort, we initially estimated spending about 50% of our time mentoring at the start of the project and then tapering off as the project progressed. However, as the project progressed, we started to feel like tapering off would be cheating the students: we have the knowledge, why not share it? So instead of reducing mentoring time, we saw value in spending a consistent 50% effort of mentoring and simply getting into more advanced techniques as the project progressed.

Of all lessons learned, the most significant by far: Starting with the end outcome in mind has incredible benefits.

No project lives in a vacuum. In a mentorship + development project like this, the results appear right from the start. That allowed us to continually have open conversations about the end of our involvement in the project, and how best to work toward that goal the entire time. The power this had cannot be understated. It was weaved into every conversation, every decision. As our involvement finally does come to a close, there is no uneasiness, no miscommunication. Everyone knows exactly what is happening, and how it will happen. We would certainly recommend this approach on all projects, even if they don’t involve mentoring.

A Final Word

While this approach requires more planning and uncovers more challenges, I believe this approach has a lot of merit and would work in many other situations. For example, using this mentoring approach to onboard junior designers to a new project and upskilling them along the way. Using a process similar to this would let you widen your pool of designer candidates, give them faster skill acquisition, and help you continually teach them in a consistent, repeatable way.

If you really want your client to succeed after you hand off a project (and are tired of your design getting co-opted by well-meaning but design-challenged decision makers) it might be time to consider a new type of project. We have found that this project type not only keeps the client fully engaged throughout the life of the project, it ultimately prepares them to run it themselves in a more enlightened and knowledgeable way. Personally, I found this project type to be more rewarding than any other project I’ve ever worked on, and our students enjoyed the experience so much that they asked if we could continue the mentorship even after we rolled off, which for me, made the ending the best part.

Design Lead at Lextech.com