︎

Work         Art         About         Contact

Direct Deposit OOUX

B2B HR Platform

Project overview

Direct deposit is one of the most critical employee self-service features, yet the experience had become fragmented. Over time, three different versions emerged:

  1. Legacy Web
  2. Responsive Web
  3. Mobile Onboarding Task

Maintaining three separate experiences was inefficient for our teams and confusing for customers. The team needed to reconcile these fragmented experiences into a single, modern solution. But it was difficult to know what to prioritize or how to unify the flows.




Project goals

  • Simplify the setup process
  • Improve understanding of various direct deposit states: pending, invalid, incomplete, etc.
  • Reduce errors


Process


Before jumping into wireframes, I used Object-Oriented UX (OOUX) to clarify the system's underlying structure. OOUX is a method for identifying and defining the real-world objects in a product before designing anything. With three fragmented versions of the same experience, I needed to establish shared language and a clear mental model before the team could meaningfully align on a direction.

Noun foraging
 I reviewed screenshots, documentation, and customer feedback to surface and sort every noun in the system. This revealed several opportunities to consolidate and clarify.


  • Paycheck and direct deposit felt synonymous, pointing to a need for clearer definitions
  • Both concepts relate to compensation, so we needed to incorporate that into our object definitions
  • Allocation, setup, and split were being used interchangeably, so we needed to consolidate terminology

Verifying objects
 With nouns sorted, I applied three questions to each candidate to determine whether it qualified as a core object: Does it have structure? Can instances be created of it? Does it serve a useful purpose?


  • Direct deposit and paper checks are the two forms a paycheck can take, making them attributes of the main object rather than objects themselves
  • Remaining balance is an attribute of the paycheck, not a standalone object

Defining objects
Each object also needed a clear, agreed-upon definition. This step forced precision and surfaced assumptions the team hadn't realized they were making.


Mapping relationships
With objects defined, I mapped how they connected to one another using a nested-object matrix and visual relationship maps.



  • Defining object relationships was the most challenging part of the process
  • Visual maps helped clarify the matrix and led to revisions in object definitions
  • This confirmed that object definitions sometimes need to evolve based on how relationships are mapped

CTAs & attributes
Brainstorming actions and attributes for each object surfaced a structural problem in the current experience: bank account attributes and CTAs were being exposed during the allocation step, where they didn't belong. Catching this before any UI was designed meant we could address it early.


Artifacts

With objects, relationships, CTAs, and attributes defined, I created object cards to serve as clear documentation for the team. 



I then used a shapeshifting exercise to imagine each object in different contexts: as a card, in a list, or as a detail page. This gave the team a concrete starting point for wireframing.




Outcomes

Although the project was deprioritized, the OOUX work laid a strong foundation that the team can build on when the initiative resumes. It clarified the system, aligned partners, and set a clear direction even without moving into high-fidelity design.

If the project restarts, I'd prioritize the following next steps:
  • Refine the documentation using the insights gathered.
  • Review the relationship map, object cards, and shapeshifting outputs with engineering to confirm feasibility and uncover gaps.
  • Translate core CTAs into object-oriented user stories.
  • Use the shapeshifting exercise as the starting point for early wireframes.