Summary
Clients depended on Intechsol to create custom reports. When deadlines could not accommodate the wait, they exported several reports and merged information in spreadsheets.
Over four months, I designed a self-service reporting experience combining templates and guided setup with a flexible editor. Users could select relevant data, apply filters and sorting, and preview reports as they worked.
My role and Team
I was the sole designer, responsible for user research, field organization, interaction and visual design, prototyping, and usability testing. I partnered with the owner on requirements and direction and two developers on feasibility and implementation.
My contribution was research and experience design; technical implementation was a team effort. This initiative was part of, but distinct from, the broader Elysium transformation.
Problem, Context & Constraints
The data existed. Getting the right report still required help.
Managers, HR teams, and payroll staff requested custom reports when existing options did not answer their questions. Requests involved support calls, clarification meetings, developer assignment, and repeated client reviews.
Under deadline pressure, clients exported two or three reports and merged data in a new spreadsheet. Internally, similar reports accumulated without a clear inventory. Support struggled with versions, and developers updated individual reports when new data needed inclusion.
The experience had to make enterprise data understandable without database expertise, while working within the existing platform and component constraints. Flexibility could not depend on users understanding data relationships or aggregation levels.
Goals & Success Criteria
Enable independent report creation
The design goal was to let nontechnical users build useful reports from existing platform data without waiting for another custom report. Users needed an understandable starting point and control over content, filters, sorting, and structure.
Evaluation tracked task completion, task time, critical errors, and usability. The recorded scorecard included completion above 85%, standard-report task time below six minutes, and near-zero critical errors. These are documented evaluation criteria, not a claim they were all set at project kickoff.
Reducing dependence on the internal reporting team was a core goal, alongside making report creation understandable for nontechnical users.
Understanding the Users
Different responsibilities, shared reporting needs
HR professionals needed workforce information; payroll managers worked with payroll and time-related data; supervisors needed information relevant to their teams. Their needs extended beyond the available fixed reports.
I analyzed support tickets and met with clients to understand requirements and workarounds. A concrete behavior was combining report exports when custom development could not meet a deadline.
Activity | Participants | Purpose |
|---|---|---|
Initial evaluation | 3 HR, 4 payroll managers, 2 supervisors | Identify report-building difficulties |
Field-classification card sort | 30 participants | Inform field organization |
Follow-up evaluation | 10 HR, 15 payroll managers, 5 supervisors | Evaluate the revised wizard and editor |
Some participants returned between testing rounds; the activity counts are not a total of unique people.
Personas
HR PROFESSIONAL
Camila Reyes
HR Generalist
Needs flexible workforce information to answer changing questions about headcount, employee records, and organizational trends.
GOALS
Build workforce reports independently, select relevant employee fields, and share clear information with stakeholders.
FRUSTRATIONS
Fixed reports omit needed fields. Combining exports creates manual work, and custom development cannot always meet deadlines.
BEHAVIORS
Starts with a workforce question, combines employee fields, previews results, and refines filters before sharing.
TECH COMFORT
Web tools
Reporting
Configuration
“I know what workforce information I need. I just need a way to bring it together.”
PAYROLL MANAGER
Adrian Cole
Payroll Manager
Works with payroll and time-related data, often needing a different combination of fields for each pay period or review.
GOALS
Compare payroll and time data, isolate exceptions, and create reusable reports without waiting for development.
FRUSTRATIONS
Separate exports require reconciliation, while rigid reports make it difficult to investigate specific payroll questions.
BEHAVIORS
Checks pay-period filters, selects earnings and time fields, verifies totals, and reuses report configurations.
TECH COMFORT
Web tools
Reporting
Configuration
“Let me choose the payroll and time data I need, then check the results before I share them.”
SUPERVISOR
Maya Patel
Team Supervisor
Needs information relevant to the team to support staffing and day-to-day decisions without working through organization-wide reports.
GOALS
Quickly find team-specific information, narrow results to relevant employees, and share focused reports.
FRUSTRATIONS
Broad reports contain irrelevant records, and waiting for a custom report delays decisions about the team.
BEHAVIORS
Filters to the team first, chooses a small set of useful fields, and reviews the output before acting.
TECH COMFORT
Web tools
Reporting
Configuration
“Give me the information for my team, without making me sort through everyone else’s.”
Research Insights
Access to fields was not enough
These findings supported guided entry, clearer data meaning, and visible configuration. The card sort informed field classification.
Prioritization and Scope
Focus on usable self-service
The confirmed scope covered starting a report, choosing compatible data, filtering and sorting, organizing content, live preview, and preparing outputs.
The case study groups decisions around helping users start, interpret data, and reuse/distribute reports. These are narrative themes, not a claim about historical release order.
Impact vs effort matrix
A qualitative view of likely user value and implementation effort, based on this case study. These are suggested priorities, not measured scores or a record of the original release order.
Impact / Effort | Lower effort | Higher effort |
|---|---|---|
Higher impact | Quick wins: Make applied filters and sorting visible; add relative-date presets. | Major investments: Provide templates, guided setup, compatible data selection, and live preview. |
Lower impact | Nice to have: Polish report-editor details that do not affect task completion. | Deprioritize: Expose user-configured database joins beyond the supported data relationships. |
Information Architecture and Key Flows
Guided setup leads into detailed editing
Users could choose a template or start a custom report through three steps:
Choose Subject → Select Columns → Add Filters → Report Editor
The wizard introduced initial decisions and then opened the full editor. It did not replace it.
The editor supported report naming and description, categorized field selection, drag-and-drop columns, filters, sorting, and a live data preview. Timecard and payroll data used distinct source categories. Curated relationships exposed compatible data without requiring users to configure joins.
Exploration and Design Decisions
Guide the start without removing flexibility
Testing and Iteration
Revise around observed difficulties
After implementing changes, we evaluated the revised wizard and editor with 30 users, including returning participants. Comparable tasks and assistance rules were used.
Completion reflects successful task attempts, not the percentage of participants completing everything. Different groups mean this was not a matched-participant experiment.
Final Experience
A guided beginning and a flexible working surface
The implemented experience combined templates or guided setup with categorized fields, drag-and-drop columns, naming/description, filters, sorting, and live preview. Relative dates supported reusable periods; grouping and report-wide information supported clearer structure.
A dedicated layout preview exposed page breaks, headers, footers, and orientation before PDF generation. Formatted Excel exports preserved data types, currency formatting, and formulas rather than producing only flat, unstyled data.
Implementation & Delivery
Translate design decisions into working behavior
I worked with the owner and two developers over four months, including testing. My responsibilities centered on research and design; development implemented the interface behavior, curated data relationships, and export capabilities.
The described changes were implemented, and follow-up evaluation tested the revised wizard and editor in a testing environment. This establishes more than a proposed concept, but does not by itself establish production adoption or reduced support demand.
Impact & Evidence
From waiting for answers to creating them
CYOR removed the custom-report request cycle for the vast majority of client reporting needs. Instead of waiting days for a report to be built and delivered, clients could produce it themselves in minutes.
That independence changed both sides of the workflow. Clients gained direct control over how they assembled and used their data, while the internal team previously handling report requests could focus on higher-value work.
The feature did more than improve report creation: it shifted control from a service queue to the people who needed the information.
Reflection & Next Steps
Flexibility needs interpretation
Access to data is not enough. Users need to know where to begin, what fields represent, and how choices affect the report. Templates, guided setup, clear categories, and visible configuration addressed different parts of that problem without removing flexibility.
A useful next step would be to connect usability evaluation with post-launch evidence: whether users independently create recurring reports and whether custom-report requests decline. This is a proposed next step, not a measured outcome.
Part of Elysium at Intechsol. This case study covers the four-month reporting initiative, not the full eight-year platform transformation.
