How to Turn Complex B2B Features into Clear Visual Interfaces

1. Understanding the Function

The first step is to grasp the usage scenario and purpose of the feature; in this case, a data‑analysis service that filters a large backend database and presents the result as a table.

Reviewing the prototype reveals three main buttons—"Generate Table", "Preview", and "Apply Conditions"—and a flat visual structure. The workflow is: select indicators, sort them, generate the table, then apply filter conditions before exporting.

2. Structure Organization

2.1 Decompose and Re‑assemble Functions

Start by optimizing the overall structure to make functional zones clearer. The original layout splits configuration items across the left sidebar (indicators), top area (sorting), and right sidebar (filter conditions), which wastes space and forces users to click back and forth.

The page can be reorganized into two major parts: configuration and data display. Common interaction patterns for configuration pages include:

Two‑step: configure first, then generate.

Modal overlay: use a dialog or drawer for configuration.

Non‑modal: place configuration controls in a toolbar or drawer.

For this scenario, a non‑modal drawer works best because it keeps configuration visible without consuming extra space.

2.2 Solution Comparison Test

Three layout proposals were evaluated:

Option 1: Indicators in one column, filter conditions in another, with a tab to toggle all/selected indicators.

Option 2: Same as Option 1 but with all indicators and selected indicators stacked vertically.

Option 3: All indicators occupy one column, while selected indicators and filter conditions share another column.

Option 3 was chosen because users rarely add filter conditions, so a separate column is unnecessary, and the layout intuitively separates "library" from "items to apply", providing clearer mental cues.

2.3 Optimizing Filter Condition Structure

Key improvements:

Place new functions at the top to keep them visible.

Expose condition relationship settings directly, reducing clicks without consuming extra space.

Add condition cards for better readability.

3. Visual Design Construction

3.1 Background Color for Content Elements

Display content and forms on white cards. Most base components are designed for white backgrounds; using other colors can cause readability issues, especially for disabled states or label colors that blend with the background.

3.2 Shadows and Outlines

Shadows are common visual separators, but B‑end users often have low‑resolution monitors, making light shadows look blurry. Outlines are more reliable for separating elements.

3.3 Readability vs. Complexity

While skeuomorphic designs add visual richness, they can increase complexity. In high‑speed operation contexts (e.g., checkout kiosks), skeuomorphism can aid muscle memory, but balance is needed based on user tasks.

3.4 Number of Functional Colors

Use colors sparingly to convey status (warning, success, etc.). Overusing colors confuses users; group similar states and assign a single color palette. For audit statuses, consider adding icons to differentiate intermediate states.

3.5 Avoid Over‑Flattening

Excessive flattening reduces hierarchical perception, making content cramped. When unavoidable, highlight top‑level content or provide dynamic cues (e.g., hover highlights) to indicate focus.

3.6 Data and Hints

Use real field content: Obtain sample data from product or engineering to ensure visual fidelity.

Default values for form items: Pre‑fill common configurations to speed up entry.

Hint information: Show hints only for less‑common or complex functions; omit for frequent actions.

3.7 Final Data‑Analysis Page

The final design emphasizes functional visibility and ease of use rather than strict adherence to generic UI guidelines.

4. Schedule Management and Development Coordination

4.1 Planning by Requirement Form

Before design, create a task form based on the PRD to outline the functional scope. For urgent requests, split modules and deliver incrementally. Use a module schedule to assess impact of unexpected optimizations on overall timeline.

4.2 Deliver Core Pages First

Provide key pages to product and business stakeholders early to align expectations and reduce rework. Sketches can be used to validate feasibility before heavy design investment.

4.3 Component and State Management

Even a single B‑end page may involve many panels, dialogs, and component states. Agree with developers on reusable components versus custom ones early, so that implementation can proceed without waiting for visual details.

5. Preliminary Debugging

5.1 "Rubber Duck" Debugging for Designers

Explain the interface and design decisions to an imagined listener (or a rubber duck) to uncover unclear or problematic elements.

5.2 Walk Through User Flows

After confirming functional completeness, test user flows for issues such as unclear entry points, missing actions, or error handling. Provide guidance or a help center for unresolved problems.

Conclusion

B‑end products often have extensive documentation and training, but their complex interactions can be hard to remember. Simply following a prototype does not guarantee usability. Designers must translate product logic into clear pages and graphics to smooth the user experience.