Design Thinking — Not Just For Designers

When I first heard of Design Thinking, I figured that it was something useful for designers but not for someone like me, a developer. Since my Introduction to Design Thinking Workshop upon joining IBM two years ago, I have learned that design thinking can be useful for anyone looking to deliver positive outcomes for users’ needs.

As a developer at IBM, I was never part of a team that employed design thinking with all three disciplines: designers, developers and offering managers. While I know that this is an effective practice that occurs daily all across IBM, when I was part of a developer team, we did not practice design thinking.

However, since moving into different roles at IBM, I often find myself turning to design thinking to solve the challenges at hand. My most recent role as program lead of the Front-End Developer Program, FED@IBM, brought me many such challenges. While developing, building user interfaces, and leading developer teams were skills I have years of practice doing, supporting a developer community while running a program was new for me.

In my new role, one of my program goals was to address a problem that many front-end developers hired through the Design program face — they experienced the same design bootcamp onboarding program as the designers hired at the same time, whose focuses were user experience and user research. While this program allowed designers to become well-versed at practicing IBM Design Thinking, the front-end developers were not well-prepared enough to be effective developers for their new teams. They spent little to no time coding or building interfaces, and after the three month bootcamp, many developers joined their team feeling less prepared than when they started at IBM. My challenge was to try and solve this problem.

After spinning my wheels for some time trying to solve the problem on my own, I turned to the practice of Design Thinking. I had lots of experience running or assisting at Introduction to Design Thinking Workshops at meet-ups, conferences or at IBM Design outreach events, so I was familiar with design thinking exercises. I pulled out my IBM Design Thinking Field Guide and set about addressing the user problem at hand.

I defined my outcome goal as: “to create a better experience for front-end developers in bootcamp so that they are better prepared for deployment to their teams.” I scheduled a design thinking workshop with seven other developers, six of whom had been participants in previous design onboarding bootcamps. In preparation for the workshop, I conducted user research; I held one-on-one interviews with all of the developers who had completed the most recent design bootcamp. I also sent out a survey to developers who had previously participated in design onboarding bootcamps and I asked them how well they felt their experience prepared them for deployment to their team. I also asked their managers about how prepared the developers were when they were originally deployed to their teams. Both surveys resulted in a very low overall rating and surfaced a great deal of feedback and comments. These were useful for the participants of the design thinking workshop to gain empathy and understanding of the developer’s experience.

We started out the workshop by drawing on this understanding and created an empathy map of an early career developer entering the design bootcamp experience. While gaining empathy for our user, whom we named Taylor, and drawing on the user research, we were able to easily identify pain points. They ranged from “no coding in bootcamp,” to “doubt and stress,” to “my dev skills are rapidly declining.” We were able to map out our user’s happiness level during their bootcamp experience, and it went from happy and excited to start at IBM to confusion, questioning their preparedness, and uncertainty about what they were doing upon completion of the bootcamp experience.

Once we understood our user’s pain points, we began to ideate on ways to address them. We quickly honed in on things like FED-specific learning, realistic code projects, mentorship, practicing agile development, and continuous learning. As a result of this ideation, we were able to formulate three hills:

1. Front-end developers are essential members of IBM Product Teams, who are prepared for the challenges on their deployed teams and who have grown their skills while contributing production code to projects that add business value for IBM.

2. Front-end developers are equipped to drive modern front-end best practices, such as Agile and IBM Design Thinking, once deployed to their teams.

3. Front-end developers who participated in the on-boarding experience are better prepared to contribute to IBM’s mission.

(Hills are a key component of IBM Design Thinking. Visit ibm.com/design/thinking to learn more.)

We took these hills and crafted a to-be scenario to work toward for the next design bootcamp. The solution centered around creating a separate development track that would run alongside the design bootcamp for a segment of the overall three month bootcamp. The dev track would be a 4-week program and would allow the developers to break into a separate team and work on building a user interface from high fidelity prototypes. They would build the UI using components from IBM’s Carbon Design System, working with a senior designer from that team. At the end of the month long track, they would have:

• built an application complete with a back-end database, API and front end

• added functionality to an existing project, allowing them to work with senior developers

• launched their application on IBM Bluemix, IBM’s cloud platform

We launched this new developer track with the current group of new-hires who started in August. In addition to the developer track outlined above, we lined up a series of sessions delivered by senior front-end developers. These senior developers covered topics such as:

• Getting Started with Carbon Design System

• GitHub Workflow

• Deploying to Bluemix

• Node

• Coding Standards

The senior developers also met regularly with them for office hours, allowing them to seek help with whatever they were working on at the time.

Following the developer track completion, the developers rejoined the designers and offering managers in the current session to work in small teams on a real IBM project. During this part of their onboarding experience, the developers are learning how to work on a team with other disciplines and are being prepared and empowered to build user interfaces for their team’s project. The developers are also developing a common language and practicing design thinking alongside the designers and offering managers in bootcamp, preparing them to join a diverse collaborative team who practices design thinking.

Ultimately, deployment to their teams will be the true test of how well this new developer track has prepared new developers to join their teams. Once deployed, we will ask their managers to compare their level of preparedness to the level of their previous new developers that were deployed directly to their teams; this feedback will be the ultimate determination of the success of this new developer track.

As for the effectiveness of IBM Design Thinking in solving a user’s problem, however, feedback from the current group of developers who are in the pilot of this new developer track has been very positive: “thank you for developing this new track” has been among the feedback already volunteered by these developers. Proof-positive that IBM Design Thinking can achieve desirable outcomes for designers, developers, or anyone willing to put it to work.


Kelly Churchill is a Software Developer at IBM and FED@IBM Program Lead based in Austin. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.