Supporting material
Research and design decisions
This archive explains the evidence I used, the decisions it informed and the questions I would investigate before release.
Evidence & sources
I used the assignment brief, my own walkthrough, informal views shared by close friends and family, and public product information to shape the proposal. The informal conversations helped me identify questions to investigate, rather than establish findings about the wider audience.
01 · Assignment and survey
Source: Updated 'Assignment – Product Design (1).pdf'. Read the supplied brief (PDF).
What it establishes: Paid Indian-stock smallcase profile scope; success is subscription purchased through the profile; constituent visibility is gated until subscription. Survey reasons for visiting but not investing: theme/strategy 33%, returns after costs 25%, timing 23%, process 17%.
What it points to: Theme explanation, cost clarity, process clarity and a distinction between hesitation caused by information and a valid decision to wait.
Limit: The brief does not provide the sample size, dates or paid/free composition. I therefore use the figures to prioritise questions, not diagnose subscription abandonment or describe a complete distribution.
02 · Product structure and theme
Source: Green Energy Theme profile.
What it establishes: The public profile describes the renewable-energy thesis across the value chain, with methodology, factsheet, performance and costs entry points.
Design implication: I structured the theme around its investment approach and retained routes into detailed evidence so investors can evaluate more than the theme label.
Limit: The public page is dynamic. Minimum investment and visible states can change; the prototype is a dated illustration, not a current offer.
03 · Manager evidence
Sources: Niveshaay on smallcase and Niveshaay about page.
What they establish: The sources describe the firm, people, investment approach and history. The smallcase manager page explicitly describes separate subscriptions for fee-based smallcases.
Design implication: I separated career experience, firm history and portfolio performance so each claim can be understood on its own.
Limit: These are provider-authored claims rather than independent validation. The sources contain different registration and role descriptions, so I would verify the relevant entity and current details before release; registration is not evidence of future performance.
04 · Performance, rebalances and costs
Source: smallcase return-calculation methodology.
What it establishes: Displayed model performance incorporates rebalances, but transaction fees and related costs are not included. Model returns are not a customer's realised return.
Design implication: I made the calculation basis and exclusions visible beside the illustration. The rebalance timeline explains portfolio changes without attributing later gains to an individual rebalance.
Limit: An illustrative chart cannot establish investment outcomes, guarantee future returns or show that a specific rebalance caused an uplift.
05 · Walkthrough and design record
Sources: Earlier and current design screens, the Figma exploration page, and the runnable prototype. The comparison directions are a design exploration, not a demonstrated winner.
What it establishes: The visible states explored and the design decisions made during this assignment.
Design implication: The earlier and current screens show how I revised the hierarchy and interactions as I worked through the journey.
Limit: This is a design and self-review record, not evidence of customer adoption or usability-test findings.
06 · What I would investigate next
I would review the actual profile-to-subscription journey, clarify the survey sample and compare support questions with task-based comprehension findings. I would also verify current data and terms, then test whether the comparison alternatives help people decide or introduce more uncertainty. Those findings could change the proposal.
Public product information can change, so the details shown here would need to be checked again before implementation.
A flow assumption to validate
I retained separate subscription and investment steps because I had not established whether they could be combined within the product’s operating constraints. This is an assumption to validate, not a confirmed platform limitation.
If the product, broker and compliance constraints permit a combined subscribe-and-invest flow, I would explore it as an alternative that could reduce steps and help retain intent. Its effect on completion, understanding and consent would need to be tested. The current prototype continues to keep the two actions separate.
The two comparison explorations
A · Inline in the Overview
The earlier implemented design shows the full comparison table beneath the amount planner. This supports scanning in place but adds length and information to the profile.
B · Open comparison on demand
The current design uses a compact entry immediately after Performance and opens the table in a sheet. This keeps the Overview focused, at the cost of another discovery and navigation step.
For a fair A/B test, I would put both treatments on the same profile while keeping portfolios, fees, data and checkout consistent. The archived versions contain other differences, so comparing those whole versions would not isolate comparison placement.
Before a live test, I would vary the order in which people see the treatments and ask them to explain the differences and decide how to proceed. I would assess understanding and task completion alongside their preferences. Comparing A and B identifies a treatment; I would then compare that treatment with the same profile without comparison to establish the feature’s overall value.
How I would measure the design
Behaviour: what happened?
- Overview: Theme detail discovery, onward movement to manager/cost, repeated tab switching and relevant task completion.
- Manager: Evidence/detail opens and movement back into evaluation. Dwell time alone can mean interest or confusion.
- Costs: Amount changes, fee-detail opens, calculation errors and checkout transitions. A decision not to pay is not necessarily failure when cost clarity reveals poor fit.
- Comparison: Exposure, opening, alternatives reviewed, choice, switching and final subscription. I would include all assigned eligible users in the primary analysis, including those who did not open comparison.
- Portfolio: Successful discovery of rebalance history, interpretation of holdings/weights and movement towards the next investment step.
- Updates: Toggle changes, update opens and opt-outs. Neither opens nor opt-ins alone establish usefulness.
- Ask AI: Question category, unresolved answers, source opens, clarification requests and repeated questions. I would use these signals to identify missing information before deciding whether the page or the assistant needs to change.
Survey and task checks: what did people understand?
I would ask a small sample of people who subscribed and people who did not a few questions after the relevant task, rather than interrupt every screen with a long survey.
- Theme comprehension: 'In your own words, what does this smallcase invest in, and what is one risk you would consider?' I would use agreed scoring criteria to measure how many people accurately identify the theme and a relevant risk.
- Commitment comprehension: 'What does this payment give you access to?' The answer choices would distinguish research access, stocks purchased, platform-wide access and uncertainty, so the measure reflects understanding rather than confidence alone.
- Cost comprehension: 'Which costs are included in the return shown here, and which would you still need to consider?' I would score answers against the costs and terms actually shown.
- Task ease: 'How easy or difficult was it to find what you needed to decide?' I would use the same 1–7 scale for both versions.
- Decision confidence: 'How confident are you that you understand what you would be subscribing to?' A 1–5 confidence score would be interpreted alongside comprehension rather than on its own.
- Unresolved friction: 'What, if anything, is still stopping you from deciding?' People could choose several reasons or write their own, including cost, suitability, timing, missing information, process or no remaining concern.
- Comparison usefulness: 'What difference between these options mattered to your decision?' I would check whether people recall a meaningful distinction beyond the headline return.
- Answer usefulness: After Ask AI, 'Did this answer your question?' Yes / partly / no, with an optional reason. I would review accuracy separately because a reassuring but incorrect answer could still receive a positive rating.
I would report who responded and the response rate, while keeping the questions consistent across versions. Because respondents are self-selected, I would interpret their answers alongside observed behaviour and follow-up conversations rather than treat percentages as proof of causation.
Ask AI: scope and future direction
For this exercise, Ask AI is limited to the paid profile. I have not explored the rest of the app in enough depth to establish where a universal assistant would be useful, so I have not extended the proposal across the product.
If research across other journeys identifies a recurring need, I would explore a consistent Ask AI entry point across the application. The entry point would be universal; the context would be local to the screen and the user's permitted access. On Overview it could explain the theme, on Portfolio a rebalance, and on Updates a manager note.
I would move there in stages:
1. Improve the page using recurring questions and comprehension gaps.
2. Introduce grounded contextual answers from approved, dated sources, with clear uncertainty and escalation.
3. Test the common entry point across a small number of screens before extending it more widely.
This needs evaluation for factual accuracy, source freshness, access boundaries and inappropriate investment advice, alongside resolution and comprehension. It must not reveal paid constituents before subscription or move users into financial actions without the required explicit flow. I would evaluate whether people leave with fewer unresolved questions, rather than treat conversation volume as evidence of value.