Client
Large Federal Agency
Overview
A large government agency was evaluating an IBM enterprise optimization product to help scheduling managers improve how they plan and allocate their workforce. While the technology demonstrated clear power and potential, the client was underwhelmed by the existing user interface - and that gap was threatening the sales opportunity. IBM client engineering was brought in to build a polished, functional UI that could make the product’s capability land with the right impression.
Tools Used
Mural
CHALLENGE
The client saw the potential in the optimization technology, but the interface it came with wasn’t compelling enough to close the deal. Scheduling managers needed something intuitive, and the technology alone wasn’t going to be enough. The team had to quickly understand the client’s use case, define a clear scope, and build something that earned their confidence, all on a tight timeline. With the front end being built by an AI developer agent, IBM Bob, the team could move quickly. The challenge was making sure each version stayed grounded in what scheduling managers actually needed.
PROCESS - STEP 1
Discovery Workshop
The first step was getting aligned with the client on their reality. I designed and facilitated a virtual discovery workshop in Mural with three client stakeholders. The session ran about an hour, so I built it around prepared probing questions that kept the conversation focused and moving.
Because the client’s security setup meant they couldn’t access Mural from their side, I took on the role of live scribe. I shared my screen and filled in the board as participants spoke, so they could see their words captured in real time and correct or add to them as we went.
The board took the group from where they are today to what a successful outcome looks like:
Current state and challenges: how scheduling works today and where it breaks down
Future state vision: what they want scheduling to look like
Use case discovery: what problem we’re solving, who is affected, which business rules must be considered, what information, recommendations, or actions the tool should provide, what a manager needs to be able to see, and which business or operational outcome improves
Core needs: what the solution must do
Nice-to-haves: what would add value but isn’t essential
Out of scope: what we would explicitly not build
Success criteria: how the client would judge the result
By the end of the hour, we had a shared record of the use case, a prioritized set of needs, and clear boundaries for the build.
PROCESS - STEP 2
MVP Statement
With the workshop findings in hand, I worked with our Business Technology Leader to turn them into an MVP statement: a client-facing document that laid out our understanding of the problem, the agreed scope, and what success would look like. I pulled the core needs, nice-to-haves, and out-of-scope items from the workshop board so the scope came straight from what the client told us.
I designed it as a visual document rather than a set of notes, so it was easy for the client to read and react to. The client reviewed and confirmed it, giving the team a shared “North Star” to build toward.
PROCESS - STEP 3
Hands-On Evaluation and Service Diagram
When the engineers had a first version of the front end, I used it the way a scheduling manager would, working through the tool from start to finish to understand the real user journey. Because the front end was being built with an AI developer agent rather than designed in a tool like Figma, the working product was the design, so testing it directly was the fastest way to judge it.
From that walkthrough, I created a service diagram that mapped the manager’s path through the tool and the points where they step in, such as entering information, generating the demand curve, and reviewing results. I made it to make sure I understood the flow, but I also shared it with the team. It gave us a common picture to point at, which made feedback conversations more specific.
PROCESS - STEP 4
Iterative Feedback Sessions
As I reviewed each version, I logged my questions and observations in Mural. We then held working sessions with the team to talk through the feedback and fold it into the next iteration. The main changes:
Button placement: The button that let users submit the form and move on to the next screen sat at the top of the page, so someone filling it out from top to bottom could easily miss it. I recommended moving it to the bottom, where people expect the next step to be.
Login screen: The login page got a full makeover. We took inspiration from another design that was true to a typical IBM login screen, so the first thing users saw felt consistent with the IBM brand and matched the quality of the rest of the product.
Status indicators: For any status indicators, I pushed for standard red, orange, and green colors so users could tell when a status changed and what each status meant.
*Due to client confidentiality, I can’t share screenshots of the product, including the changes I helped make.
OUTCOMES
The UI was demonstrated to the client, and the response was strongly positive. They were impressed with what they saw and requested that the product be piloted in an additional environment for further testing.
The engagement ultimately closed as a $137K deal.
DELIVERABLES
Discovery Workshop: A tailored workshop agenda and custom virtual Mural board activities designed to guide collaborative exploration with the client.
MVP Statement: A polished visual asset that articulates the MVP, giving the client a clear artifact to confirm project direction.
Service Diagram: A map of the scheduling manager’s touchpoints through the tool, used to guide feedback discussions with the team.
Iterative Feedback Boards: Mural boards capturing my questions and UX feedback on each version of the front end.
PORTFOLIO
IBM Quantum for Federal
IBM Quantum for Federal
IBM Quantum for Federal
Creative Strategy
Video Design
Motion Design
Project Alpha
Project Alpha
Project Alpha
Creative Strategy
Video Design