Using familial mental models for a WYSIWYG resume editor

1Template

Using familial mental models for a WYSIWYG resume editor

Designing a resume editor built on familiar document editing patterns (Google Docs, Word) that maintains a true WYSIWYG experience with pixel-accurate digital-to-print translation, bridging the gap between what users design and what they print.

FOCUS

Product Strategy and Design

AREA OF WORK

Productivity SaaS

ROLE

Product Strategist and Designer

PROBLEM

The rigidity of modern resume builders

Resume builders force users into restrictive, templated layouts while feeling unfamiliar and unintuitive. Meanwhile, the disconnect between digital design and printed output creates friction and uncertainty for users about their final resume quality. We wanted to create a resume editor that felt as flexible and familiar as Google Docs or Microsoft Word, staying as simple and intuitive as possible, whilst still supporting resume-specific structure, formatting, and optimisation.

1

Restrictive editors. Most resume builders feel restrictive, unintuitive, or overly templated, forcing users into rigid layouts that don't reflect how they naturally write or edit documents.

1

Restrictive editors. Most resume builders feel restrictive, unintuitive, or overly templated, forcing users into rigid layouts that don't reflect how they naturally write or edit documents.

2

Learning curves in new UI. Lack of familiarity with standard document editing patterns meant users had to learn a new interface instead of leveraging their existing mental models with tools like Google Docs

2

3

Uncertain digital-to-print. No guarantee that an editor could output to print accurately, creating friction between design and final output against certain guidelines and standards.

3

Uncertain digital-to-print. No guarantee that an editor could output to print accurately, creating friction between design and final output against certain guidelines and standards.

DESIGN APPROACH

Setting a foundation

We needed to established a scalable foundation in building the entire from scratch. We opted for a very iterative process, throwing around ideas, building out affinity maps all before establishing the core pieces of the editor. These included the emphasis of leverage existing mental models to build a true WYSIWYG editor, and to design a modular system for scalable features.

1

Design the experience around the familiar patterns seen in the likes of Google Docs and Microsoft Word to reduce onboarding friction and allow users to focus on writing and taking advantage of native features - not learning new interfaces.

1

2

Build a system for pixel-to-print translation by developing measurement libraries, DPI standards, and formulas for accurate margins, text sizing, and spacing.

2

Build a system for pixel-to-print translation by developing measurement libraries, DPI standards, and formulas for accurate margins, text sizing, and spacing.

3

Design modular, resume-specific features (guided improvements, AI writing assistance) that layer over the core editor without bloating the experience, all while being truly meaningful and providing value unseen in a typical word processor.

3

DESIGN DECISIONS

1

Unlike most resume builders, limit user input into modals or forms, and instead establish most input into the document and surrounding editing controls itself to maintain flexibility and familiarity.

1

Unlike most resume builders, limit user input into modals or forms, and instead establish most input into the document and surrounding editing controls itself to maintain flexibility and familiarity.

2

Establish technical accuracy (measurement blueprints, DPI conversions) early on and communicate with engineers and related libraries to ensure digital editor output matched real-world printing standards.

2

3

Modular features that may or may not appear in the future should still be noted and explored, including evolving existing ones over time rather than shipping everything at launch, allowing the product to scale without overwhelming users.

3

OUTCOMES

Measurable retention and rapid startup growth

1Template achieved over 1000 users within 3 months of launch with a 31% returning user rate, validating the core strategy of leveraging familiar mental models.

1000+

Users within 3 months of launch

31%

Returning users over a 6-month period

LEARNINGS

Learnings and Findings

Anchoring design in existing user mental models (Google Docs, Word) dramatically reduced onboarding friction, proving that users prioritise familiarity over novelty when editing important documents. However, more time could've been both saved and spent on better decisions from the beginning.

1

Leverage existing resources

For rapidly iterating products, leveraging an existing design system rather than building one from scratch would've accelerated development and reduced overhead costs and time.

1

Leverage existing resources

For rapidly iterating products, leveraging an existing design system rather than building one from scratch would've accelerated development and reduced overhead costs and time.

2

Establish foundations early-on

Spend time on the strong focus on scalable product workflows, clear documentation, and cross-functional collaboration strengthens both immediate execution and future iterations.

2

Establish foundations early-on

Spend time on the strong focus on scalable product workflows, clear documentation, and cross-functional collaboration strengthens both immediate execution and future iterations.

3

Focus on both UI and UX

Although an adequate amount of time was spent fine tuning the UX and designing features, not enough time was spent on ironing out the AI, and polishing out elements from a component level.

3

Focus on both UI and UX

Although an adequate amount of time was spent fine tuning the UX and designing features, not enough time was spent on ironing out the AI, and polishing out elements from a component level.