Floating drawer or push drawer?

I was working on our internal case management system where staff review changes via a slide-in drawer. The pattern was standard, but the users kept making a specific request: "Can you make the background page scrollable when the drawer is open?"

They felt "stuck" when the drawer was active, indicating a severe break in their workflow. My investigation revealed that scrolling wasn't the root problem; it was the entire interaction model that was fundamentally flawed for a comparative task.

The power user persona

The staff in this system are expert users with specific needs that contradict standard consumer application design:

• Workspace: They typically use wide-screen desktop monitors, often running multiple screens side-by-side.
• Task: Their work involves cross-referencing—referring to multiple sources of information (the case data, external documents, etc.) simultaneously.
• Aesthetics: They appreciate dense information displays over white space. For them, efficiency is beauty, and unused screen real estate is wasted effort.

This persona immediately told me that any solution must be optimized for wide, simultaneous views.

The misleading request: Violating context

The original design used a floating overlay drawer. This pattern is successful when the secondary task is self-contained (e.g., viewing settings). However, the staff's task was review and annotation, requiring constant reference to the underlying case data.

I sat down to watch them work. The interaction cost was extremely high: they were constantly toggling the drawer on and off. They would perform an unnecessary three-step loop—read data, open drawer, close drawer—just to input one field, effectively doubling their interaction time.

They weren't trying to scroll; they were fighting to preserve their context. The standard overlay pattern violated the core principle of Direct Manipulation by physically blocking the information they needed to complete the task.

Moving from overlay to split-view

The interface was fighting the user's intent. The user needed a side-by-side comparative view (Source vs. Input), but the UI gave them a layered view (Input over Source).

I realised the solution was a layout change. The simple scroll fix would have been a poor design choice, as the blocked content would still require vertical scrolling, adding complexity without solving the visibility issue.

I scrapped the overlay and worked with engineering to implement a Push/Resize Interaction. This approach solves two problems:

1. Preservation: The main case data (the source) is never covered.
2. Efficiency: It requires only one initial click to access the review area.

Instead of floating, the drawer "squeezes" the main viewport. The content dynamically narrows, creating a true side-by-side view where 100% of the data remains visible and accessible.

Adaptive design: Optimizing for density

Since our staff uses a mix of laptop screens and wide monitors, a fixed-width sidebar was too restrictive. The ideal width for the review panel changes based on both the user's screen size and the length of the remarks they need to write.

To achieve fluid data density, we added a draggable handle. This allows users to:

• Widen the panel when writing long notes in the review field.
• Narrow the panel when they need to see more columns in the source table behind it.

The takeaway: Fixing the root cause

Users often ask for features that fix the symptom ("make it scrollable"), not the root cause. If I had just enabled scrolling, the fundamental visibility problem would have remained, resulting in a slightly faster but still flawed workflow.

This project reinforced that true UX value lies in observing the workflow, diagnosing the underlying structural conflict, and implementing a change that eliminates unnecessary steps for the user.