SUMMER INTERNSHIP | 2026
Redesigning Pulselake AI from Business Intent to an AI Product Experience
During this summer, I worked on translating Pulselake's business ambition into a clearer product experience helping researchers understand the platform's value, discover its capabilities and navigate their research journey from study creation to generating insights.
Market Research
Product Thinking
B2B SaaS
Conversational UX
Intuitive for first-time users
Enhanced Feature Discoverability
Where research grows and insight flows.
Role
UX Researcher & Product Designer
Overview
Platform
B2B SaaS
AI Native Research OS
2 Months
Simplify research workflows for first-time users through Onboarding, AI Study Creation & Contextual Learning.
Tools
Figma
Lovable AI
Balsamiq
ProtoPie
Team
FOUNDER & MENTOR
Venkat Chandra
CTO
Riddhi
Product Deployment Engineer
Rishikesh
Timeline
UNDERSTANDING PULSELAKE
PulseLake is an AI Native Research Operating System designed to help in managing the research lifecycle from study creation and participant management to analysis and insight generation.
WHAT PROBLEM DOES PULSELAKE SOLVE?
PulseLake solves the fragmentation and inefficiency of market research by turning complex research workflows into actionable business intelligence, faster.
Study Creation
Panel Management
Analysis
Reporting
AI Assistance
PULSELAKE AI
USERS
Insight Professionals & Market Researchers
PROPOSED EXPERIENCE / Research-oriented navigation, visible starting routes and Pulsebot in context. Design concept; implementation and impact are not verified.
On smaller screens, scroll product images sideways to inspect interface details.
THE BUSINESS GOAL
The brief began with signups.
The founder wanted to increase website signups. Understanding the business ambition established the starting point—not a predetermined dashboard solution.
Increase website signups.
Founder’s stated objective · supplied project brief · no conversion baseline or results supplied
DEFINING THE EXPERIENCE PROBLEM
The brief changed as I explored.
Study-creation complexity emerged as a separate product problem. This expanded the design focus without establishing a causal link to signup performance.
01 BUSINESS INTENT / Increase website signups
02 INVESTIGATION / Explore website and product
03 PRODUCT PROBLEM / Study creation was complex
04 DESIGN FOCUS / Make getting started clearer
A change in design focus—not proof that study-creation complexity caused low signup rates.
AUDITING THE EXISTING EXPERIENCE
First, look at what researchers encountered.
The original screens mix platform-level operations with research tasks. These captures are the baseline for the audit—not the redesigned experience.
E03 / ORIGINAL DASHBOARD · Data Ops mode. The visible task cards concern factories, data, catalogues and governance. This capture is not a research-specific home state.
E01 / ORIGINAL STUDY CREATION · About, Questions & Structure, Study Experience and Share & Launch are visible stages. The initial screen starts with study information and configuration.
E05 / ORIGINAL SETUP CHOICE · Guided Assessment Templates and Flexible Form-Based Projects are the two visible starting paths. This is existing-product evidence, not the proposed AI / blank / template dashboard.
E04 / EXPERIENCE OPS · ① Multiple navigation groups ② Nested category and filter controls ③ Create Study appears on individual templates. Observed structure; difficulty is a hypothesis to test.
SOURCE GAP / An original website capture is not available in this project. Website recommendations are strategic proposals, not a screenshot-verified website audit.
05 / HEURISTIC EVALUATION
Evaluate the evidence, not assumptions.
A screenshot-based review using Nielsen’s ten heuristics. Observations below are design assessments, not usability-test findings. Severity is not scored without task and frequency evidence.
01 Visibility of System Status
E01: four named study stages and an active About tab provide orientation. Save confirmation, processing and launch feedback need further inspection.
Opportunity: preserve stage visibility and verify completion feedback.
02 Match Between System and the Real World
E04: “Research Survey Stacks”, apps and project types coexist with Create Study. This asks researchers to interpret platform terminology.
Implication: the next research action may need translation. Response R1: use research-oriented labels and routes.
03 User Control and Freedom
E05–E06: a close control and a Back action are visible. Whether input survives exit or backtracking is unknown.
Needs further inspection: draft persistence, undo and safe exit.
04 Consistency and Standards
E04–E05: Create new template, Create Study and project setup describe different actions. Their relationship is not explained in these captures.
Implication: users may struggle to distinguish a reusable template from a live study. Opportunity: clarify object and action labels.
05 Error Prevention
E01–E02: required fields and a locked project type are visible. Validation timing and invalid-input handling are not captured.
Needs further inspection: field validation, destructive actions and launch checks.
06 Recognition Rather Than Recall
E05–E06: descriptions explain guided versus flexible routes and the available methodologies. These are existing recognition aids.
Opportunity: carry route guidance into the new entry point; do not remove useful context.
07 Flexibility and Efficiency of Use
E04: Import, search and filters are visible. E05 offers two setup paths. Their effectiveness cannot be established from static images.
Needs further inspection: novice versus repeat-user tasks and keyboard access.
08 Aesthetic and Minimalist Design
E02: basics, metadata, purpose, impact and values share the About stage. E04 combines several navigation and filtering levels.
Implication: initial setup may compete with secondary detail. Response R2: make essential decisions and the next action prominent.
09 Help Users Recognise, Diagnose, and Recover from Errors
No error state is supplied. Absence of an error message in a screenshot is not evidence that recovery is missing.
Needs further inspection: error wording, field associations and recovery paths.
10 Help and Documentation
E01–E02 contain inline guidance; E04 exposes Learn More. A persistent feedback tab is also visible.
Needs further inspection: whether help answers research questions at the moment of need. Response R3: explore contextual Pulsebot guidance.
06 / MAPPING THE PROBLEMS
Three issues. A visible trail to each response.
Issue IDs connect the original interface, the likely user implication and the proposed response. Priorities remain unscored pending task-based review.
P1
P1
P1 / Navigation and category terminology. P2 is evidenced in the About form (E01–E02). P3 concerns the proposed AI handoff, not an observed defect in this original screen.
P1 / Terminology & navigation
Evidence E04 · Heuristics 2, 4
OBSERVED: study templates sit among platform and administration groups.
IMPLICATION: researchers may need to learn the platform before identifying their task.
R1 / Organise around research tasks; D01 exposes Projects, Studies, Participants and Insights.
P2 / Setup information load
Evidence E01–E02 · Heuristic 8
OBSERVED: the About stage contains study basics, metadata and several long-form context fields.
IMPLICATION: the first action may feel like configuration before research.
R2 / Present starting routes and lifecycle guidance before setup. D01 shows AI, blank and template choices; progressive disclosure remains a proposal.
P3 / Assistance without visible handoff
Evidence D01 and supplied flow documentation · Heuristic 10
OBSERVED: the concept promotes Build with AI and Ask Pulsebot; the standalone conversation is not available at full resolution.
IMPLICATION: users need to know how generated output will be inspected and changed.
R3 / Make researcher review explicit in the proposed AI route. Approval and editing controls require screen verification.
07 / FROM FINDINGS TO DESIGN DECISIONS
Make the reasoning visible.
The design shifts emphasis from navigating a broad platform to understanding and starting research. Each response is a proposal, not a measured result.
R1 / Speak the researcher’s language
Platform terminology / interpretation burden / task-first organisation / research-oriented navigation.
R2 / Orient before asking for configuration
Long About stage / possible setup burden / reveal a clear first action / AI, blank study and template entry routes.
R3 / Keep AI accountable to the researcher
Prominent AI entry points / unclear downstream control / assistance with human judgement / proposed clarification, review and refinement loop.
08 / REDESIGNING THE DASHBOARD
From platform operations to research orientation.
The proposed dashboard makes the research lifecycle visible, brings starting routes to the surface and gives AI an explicit place in the workspace.
BEFORE / E03 · Platform operations in Data Ops mode. This is a directional comparison, not a matched research-state usability test.
PROPOSED / D01 · ① Research lifecycle explains the whole ② AI, blank study and templates provide visible starting choices ③ Ask Pulsebot and the sidebar expose AI assistance. These are visible design intentions, not validated improvements.
Establishing a design system
The proposed design system unifies all the
09 / RETHINKING THE RESEARCH JOURNEY
A clearer start—not an unverified shortcut.
The existing journey is reconstructed from captured states. The proposed routes combine the dashboard concept with supplied flow documentation. Dashed boundaries identify steps that still need screen-level verification.
EXISTING / Captured states
Start / Research template listing · E04
Create Study on a template · E04
Setup path? · E05
Guided assessment / Flexible form-based project · E05
Guided route: choose methodology · E06
Transition to study setup / not captured
About · E01–E02: name, summary, locked project type, measure, description and context
Questions & Structure / Study Experience / Share & Launch · stage labels visible in E01
End / Launch interaction and confirmation not captured
PROPOSED / Design documentation
Start / Research-oriented home · D01
How to begin?
Build with AI / Blank Study / Browse Templates · D01
AI route: enter research goal; Pulsebot clarifies intent · supplied flow document
Goal clear?
No: clarify / Yes: generate hypothesis and methodology · documented proposal
Researcher reviews; edit or refine if needed · documented proposal
Other routes: choose and adapt template, or name blank study and add questions · documented proposal
End / Proposed study draft; downstream review and launch controls need verification
FLOW KEY / Rounded = boundary · Rectangle = action or captured state · Diamond = decision · Dashed = unverified. Arrows indicate narrative order; captures do not establish every transition. No reduction in steps or time is claimed.
ENTRY / Existing: template-centric listing. Proposed: explicit starting routes on home.
DECISIONS / Existing: guided versus flexible setup. Proposed: AI, blank or template according to intent.
GUIDANCE / Existing: methodology descriptions and inline form help. Proposed: lifecycle orientation plus first-action guidance.
AI & CONTROL / Existing: AI Co-Pilot navigation is visible; behaviour unknown. Proposed: goal clarification and a researcher review loop in flow documentation.
REVIEW / LAUNCH / Existing: Share & Launch is a visible stage label. Proposed: no complete launch screen supplied. Both require further inspection.
Three routes. The researcher chooses.
Expanded proposed task flows / reconstructed from supplied flow documentation, not implemented interactions. Each route is independent; researchers do not complete all three in sequence.
AI-assisted route
Researcher: describe the research goal
Pulsebot: clarify intent; if unclear, return to the goal
System: propose hypothesis and methodology
Researcher: inspect and refine; if unsuitable, return to editing
Draft study · screen-level controls unverified
Template route
Researcher: browse templates
Researcher: filter by goal and choose a template
Decision: use as-is or edit questions
Researcher: adapt and review the study
Draft study · downstream launch unverified
Blank study route
Researcher: start a blank study
Researcher: name the study
Researcher: add questions and structure
Optional: seek AI help · documented proposal
Draft study · downstream launch unverified
10 / CONNECTING BRAND, WEBSITE AND PRODUCT
A research partner, not a collection of tools.
The website explains the promise. The product helps researchers begin. Pulsebot should support that continuity without taking ownership of research judgement.
Your Research & Growth Partner.
BRAND / Pulse motif and partnership proposition
WEBSITE / Explain the research value before asking for signup
ONBOARDING / Orient the researcher and reveal the first action
PRODUCT / Choose a route, shape a study, keep judgement with the researcher
Strategic experience map · not a measured conversion funnel
Pulsebot: assistance with accountability
AI should help researchers move through complex work, while keeping them in control of decisions.
RESEARCHER / Defines the research goal and context
PULSEBOT / Clarifies intent and proposes a study approach
RESEARCHER / Inspects, questions and refines the proposal
Documented proposal / D01 visibly promotes goal-led creation, suggested questions and methodology recommendations. The supplied flow document adds clarification and review. Conversation details, approval controls and bias checks are not verified.
Information architecture as a research journey
Discover: home, templates, examples · Research: projects, studies, interviews · Manage: participants and collection · Knowledge: repository, reports, insights · Support: learning and settings. This intent-based grouping is a documented exploration; the dashboard concept retains familiar destination labels.
11 / REFLECTION AND LEARNINGS
Investigate the brief. Then design the system.
The most important shift was recognising that a signup objective and a study-creation problem were related areas of work, not the same problem. The response connects communication, navigation and research support.
Design contribution—not a conversion claim.
The work establishes a clearer relationship between the promise, the first research action and AI support. Signup impact, task completion, time savings and implementation status were not measured in the supplied evidence.
Next validation: test first-study creation with researchers; inspect error and recovery states; verify AI review controls; measure the website signup funnel separately.
Source-of-truth asset inventory
Six original product captures preserved outside the canvas; one proposed dashboard; seven supplied documentation screenshots. Original interface evidence and design explorations are deliberately kept separate.
E01 / Original study creation — first viewport · Original source
E02 / Original About stage — full form · Original source
E03 / Original Data Ops dashboard · Original source
E04 / Original research template listing · Original source
E05 / Original setup-path chooser · Original source
E06 / Original guided methodology chooser · Original source
D01 / Proposed research dashboard · Proposed concept
MISSING / Original website; complete screen-to-screen recording; full-resolution standalone Pulsebot and study-builder screens; test evidence; signup metrics. Competitor positioning remains an unverified exploration and is not reproduced as market evidence.
REFERENCES / Navira — narrative progression from context to decisions and learning. Desqworx — existing interface, issue explanation and navigation rationale. Both public articles were accessible; this case study uses original Pulselake content.