My Venture into Enterprise UX with IBM


Projects I worked on

  • (Ship 7.2) App 2 Codename: Deck
    Bonus: Bootstrap prototype that I built (✅ yeah, I know basic HTML/CSS!)

    See CodePen
  • (Ship 7.2.1) App 3: Loss Event Entry
  • (Ship 7.3) Reimagined Homepage
  • (Ship 7.3) Global Search Enhancement
  • (Ship 7.3) Filtered List View Enhancement
  • (Ship 7.3) Organization Tree Picker UI Component
  • (Ship 7.4) User Provisioning Overhaul
  • (Ship TBD) Speculative Cognitive Designs for Risk Management
  • DashDB Design Thinking Workshop
  • Watson Analytics Purchase Platform

Large companies can be breeding grounds for learning and personal growth. My time at IBM was full of new learning experiences and helped me to grow tremendously as a designer. I led a small team of designers, facilitated design thinking workshops, shipped some neat product features, and was an essential member of the Design Studio party planning committee 🎉🍻.

In hindsight, three themes guide how I think about my time at IBM: People, Process, and Product.

Note: Under NDA, I’ve left out some of the specific details for each project worked on.

Who are the people involved?

design team

This is us (Dylan Trow, Jasmine Lin, and Susan Qu). Our small design team, straight outta Toronto (not quite Compton.) We were tight-knit and well rounded, each with a specific design speciality – mine being interaction design. Roles are a tricky thing to pin down when working on a new team. Being a designer encompasses many skills, from research to pixel-pushing to coding. Each member sometimes has experience in more than one area! As a team, we made sure to distinguish our roles and establish accountabilities, but everyone was free to learn from each other in different areas if they wanted. We made personal growth and knowledge sharing a priority.

‘Having a specific role and responsibilities frees your creativity. You don’t hold back as much. You devote yourself completely to your “specialization.”’

– Cooper “Better Together, The Practice of Successful Collaboration”

With my experience doing user research, interaction design, visual design, and basic coding I took on the role of team lead and interaction designer. This meant that I was able to bounce around ideas with each member to enable them to make smart decisions in their speciality.

Our awesome Design Manager Dolly took on the role of support rather than formal top-down management. She gave our team trust, let us manage our projects on our own, and provided us with mentorship and support along the way. Our design team worked together to figure out requirements and independently manage our project deadlines based on needs from product management and engineering.

We were the new kids on the block learning about the legacy product. We reached out to sales, product management, development, and product support to better understand the product. These people were from all over the world. We spoke with team members from Massachusetts, New York, Toronto, Ottawa, and even Australia. This meant that Dylan and I had to reach out to people on Skype, so that everyone could get to know us and put a face to a name. We used the Stakeholder Interview checklist from Boxes and arrows to figure out which were the right questions to ask. We learned a lot about how products and teams at IBM were structured, managed, and organized. This also inadvertently helped socialize the design team among the broader OpenPages team; most people we met with didn’t even know a design team had been hired!

product team

We set out to prove our worth to the broader OpenPages team by trying to help as many people out as possible. For example, the prototypes and design assets we created were useful for product managers to show customers, and for developers to build from. We had slide decks and presentations about design thinking that we were able to share with the sales team for client pitches. We tried to reach every part of the organization that we could! All just by sharing assets we already had. Talk about efficiency and cross-collaboration.

Littleton, Massachussets happens to be a few minutes away from Boston. It also happens to be where our development team and lead product manager work from. We pushed for budget to go fly out and meet them in person to do feature prioritization and sprint planning. The week was full of design workshops, presentations, and whiteboard planning. Oh, we also managed to sneak in a few activities at the British Beer Company and ping pong over lunch.

team 2

Lesson: Developing empathy and building relationships with your remote team is just as important as with your co-located team.

What was our process like?

We were all hired around the same time, so we started with a blank slate. The design team was co-located, but the challenge was keeping in touch with our remote team members. It required experimentation with different tools and practices to get right.

  • Slack vs Sametime vs Email?
  • Phone + Screenshare vs Skype?
  • Box notes vs Microsoft Word?
  • Box vs RTC vs Wikis vs GitHub enterprise?

What works best? What tools do other teams use already, and what can we introduce? How do we structure our collaborative design folder? After a few months of trial and error, we’d figured out what worked best to communicate and collaborate across all teams.

As for our design process, we borrowed ideas from Lean UX, Agile methodologies, and IBM Design Thinking. Each project would start with design research. In the research and scoping stage Dylan and I would figure out the problem we were trying to solve, and why we were solving it. We would work with our product manager Bob and with our customers. After we had more clarity on the problem, we would present the problem that we were exploring to our team. Usually we would use Empathy Maps, As-Is Scenario Maps, and sometimes would show demos of the “hacks” users were currently using.

From this stage, I would lead generative design activities with the team. This involved sketching and working through the interaction design and ideation phase. At the end of the session, I would be responsible for taking all of the ideas and turning it into an end-to-end user flow, or sometimes a lo-fidelity prototype. In this phase, I would make sure to incorporate all of the scoping and user research into the design, to make sure we worked within our constraints. After testing with users and presenting designs to Bob, I would pass the work on to Jasmine our visual designer for hi-fidelity mockups, and Susan our front-end developer/designer to build something that the development team could pick apart.


The user research network

We worked closely with customers when building new features. We dug in and reached out to the customer base of large banks in Toronto that used our product, so that we could schedule user research sessions. Most of these banks had never participated in user research before, so we needed to spend time educating them about Design Thinking. Dylan and I spent a long time building trust with our product manager and with the customer liaisons who would find users for us.

Once we were off the ground and running, we ran workshops, did usability testing, and ethnography with banks across Canada and the United States. My role was to collaborate on the design of the research plan, facilitate workshops, document, and take notes during customer visits.

Keepin’ things agile

Let me start by saying I love doing retrospectives. I would run retrospectives to reflect on and congratulate the team on all of the awesome hard work we were doing, but also to air dirty laundry and identify pain points in our internal process. This encouraged us to try out new tools and methods to smooth out our process and keep everyone happy.

For example, at one point we found that physical daily standups weren’t working for us, so instead we wrote our daily standups in collaborative Box notes. This solution was brought up by someone during a retrospective, and worked out well for us.


Lesson: Like your product, you and your team should always iterate on your process, keeping the things that work, while finding new solutions to pain points.

What impact did we have on the product?

Our team was brought in to improve usability and build simple single-purpose apps on top of the legacy product. We shipped six major projects during my time at IBM, each posing a different set of challenges.

We had some hard decisions to make. We didn’t want to alienate current users of the product with new designs, but wanted to follow the IBM design guidelines. In the end, we found a compromise. We used IBM’s modern flat design for bigger features and new single-use applications, but kept the legacy UI design for small enhancements and updates.

Big lessons learned

Communication is important, especially in large companies
I love working with teams and collaborating with other designers, developers, and product managers. I enjoy giving presentations, and reaching out to people across the organization. I’m fascinated by processes, people, and the communications that take place between different parts of an organization. Organizational design is really interesting. Busting down silos and opening up communications channels excites me.

Enterprise UX is tough, but rewarding
Anybody who’s ever designed a “simple form” for a complex enterprise product will be able to regale you with a tale of complexity and complication rife with technical constraints. It turns out it can be difficult to design something simple that is also highly customizable by your enterprise customers.

Designers often dream of working on consumer based apps where problems are “cool” and easily understood. Enterprise UX is different. It means being immersed in a completely foreign area (like governance, risk, and compliance!) I quickly found solace in a few web articles and E-books concerning enterprise UX design, and the challenges designers face (Design Collaboration in the Enterprise, Why I Design Enterprise UX, Enterprise UX Community.)

In the end, I realized that even though learning about a new discipline can be tough, I enjoy the complexity involved in solving these problems (big or small). Enterprise software is full of this type of complexity, and though it can be a struggle, once you find simplicity on top of all of the chaos, it’s actually quite rewarding.