Email scheduling for dashboards
netlex CLM
My role
UX/UI Design, User Research, Wireframing, Prototyping, Technical Alignment with Engineering and PM
Team members:
Thais Muchon (Product Manager), João Lima (Tech Lead), Gustavo Souza (Developer)
Tools
Figma, Miro, Lovable
Email scheduling is the feature that lets netLex users receive their Intelligence dashboards automatically by email, on a recurring basis, without needing to log into the platform every time.
I led the design end-to-end: from research on how users shared dashboard data to the decision to expand scope beyond email, adding full dashboard expansion as a second delivery path. The result reduced a fully manual reporting process to a few clicks, tested and validated with real users before launch.
Project duration: 2 months
Challenge
Every time a user of netLex's data intelligence needed to share or present a data, the only way was manual. Login to the platform, load the dashboard, and take a screenshot every time.
The chart legends only showed complete when the user hovered over each column, one at a time. This hover was not captured in a screenshot. This made the process slow and open to error, especially in important presentations..
Research & Validation
Not a one-person decision
Design decisions did not come from one person alone. We ran validation cycles with three groups: managers and account admins, hands-on doers running day-to-day operations, and internal implementation users, who saw the client pain most closely.
Confirmed, not assumed
We cross-checked what these groups reported with internal data already recorded, to confirm the pain wasn't an isolated case.
This process revealed specific needs, documented during discovery:
Automate the delivery of reports and dashboards by email
View labels and legends complete and readable, without needing to hover
Same platform, different jobs to be done
Managers, doers, and implementers needed different things from the same dashboard
Managers and account admins: needed the full picture delivered automatically, without logging in, this became the email scheduling path.
Doer: the hands-on users actually running day-to-day operations, needed to check a chart fast, without building a full report, this became the single chart expansion.
Implementation team and internal users: used both paths, depending on whether they needed a quick check or a full report to share.
User Experience Flow
Before
After
After
Before
Usability testing with 5 stakeholders
Focused on the scheduling flow, to understand if users recognized the pattern, completed the setup alone, and where the friction appeared.
Fixed date rigidity
The first prototype only allowed scheduling by a fixed calendar date. The tests showed this did not cover the reality of many users: clients often work by period, like the 5th or 10th business day, not a fixed date.
Low friction, by design
Besides this point, the flow had low friction. The familiarity with netLex's existing alert, and with Monday's scheduling pattern, helped users recognize the pattern without needing an explanation.
Usability testing
"I think a specific period is as important as a fixed date. Sometimes client dates are set by the 5th business day, for example"
Internal stakeholder, during usability testing
Key Design Decisions
Expand dashboard
Sequencing saves rework
Email delivery was the goal, but we didn't build it in isolation. We aligned with the Tech Lead first: the dashboard expansion would be the foundation for email later. Delivering it first only worked because design and engineering planned the sequence together.
Expand the whole dashboard
Expanding the whole dashboard gave users full context at once, every chart visible and ready for a presentation, without navigating chart by chart.
Capture on demand, not the whole board
Hovering over a chart reveals a download icon in the top right corner, exporting that chart at presentation-ready resolution. Same interaction pattern used elsewhere in the product, letting users grab exactly what they need instead of exporting the entire dashboard as one file.
Key Design Decisions
Email Scheduling
Frequency with alternate days
Monthly scheduling used alternate days (01, 05, 10, 15, 20, 25, 31), based on user feedback and the pattern of other calendars, like Google Calendar. A conscious trade-off between simplicity and full coverage.
Familiarity as a usability shortcut
The flow was based on netLex's existing alert, using the company's design system, applying Jakob's Law.
Strategic direction, aligned with the PM: bring Intelligence closer to market benchmarks (Looker Studio, HubSpot, Monday), to make the product more competitive.
Technical export standards
Images in JPEG or PNG, minimum size of 1000 to 1200px, lossless compression on the backend, and responsive design on the frontend.
Real impact
Delivery success, distribution gap
Usability
Low friction in usability tests, no difficulty setting up recipient, subject, and frequency.
Timeline
Delivered within the quarter deadline, aligned with internal goals and market benchmarks.
Adoption after launch
Adoption stayed low in the first months. Usage was concentrated in a single company, responsible for half of all activity, a sign the feature worked well where it was discovered, but didn't have a formal release or active communication to the full user base. The gap was in distribution, not in usefulness.
Learnings
Launch communication is not an optional step in design
The low adoption number didn't come from the feature itself. It came from a structural problem: CS, implementation, and product didn't have an efficient channel to inform the user base about new releases. This was a pain point for every team, not just mine. In the following launches, we fixed this, and the company adopted a central release platform ("feature base") for all teams. Being part of the launch strategy is also design work, not just delivering the screen.
Reusing what already exists is also a design decision.
The familiarity with netLex's alert and with platforms like Monday reduced the users' learning curve.
A technical limit doesn't need to become an experience limit.
The switch from PDF to HTML was decided outside of design, but the care with readability made sure the user didn't feel that trade-off.