Life inside the design asylum

A sneak peek at how our design teams operate

The BAM Hybrid Cloud design team at IBM. L-to-R: Troy Bjerke, Jamie Skinner, Sandra Tipton, Esteban Pérez-Hemminger, Lauren Goldstein, and Natalie Caudell.

People often ask me about our design teams — how they operate, how much autonomy they have, what tools they use, what processes they follow, whether they’re entirely populated by bearded hipsters, etc., etc.

Now, while each team is made up of a different set of individuals, working in different product contexts, there are some common threads. So, I thought it might be of interest to share some insights with you all here.

But instead of writing up my observations, on this occasion I asked one of my design teams to introduce themselves and to share a bit about how they operate.

So here’s a sneak peek into the life of one of our IBM design teams, within the Hybrid Cloud Design organization— written in their own words.

Hello, we’re the BAM team!

(In case you’re wondering, we call ourselves BAM mostly due to our penchant for comic-strip-sounding words. Plus the product we design for is IBM’s Bluemix Availability Monitoring service. So that was lucky.)

Let us introduce ourselves…. We are:

• Esteban Pérez-Hemminger (fearless design lead and pun master)
• Troy Bjerke (researcher extraordinaire — and only bearded hipster)
• Jamie Skinner (Design Prototyper by day, data vis expert and UX unicorn, also by day)
• Lauren Goldstein (newest recruit who’s killing it in UX — after our beloved Nina Dang transferred to San Francisco)
• Natalie Caudell (fingers-of-gold visual designer)
• Sandra Tipton (amazing design manager and work mom)

The BAM team out for lunch on a day off.

A bit about the product we design

Here’s a very quick summary of the product we work on:

• Bluemix Availability Monitoring is aimed at application developers (people who write and deploy code).
• It helps developers test the performance of the apps they build to ensure they work, respond quickly, and meet their end-users’ expectations.
• If there are any problems with the app, BAM highlights these and helps users to determine what might be causing them.

How we operate

Here is our own tried-and-tested recipe for success(ish):

1. Preheat the oven to 350˚F

In the beginning of a project we’re usually given a problem that we need to solve. Although this isn’t an ideal way of identifying a problem, our researcher, Troy, will take the prompt and do generative research to confirm that what we’re solving is useful and addresses a valid pain point for our customers. Once we validate the problem, we look at the current as-is scenario and take a swing at writing the ideal to-be scenario.

Forming an initial user story on our team whiteboard.

2. Mix wet and dry ingredients in a large mixing bowl

When we feel like the story makes sense, we start to iterate on designs up at the whiteboard. As we do so, we usually start to see holes in the original story, which leads us to revise it as needed until the story and the rough designs fit hand in hand. With some confidence and a lot of doubt, UX and Design Prototypers take a swing at creating the first low fidelity prototype so the team can get feedback on the current direction of the experience. We hold playbacks every two weeks, where Product Management, Design, and Engineering colleagues come together. Our design team gives an update on the progress we’ve made and we walk through the current designs to make sure everyone is on the same page. In other words, we put the IBM Design Thinking framework into practice.

Playing around with some initial low-fi visualizations.

3. Add a little cilantro

Once we’ve aligned as a team, we perform user research, which includes getting feedback from our users. Research and UX will collaborate to create a lo-fi prototype to test our general assumptions about our designs. Are we thinking about things the same way that our users are? Does our information hierarchy align? Does this basic design communicate what we want? Are there things we aren’t considering? Typically, this becomes a clickable, prototype-based usability study using Marvel and UserTesting.com. These tools allow us to get video feedback from potential users thinking aloud while solving problems in our prototype, which we then review and analyze to see if we need to make improvements to our design. Typically we share this process as a team to diversify the workload and to get a mutual understanding of how our users are approaching the problem through our design.

One of our usability tests conducted via UserTesting.com

4. Panic — and perhaps remove the cilantro

Based on the user feedback, we revise the designs as needed. Typically, we will create a revised version of the Marvel prototype to re-test so we can further solidify the design direction. Finally, we start creating higher fidelity assets. UX will start creating higher fidelity wireframes, and the feedback from the testing sessions will inform the coded prototype.

5. Walk around a while trying to figure out if your life is going in the right direction. Then shake your booty: it’s going to be okay.

Around this time, the coded prototype is wrapping up and ready to be tested. Research and Design Prototyper will collaborate to create a problem that our users can solve using our designs. This allows us to test the nitty gritty of our designs. What happens when you hover here? Is the click area too small? Do these animations make sense? As before, we review this feedback for further learning points about our designs. Hopefully at this point, our revisions are small tweaks that we can make easily or which can be addressed in the visual design phase. We then combine forces. With the high-fidelity visual design and a coded prototype, we have a strong set of assets to present to our engineering colleagues for implementation. Anything else that comes along is captured in a GitHub issue for easy tracking, assignment and resolution.

6. Sit back and enjoy!

Remember, when life gives you lemons just add cilantro…(or not).

And BAM! Here’s one we made earlier :-)

A picture is worth a thousand words:

And for those of you who don’t much like reading, here’s a diagram:

Our design team process subway. Look out — doors closing!

What you’ve just read is admittedly a somewhat simplified / idealized version of our process. Real life can be more complex and messy. Oftentimes directions change, and in some cases whole projects get tabled. For this reason, to keep things fun, we sprinkle in as many puns as possible and instigate a veritable plethora of team activities to regularly bring us together as people. After all,

Software design / development is primarily a human endeavor.

So there you have it: a sneak peek into the working life of one of our Hybrid Cloud design teams, showing a little of how they operate.

As this account from the BAM design team hopefully demonstrates, at IBM Design, we firmly believe in:

• forming multidisciplinary design teams (with individual designers who have a particular focus on research, UX, visuals, or prototyping)
• taking time to form well-researched and well-reasoned user stories so that we know we’re putting effort into things that matter
• design teams working closely with Product Management and Engineering colleagues
• user research informing our design work, then testing our designs with sample users
• random soft toys, metaphors that only partly make sense, puns, team barbecues, beer, unicorns, and pretty much anything else that enables us to have fun together

Thanks to Esteban, Troy, Jamie, Lauren, Natalie, and Sandra for sharing their insights here and for being such a fantastic and user-centered design team.

Arin Bhowmick (@arinbhowmick) is Vice President, Design at IBM based in San Francisco, California. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.