Lessons Learned from Shipping a Product
Since finishing IBM Design Bootcamp, I have returned to San Francisco to join my IBM Analytics team. At the time I arrived, my team was working on getting the greenlight for a new project. After holding day-long meetings for most of the week, we had our executive backing and were told to prepare the product for debut a mere six weeks later. We had our work cut of out for us.
Project Miles — the project we built — aims to redefine the way Data Scientists work. It spawned from our attempts to understand Data Scientists and turned into the realization that they were missing a holistic tool for their work. Zoe Padgett, my fellow IBM designer, and I wrote a separate blog post detailing the design decisions of IBM Data Science Experience [here].
Shipping an entirely new product — especially in a tight time frame — is incredibly complex. I’ve found that I primarily grew in the following three ways.
Shipping a Product is More than Shipping a Design
In Design Bootcamp, our designs weren’t developed, but here we built and released it. Since this experience, I often see beautiful designs but can quickly notice holes that would surface if that particular design was to be shipped.
Designs, when being coded, get stripped apart and then reassembled piece by piece. There are many reasons why something could break, such as feasibility or scalability. Each time a design is adapted to be more feasible or more scalable, it then must be evaluated as to whether or not it still meets the user needs. This back-and-forth can diminish a product’s effectiveness and it’s something that only the design process can help mitigate. The amount of collaboration needed between design and development to get something shipped properly is astounding.
Moving from a file that is a finalized for design to one that is finalized for developers is a major step in the process that we often overlook.
Redlining, exporting assets, and organizing files for delivery are all time consuming steps that don’t initially get factored in for the timeline.
Collaboration Between Disciplines
The team behind the creation of this product could best be described as a startup, as a variety of people jumped into action to contribute. The collaboration between not only designers but between User Researchers, Offering Management, Developers, Marketing, Content, etc., is incredibly important.
Having access to the diverse array of talents is something very few companies can offer.
For example, having a dedicated user researcher to test even the smallest questions (i.e. “Do Data Scientists arrange their files by projects or notebooks?”) is invaluable.
Many different pieces of the product merged seamlessly when all teams worked together to move everything forward. It can definitely be overwhelming to have this many people involved, but once we all clicked as a team and hit our stride, the speed of progress leapt.
Wearing Different Hats
Also in typical startup fashion, we were sometimes required to wear different hats and it’s important not to get hung up on job titles. Pull from any other experience to make the impossible possible; put the success of the team before that of the individual.
About a week before the keynote to debut this product, our manager asked if any of us had video experience. Having recently made the Design Bootcamp video, I raised my hand and signed up to create a promotional video. Little did I know this was the video that was to be shown by our Vice President of Analytics, Rob Thomas, at Spark Summit.
I gathered all my camera equipment, a rolling desk chair as a makeshift rig, and all my knowledge of cinematography. I filmed and interviewed designers around the studio, selected and placed music, and then spent hours editing on Premiere Pro. Somehow, with the help of my team, I pulled it off. View the video here.
As a young designer at a large company such as IBM, I am incredibly lucky to work with a team that is shipping a brand new product.
This product is incredibly complex and definitely pushed me into the unknown place where I learned the most. Our large team, full of vast experiences and skillsets, collaborated together to design and build something far better than what any of us could have done alone.
