( 01 )
Business Context
Task Calendar was our way to make the platform essential to their daily work while helping them avoid serious legal mistakes. In the post-MVP phase, leadership demanded faster engagement growth to justify scaling investment.
( 02)
My Role
Solo UX designer on 4-month timeline with zero research budget and "yesterday" delivery pressure.
( 03 )
Impacts
For users:
Centralized scattered tasks across 5+ disconnected portals
Reduced compliance risk through visible, trackable deadlines
Created daily engagement touchpoint beyond urgent tasks
💬 "This helps me stay on top of deadlines and centralize everything I need to do"
For business:
Platform NPS: 66 (vs industry avg 30-40) — top quartile for B2B SaaS
Delivered strategic feature in 4 months under extreme deadline pressure
For design and team:
Established reusable template pattern adopted across 3 subsequent features
API solution freed 3 weeks engineering capacity for complex logic
Created collaboration model for compliance-constrained design work
( 04 )
The Core Problem
Surface request: Build a calendar feature to increase engagement.
Actual challenge: People managing millions in retirement savings (plan managers) were terrified of forgetting tasks with serious legal consequences. But the industry had spent decades building software for executives and auditors—not for the people actually doing the work.
Why existing tools failed them:
Executives who buy the software don't use it daily, so it's built to check legal boxes, not help people
Information lives in dozens of separate systems that don't talk to each other
Companies are too scared of legal risk to try anything new
Employees are stuck with whatever tools their company buys, so no one has pressure to improve
What users dealt with every day:
Tasks buried in emails, scattered across different websites, written on sticky notes. Constant worry about forgetting something important.
( 05 )
My Strategic Approach
What I inherited: A 3-year-old approved design showing both calendar events and task lists. PM said "build Events" based on ambiguous examples. I had doubts but no budget to validate.
My strategic bet: Created a rapid prototype with a simplified version fast to learn, not to be right.
( 06 )
Pushbacks and Alignments
Where stakeholders disagreed:
Product manager: "Build event scheduling (meetings, seminars)"
Me: "These feel more like action items to complete"
Legal team: "Can't let people type freely (privacy risk)"
Users: "We need to describe what our tasks are"
Engineers: "Building a calendar from scratch takes months"
How I got everyone aligned:
Step 1 — Let users prove my point
Rapid prototype with event-based calendar even though I had doubts
Users clearly rejected it, and I it as proof to challenge the original direction
Step 2 — Turned legal blocker into solution
Took legal constraint as a creative challenge
Found task patterns and created a menu system
Showed legal and product teams: "Pre-written choices = no privacy risk + users get clarity"
Step 3 — Made testing non-negotiable
No budget, but argued: "We already built the wrong thing once—can't do it again"
Ran quick sessions to check if the menu matched real work
Gave product manager confidence to support the change
Step 4 — Found engineering shortcut
Suggested using existing calendar tools instead of building from zero
Saved 3 weeks and let engineers work on harder problems
Engineers became supporters of the approach
( 07)
Key Decisions and Tradeoffs
First version needed to solve the core problem: give users visibility and peace of mind. Everything else could wait for real usage data.
Shipped:
Tasks menu (template system): 6 task categories, 8 subtopics (pattern-based)
Calendar views (list, day, week, month)
Mark complete, basic details
Clean, accessible interface
Deferred:
Priority levels (nice-to-have)
Status tracking (adds complexity)
Custom task creation (defeats compliance purpose)
Sorting/filtering (not critical initially)
External calendar integration (significant dev effort)
Tradeoffs: Total freedom for users
Why: The legal restriction revealed patterns of tasks menu (template system), which was actually clearer, safer, faster.
( 08 )
Outcome
Delivered on time in 4 months:
Menu-based task system that passed legal review and users confirmed worked
Calendar views showing time-sensitive responsibilities
Self-service design that could grow to include advisers later
What changed:
Users stopped worrying about forgetting things
Platform became part of daily routine, not just for emergencies
Legal team trusted design to solve compliance challenges
Design system got a reusable menu pattern
( 09 )
What I learned
Design with constraints: Legal's privacy rule felt like a wall. Using it as a creative challenge to find patterns led to the menu system, which was better than open typing (clearer, safer, faster).
Data-driven product strategies: When user testing rejected the original business logic and proved my doubt. I listened to feedback and used it to convince product partners to pivot product strategies.
Cross-functional alignment: Utilize real user data to align legal, writers, engineers, and product managers at each step
DISCOVER MORE
