What I learned from my first product release
Playing Defense for the End User
This is a story about the role of design I expected and the role of design I experienced.
As a user experience designer, I empathize with users to ensure that their needs are met by the software products I design. I get to play offense and defense. I recently hit my one year anniversary with my team and reflected on a moment of change, success, failure, and imperfection.
My ten weeks of training in the IBM Design bootcamp empowered me to bring my fresh perspective onto an IBM product team. It was an intensive exercise in collaboration, problem solving, and crafting vision for emerging tech. Later, I joined designers, developers, and offering managers on IBM Cloud with the expectation that this would be how I work with a product team. I believed the role of design at IBM was to provide the visionary guidance and build new delightful user experiences with the wave of a wand. I’ve never felt so naively wrong.
Facing reality
“We’ve made some changes to the backend.” “We’re adding more functionality that nobody knows how to use.” “Here are more steps you need to add to an already exhausting task.” “Here’s a rare interaction that could potentially happen. You need to include it in your designs.”
These weren’t actual quotes from our engineers, but it’s what I heard.
The product team I joined helps businesses run and scale their applications and workloads. It serves developers who create and maintain enterprise applications on the cloud, and data scientists who consume and enrich data sets for insight. Think of it like a workspace and an app store. It provides tools and services that fit together to help developers make apps. In bootcamp, I got to make a lot of strategic, tactical decisions about the direction of a project, but on my product team, I was deep in the trenches.
The Problem: The product outgrew its underlying technology platform, its foundation. This directly impacted performance, reliability, and reputation. Our high-value product outgrew its simple, open-source, PaaS-only foundation and needed a more mature backend. To keep the business growing, the engineers, OMs and architects envisioned and prioritized a scalable platform solution that would redefine how users create and access their resources. They set a release date that everyone in the organization was working towards. They worked with design to introduce new features that maximized feasibility and user impact.
The Requirement: Reformat existing components in the product to use a different technical foundation, and introduce new terminology.
The Solution: My design team and I, along with offering management and front-end development, stood up to the powers that be. We shipped core component updates for the advancement of the platform. We eased users into new features by introducing them as soon as they logged in. For five months, we pushed back, refusing to ship bad experiences, and negotiated to ship less.
Making decisions and discoveries
I worked alongside my design lead and engineers to enhance the catalog “checkout” experience. After selecting a service from our Catalog, they land on a page with more detail about the service. From here they fill out a form to “configure” it, by assigning a name, location, and pricing plan for their usage. I made some modest updates to this flow, to reflect the new technical paradigm. Its humble beginnings as a simple PaaS product were forgotten when it became a huge enterprise-scale cloud product.
The “address” in the form still reflected these humble beginnings. In the past, users assigned their new resources to organizations (folders) and spaces (sub-folders). Resource groups, a concept created by our architects, are like singular folders, which replaced the construct of folders and sub-folders. Their intent was to take more cognitive load off the user and allow for easier tracking of billing.
An engineer challenged me when I showed the first pass of the above screen where resource groups replaced orgs and spaces. It wasn’t accurate and they called me out for it (in front of half of my organization). They argued for more complexity and more fields on this already (somewhat) arduous form. I wasn’t sure how to respond to this. Did they know I was new to this? Did they know I wasn’t versed in the complexity? Did they know I didn’t know I was incorrect?
It didn’t matter. My manager and lead played defense for me, and we negotiated to remove adding any additional complexity. Through their deliberation and arguing for the optimal user experience, simplicity beat granularity. This taught me that the fight was not one that I understood. I would need to step up and train for any time technical complexity interfered with something I wanted to simplify for users.
Removing gratuity
As a new hire, I wasn’t sure what I’d done to deserve the opportunity to work on something that all users would see and interact with. The header was more than a place to use core functionality, it was a place to showcase the brand i.e. the logo. Coming from a background in graphic design, I was ready to have a stake in something where brand was being reassessed and redesigned.
Besides functional transformation, this release involved the very first steps towards brand transformation. While IBM’s global marketing team developed the brand strategy and assets, my team implemented it. At a critical point, I asked myself and my team: should our brand communicate functional complexity, or functional use? The header often provided more functionality than the tools on the page. There was no optimization for mobile/tablet screens and the visual display was unnecessarily complicated.
The header redesign was a short term solution. It was the result of two two-week sprints. A long term re-evaluation was out of scope. We’d need weeks of interviews and evaluation to uncover what productive use means to all our users. This was an evolution of something that was already there.
I collaborated with a visual designer and our veteran design researcher to merge the two headers. We used the same user insights which informed the design of the same headers we were trying to condense. An audit revealed external links to outdated pages and links that could be grouped more intuitively. Our solution simplified the core actions in the header. We merged 21 links in 6 menus into 19 links and 4 menus.
Admitting Failure
The increased simplicity of finding links and menus were successful and impactful to the user experience, but we had almost over-simplified (or over-designed) for more common tasks. For example, more people clicked on the link to documentation, yet fewer people could find their full account name. To these users, we “hid” it, because it wasn’t visible unless you opened a menu.
How was I supposed to know that? I thought I was cleaning up the mess? An engineer let us have it for confusing the users he knew personally. Building empathy is one way of utilizing user input in human-centered design. It will also tell you when the decisions you make will interrupt their workflow.
Communicating change
Domain knowledge, and the lack thereof, is what led me to work on introducing new features to our users. Our documentation doesn’t communicate the subtle nuances and what they mean for end users. I again had the opportunity to defend the end user with simplicity in this project.
My greater team invited me as a collaborator to build a new component to announce all new features to end users. (Mina Adame shares the process of creating this project) The unique benefit of working on new feature messaging is that it reaches users with a range of expertise. My lack of intimate knowledge about the new features made it easier to empathize with a user who also lacked intimate knowledge.
We expected two results when users signed in or signed up: immediately closing or viewing everything. Every day, I click out of ads if they appear on an article I’m trying to read. Why should a developer behave any differently? To combat this, we needed something to take their attention, without asking for it. Refining the simplicity of the language was a long process. As was developing an image that quickly communicated the functionality.
We saw more new users interact with our new feature tour than expected, in the US and around the world. Our developers found that over 60% of new users clicked through the entire tour. It also revealed the importance of planning for messaging across multiple languages.
A good defense is the best offense
The release was not perfect. This was not an ideal rollout of the promised functionality. In some places, the intended vision was compromised. The amount of effort and complexity engineering could contain would prevent some features from becoming fully robust.
My manager and lead both reminded me that perfection in this one release shouldn’t be the target. I learned that a “perfectly” designed solution in software will inevitably stray from the original vision upon release. Especially when every nuance and interaction is accounted for. That vision can still live on, so long as you iterate and build towards it.
We still didn’t settle on releasing any worse experiences for our end users. Products get updated all the time. We didn’t want to risk this update introducing more complexity for the end user, just to improve technical shortcomings. Transformation takes time.
These views are my own and do not necessarily reflect the views, strategies, or opinions of IBM.
Check out my work and say hi on Instagram | LinkedIn | Dribbble
