AT A GLANCE

IBM Asset Performance Management is a tool that leverages Watson IoT sensor data and more to primarily track the life and performance of assets over their lifetimes. Additionally, APM provides predictive capabilities that incorporate artificial intelligence to predict assets' decline, allowing for better preventative maintenance and replacement strategies.

My Collaborators: Karen Gosciminski, Mason Sperling

ROLES

UX Design Intern: I worked in a design team of 3, while collaborating closely with offering management, user researchers, and development teams. I mainly created prototypes of user interfaces and task flows using Sketch and InVision. Working in agile, I also helped to break down sprint design goals into tangible, actionable tasks to tackle one at a time. I was also able to participate in a few user interviews with our stakeholders.

DESIGN GOALS

Human-Centered Design

IBM Asset Performance Management has already gone through several iterations of development since its initial release. However, it has historically been lacking in the aspect of human-centeredness. While the current tool functions well and provides all the functionalities it purports, there is much room for iteration and improvement utilizing the invaluable feedback of current customers and stakeholders. During my duration on this team, we mainly worked towards this goal of becoming more deeply connected with our users to provide substantial design improvements.

In aiding our design, we have a persona: Marcia, who is a reliability engineer. Her expertise, responsibilities, and desires are well-documented across the team, summarized down below.

DESIGN PROCESS

I joined the APM team during a more transitional period where we had just started adopting the agile process and were trying to integrate across all the teams we collaborated with. Although we poured a lot of our efforts into adopting an agile workflow, there were definitely elements that fell short of a true agile pace.

Agile Process

In preparation for a sprint, we utilized Mural as a way for us to map out the overall design goal that we were going to tackle for the duration of the sprint. Together, we would map out the key steps in the user's flow and break each one down into its basic components. We would then take this breakdown, validate it with our offering management team, and start picking off pieces as design work while also creating numeric estimates for each item depending on the amount of work we predicted it would take.

Throughout the first week of the sprint, much of our time was spent with our heads down, fully involved in design work. We would create rapid prototypes of the core screens involved in the specific user flow, and occasionally turn to offering management or development with questions or obstacles that we encountered while doing so. We utilized ZenHub to organize our work and track progress.

The second of week of our sprints was spent mostly in a stage of feedback and iteration. We would demo our designs to offering management and development, receive their feedback, and turn their suggestions into design iterations. Once we had gone through enough internally where we felt the design was at a good place, we took them to our broader stakeholders for more user-centered feedback. Although we didn't get to do too many of these feedback sessions during my time with APM, I thoroughly enjoyed the occasions we were able to.

Finally, at the end of a sprint, we would play back all of the work we accomplished with offering management, development, and other design teams within IBM who might have worked on similar things. We'd then do a sprint retrospective within the 3 of us in the APM design team to reflect on the details of the mechanisms of the sprint– what went well, what could have been better, etc. We'd use these reflections to shape the way we tackled the next sprint.

EXAMPLE SCREENS

Much of my work is still under NDA. If you would like to learn more about my design work for this project, feel free to contact me for more information.

TOOLS