Watson Console

Developers are users too

Project Year


Business Units

IBM Watson,
IBM Cloud,
IBM Marketplace


Design Lead

Team (all remote)

1 other UX designer
3+ product managers
2 senior engineers
3 VP-level stakeholders


The Watson Console is the space in IBM Bluemix where developers get work done. With the Console they are able to create Hello World applications and start making API calls from the time they choose a service.

These ecosystems are high-volume b2b websites. I worked on the conceptual, foundational vision for this work.

See it in action

To see the work in its current, finished state go to:


This project was a long time coming. While working on Signal Services, and later on Conversation, both designers and developers pointed to the friction in the developer experience as a risk to customer acquisition and overall damage to the Watson brand.

Stakeholders were viewing design as low-priority, if the end-user was a developer. The IBM Watson group considers itself a company of developers, for developers–they know their customer best. In their minds, developers didn't care about design–and if IBM's own developers were figuring things out, customers would too. If they needed help, IBM sold consulting hours. But this approach was the reason other self-service cloud computing businesses were eating into IBM's market share.

Some of the strongest advocates for change in the developer experience came from designers and design researchers across IBM Design. We had support from developers themselves, whom we collaborated with to eat our own dog food. There's some irony in this–and there isn't anything particularly insightful about it. It's just UX 101: we are not our users.

A few teams across IBM had started to address the developer's experience on their own. As the only designer from Watson working on this, my job on this project was to position the design problems from Watson's perspective, and align on requirements and scope across business units. My work influenced a change in strategy in acquisition–from free trials based on usage, not time. And as a result, a 50% increase in conversion rates from free to paid.

Eventually, the IBM Cloud team ultimately owned the implementation of the work. I'm really happy to see the work become a reality.

Framing the problem

I like to build rapport on new teams, particularly with team members who have not worked with a designer before. Starting out with some design thinking exercises was my way of enabling trust, honesty, and efficiency among all of us.

Here's an example of one of the exercises we did together which helped us have a common understanding of the gaps in the developer experiences. In IBM Design Thinking-speak, an As-is is essentially a journey map.

I always approach my work with systems-thinking, so I created more analytical user journeys to spur a conversation about dependencies and technical debt. Their level of detail helped the team think about how much of their problem would be solved, and at what cost.

What you are looking at are pieces of journey maps detailing all the steps a developer has to take to make a "Hello World" application and convert to a paid plan; and one that shows the dependencies and major pain points in that solution. We were tasked with creating an experience that enabled developers to create a multi-service project in 10 minutes. As you can see, that wasn't going to happen.

Next, I worked with a senior engineer to create a competitive analysis from both a technical and a user experience perspective (NDA sorry 😬). I then facilitated a to-be experience exercise with the team, to align on what we wanted to achieve.

Low-fidelity design

Next, I created lo-fi visuals of what the experience to facilitate alignment among product and engineering stakeholders at the VP-level. I chose this level of fidelity to demonstrate the hops between experiences, the scope of the work, and to begin collecting high-level requirements that I or another team would need.

Fleshing out requirements

I reached out to design researchers across IBM Cloud and Watson to avoid repeating any mistakes, and to test my directions with users. I learned that while I was making the connections between ecosystems smoother, I wasn't fully addressing the developer's workflow. This was where the need for a dedicated, developer experience for creating and managing Watson projects became very apparent. At this point the project pivoted, largely due to stakeholders finding out about the amount of design research underway on this problem on flagship product teams, such as Conversation.

I took this back to my team, and with a senior engineer, I started sketching with him (remotely). Each sketch was used to write a story in Github.

I increased the fidelity to illustrate key parts of the experience in more detail.

Future Thinking

Once stakeholders had aligned on the need for a better developer experience, they began telling us that something was missing. It wasn't really showing the power of Watson–it felt ordinary.

I went back to the drawing board and came up with the idea to integrate a conversational experience within the developer experience itself. Instead of trying to figure out how to build with Watson, why not have Watson itself show you how?


I started out the work trying to stay Watson-centric, putting my team and users’ problems first. But I had to think strategically across business units to facilitate alignment, sell a vision to stakeholders, and make the work happen. Luckily, my experience working on the Signal Services team helped me grasp the technical side of this work. 

While my early work on Watson focused on its technology, this project was almost all business. My collaboration with the team resulted in a 50% increase in conversion rates, and a change in strategy from free trials based on usage, not time. It prepared me to think more strategically about my work on Conversation, the team I would work on next.