How to Tame Project Uncertainties with Proactive Frontend Collaboration

Project Variables in Parallel Development

When product, visual design, and frontend teams work on tight, multi‑track schedules, specifications are often incomplete. This creates "project variables" such as undefined global components, unclear module management, and missing design resolutions, which can cause rework and delays.

Proactive Information Gathering

Key data to collect at project kickoff:

Overall information architecture and channel layout of the existing site.

Full timeline, including visual delivery dates, handoff deadlines, and frontend development cycles.

Contact points for each discipline (product, interaction, visual, backend).

By reviewing the legacy site’s channel hierarchy and product logic, the team identified reusable components (e.g., side‑navigation overlays) before the new visual assets were complete. This allowed early estimation of effort and selection of optimal implementation approaches.

Detecting Hidden Variables

Some variables are not obvious until later. In the JD Cloud redesign the initial design files were provided only at a 1280 px width, while the market‑significant 1024 px resolution was missing. Early confirmation of the need for a 1024 px version prevented later emergency adaptations, which would have required additional frontend and visual work and could have caused overtime or project delay.

Embedding frontend engineers in the early product, interaction, visual, and backend discussions enables detection of such incompatibilities (e.g., resolution, color depth, retina support) before development begins.

Standardizing Icon Management with Iconfont

The homepage contained dozens of monochrome icons that were reused across modules, required multiple sizes, and needed retina‑ready rendering. Different teams used inconsistent methods:

Some developers created custom iconfonts manually.

Others asked designers to supply SVGs and used online converters.

In some cases designers generated the iconfont themselves.

To unify the workflow, the following process was adopted:

Designers deliver clean SVG files for each icon.

Frontend engineers run an SVG‑to‑iconfont conversion tool (e.g., iconfont-cli or an online service) to generate a single font file and accompanying CSS.

The generated font is version‑controlled in the project repository and referenced by CSS classes.

If any glyph displays incorrectly on Windows, the designer refines the SVG in Illustrator before regeneration.

This approach yields:

Vector scalability and automatic retina support.

Reduced asset count (one font instead of dozens of PNG/SVG files).

Consistent styling via CSS (size, color, hover effects).

Simplified maintenance when adding new icons or states.

Five team members completed the redesign using this unified iconfont pipeline, eliminating duplicated assets and cutting the icon‑handling effort dramatically.

Key Practices

Identify and document potential project variables early, especially hidden ones like resolution requirements.

Quantify the impact of proposed solutions (e.g., time saved by using iconfont) to secure stakeholder agreement.

Involve frontend engineers in cross‑team discussions from the outset to surface technical constraints.

Standardize reusable technical solutions (iconfont, component libraries) to improve consistency and reduce rework.