THE QUESTION: What did it take to turn this question into something you can click?
WHAT DID IT TAKE TO MAKE THIS CLICK?
A question becomes a page, then a system, then something a stranger has to understand. This is a workshop-floor dissection of one real public project: the Sahilverse homepage.
Nine visible design choices. Their likely benefits. Their genuine costs. The things a public page cannot tell us about its own history.
01 verified live case09 observed checkpoints05 copyable toolsNo fake timeline
WORKSHOP / CONCEPTUAL MAPNOT A SCREENSHOT
Blueprint reconstruction, not an original sketch or captured webpage. The boxes reflect categories visible on the live homepage; arrows explain a possible visitor journey.
00 / Read the evidence label
A build story with its seams showing.
A polished result does not reveal the path that produced it. Treat this page as a design reading of a public artifact, not an authenticated history of every draft.
SOURCEPublic live homepage
Opened for this case on 23 October 2026.
OBSERVABLEContent and visible controls
Hero, modes, sections, categories, search labels, and links.
RECONSTRUCTEDTrade-off explanations
Why design decisions may help or hurt a visitor.
NOT AVAILABLEPrivate version history
Drafts, code commits, prompts, failures, timed iterations and actual prototype sequence.
OBSERVED = visible in public artifactANALYSIS = reasoned interpretationUNKNOWN = private evidence not suppliedSIMULATION = teaching illustration, not a recovered version
A page can demonstrate what exists. It cannot prove what alternatives the maker considered, how many times they revised, which tools generated each component, or which experience visitors preferred. Those would require dated source files, repository commits, analytics or genuine user research.
01 / The flagship artifact
The internet is wide. The entrance is narrow.
Featured case: Sahilverse / sahiltayal.com ↗. Not a hypothetical client project. Not a claim about conversion rates. An actual, inspectable independent publishing home.
Working case proposition / analytical reconstruction
How do you make a large and varied body of work discoverable without making it uniform?
A visitor arrives with no map of the creator's interests. One may want an essay, another a playful web experience, another a practical studio conversation. The homepage publicly offers modes, three starter paths, recent experiments, thematic constellations, a searchable album and studio links. Those observed ingredients let us reason about the design's purpose.
Caution: this proposition is a useful reading of the live interface, not an alleged quote from the original brief.
The live hero introduces Sahil Tayal as someone working across psychology, education, work, technology and perfumery. The page then unfolds into many separate destinations. Breadth is attractive, but it creates a navigation problem: the reader should not have to know the creator's internal taxonomy before finding something worth exploring.
A conventional solution would be a resume-first landing page with a list of achievements. A different conventional solution would be an unfiltered project grid. Neither is inherently wrong. Yet both risk answering the wrong question for a first visitor. A stranger initially needs to know what kind of place this is and how to enter. The homepage's headline, framing line and “Three Doors” section are observable answers to that problem.
Transferable lesson: Define the visitor's first uncertainty. Then make the first screen reduce that uncertainty, not merely display the creator's personality.
02 / Audience
Inferred visitor jobs
One page, several legitimate intentions.
We can identify plausible tasks from the interface—not from unprovided audience surveys. A first-time explorer wants an inviting start. A returning reader wants to find a particular idea. A visitor interested in professional web design wants to judge concrete work and reach a services page. An intellectually curious visitor may want to follow relationships between ideas.
That implies several layers of entry. The hero frames the whole. The three doors curate a beginning. The album supports retrieval. “Follow the Thread” offers editorial connection. The studio link supports practical inquiry. A useful interface does not force all these people down one funnel; it makes their next step intelligible.
03 / Constraints
Visible tensions, not a private specification
Creative distinctiveness has an operating cost.
The public experience holds apparently conflicting ambitions: unusual presentation and understandable navigation; a growing library and a curated entrance; editorial exploration and a clear commercial contact path. We can observe those tensions, but cannot assert the exact device matrix, performance budgets or accessibility targets that were set during the original build.
Each choice creates a maintenance obligation. Multiple modes multiply the number of visual and interaction states to check. A searchable catalogue depends on accurate names and stable destinations. Curated routes become outdated as new ideas appear. A personal universe can be playful; a broken link is still a broken link.
A useful constraint for future iterations is simple: if an experience asks a visitor to learn a new interaction language, it must also leave a familiar way home.
04 / Concept sketch
Rebuilt here as a teaching diagram
Frame → orient → retrieve → connect.
The diagram below is a functional abstraction of the homepage as observed, not an archival sketch. It explains how a reader can move from a large identity statement toward smaller, increasingly specific decisions. The surrounding explanatory labels are interpretations.
A diagram is not the interface.
Text equivalent: A visitor first reads the overall promise, can then choose among three starter routes, search or filter the fuller album, and optionally pursue thematic relationships among different projects.
This is one possible route, not a compulsory sequence; on the live homepage the visitor may jump directly to another section.
05 / Prototype
What is visible vs unavailable
The published artifact is inspectable. Its prototype genealogy is not.
At the public URL you can see named mode controls, thematic prompts, a searchable album interface, separate editorial sections and destinations. That is adequate evidence to analyze the present interface architecture. It does not establish that a hand-drawn wireframe existed, that this precise order appeared in the first build, or that an AI model authored any specific part.
To establish a historical timeline, collect an early source file with a timestamp, a later source file, a dated commit or deployment record, and a screenshot from each version. Then describe actual differences and the evidence that motivated the change. This site deliberately avoids the tempting fiction of “first we failed, then we heroically fixed it.”
The interactive comparison further down is explicitly a simulation for reasoning. It is not presented as an archived before/after of Sahilverse.
06 / Publication
Public facts / separate QA standards
Shipping is a state, not a certificate.
The homepage and the linked studio page were publicly reachable when this case was researched. The homepage contains navigational links, several visible entry formats and labelled sections; those are independently inspectable. The precise build tooling, hosting settings, original launch date, redirect configuration and historical code changes were not established from the public page.
For a future deployment, content and usability checks are not the same as a claim of full WCAG compliance or guaranteed search visibility. Keyboard operation, small-screen layout, reduced motion, HTTP status, metadata, crawlability and endpoint accuracy need their own tests. The W3C reference offers test criteria; the Google SEO guide explains foundations without promising rankings.
07 / Unresolved
Open questions
The meaningful next questions aren't more visual effects.
Can a first-time visitor find an appealing destination in under a minute? Can a keyboard-only visitor navigate every mode? Does the catalogue have a single source of truth? Are links labelled accurately after frequent publication? Does an intense visual variant preserve the same core content? Those are questions to test, not verified deficiencies of the current website.
Useful evidence would be task-based observations from a few real visitors, mobile screen recordings with permission, an automated link inventory, accessibility checks followed by manual review, and a repeatable pre-deploy smoke test. A beautiful front door earns its existence by opening, not by impressing its architect.
Primary source notes & uncertainty ↗
Observed from the live homepage on 23 October 2026: headline, multi-mode controls, “Three Doors,” constellations, album search/select controls, “Follow the Thread,” web studio links, dated recent groups and the explicit status disclaimer. Not independently established: historical alternatives, implementation code, browser-wide conformance, uptime, successful end-to-end interaction, search indexing results or audience performance.
To turn this into an actual versioned production history, provide original HTML/source archives and their dates. Until then, the analysis remains a contemporary design reading.
02 / Decision trail
Every advantage sends an invoice.
Nine checkpoints grounded in visible present-day features. Alternative options, likely benefits and costs are explicitly analytical hypotheses. They are not invented meeting notes.
09 checkpoints / overview
CHECKPOINT 01 / 09LIVE OBSERVATION
The one-sentence contract
Live hero: “ONE MIND. INFINITE WORLDS.” and a short explanation of cross-disciplinary work.
Possible alternative · hypothetical
Open with a CV, an autobiography, or a wall of tiles.
Potential benefit · analysis
Gives strangers a quick interpretive frame before the catalogue.
Cost / responsibility · analysis
A poetic headline cannot by itself explain every project.
Effect on the visitor · not a version history
A visitor can describe the site’s remit before choosing a destination.
When a step control has focus: ← / → keys work too.
03 / Model, not archival material
A before/after without a fake past.
This teaching simulation contrasts two possible information architectures. It does not display genuine historical versions, earlier screenshots, or measured outcomes.
Illustrative simulation / choose a view
Same fictional collection. Different entrance.
Suppose a new visitor has eight unrelated-looking items to scan. What changes when we offer a small set of questions before exposing the full catalogue?
A / hypothetical flat index. Eight equal choices; good for scanning if you already know a title. A newcomer must infer their meaning.
ILLUSTRATIVE ITEMS · NOT ARCHIVE CAPTURES
Agency notes →
Learning essay →
Interactive world →
Fragrance concept →
Work journal →
Identity lab →
Research model →
Design services →
No scoring, tracking, hidden correct answer or fake performance metric. This is a visual thought experiment, not evidence that either design won a user test.
04 / The trade-off bench
You decide. Then pay the price.
Three real tensions in creative technical work. Pick a direction and read its likely consequences and a reasonable compromise. Results stay on this page, only in your browser memory while it is open.
These are reasoned trade-offs, not psychological profiles or a scored test. There is no submission, backend or analytics event attached to your choices.
05 / Workshop takeaway kit
Use the thinking. Not just the aesthetic.
Five practical tools you can copy directly into a new project. Each is intentionally explicit about evidence, constraints and responsibility after launch.
01 / Creative brief
Use before opening a design tool or drafting the first line.
PROJECT / working title:
QUESTION / what is genuinely unresolved?
AUDIENCE / who will use this; what do they already know?
ONE-SENTENCE JOB / after 30 seconds, a visitor should...
PRIMARY ACTION / what should they be able to do?
IN-SCOPE / essential claims, pages and interactions:
OUT-OF-SCOPE / attractive things we're deliberately not building:
PROOF / which facts can we substantiate with source links?
CONSTRAINTS / bandwidth, accessibility, devices, time, privacy:
TRADEOFF / which desirable feature are we willing to sacrifice?
SHIP CONDITION / minimum tests that must pass:
UNKNOWNS / what cannot honestly be claimed yet?
02 / Source-verification ledger
Separate a working link from evidence that its claim is true.
CLAIM / exact public-facing assertion:
TYPE / observed fact | interpretation | design proposal | unknown
PRIMARY SOURCE / original URL or owner file:
CHECK / what did I inspect, and on which date?
RESOLUTION / did the exact destination load and match the label?
SCOPE / what does the source actually support?
LIMIT / what does it NOT establish?
DISPOSITION / publish | qualify | omit | ask owner
RECHECK / when would this evidence become stale?
NOTE / never turn a site listing into an independent QA certificate.
03 / Ethical AI review
For code, graphics and research produced with AI assistance.
HUMAN INTENT / what question and judgment did I contribute?
AI CONTRIBUTION / outline, code, rewrite, critique or other:
VERIFIED FACTS / what did I check independently?
FABRICATION PASS / invented biography, users, results, quotes, dates?
ATTRIBUTION PASS / external material, rights and links acceptable?
HARM PASS / privacy, sensitive disclosures, misleading framing?
INTERACTION PASS / does every button do what it promises?
ACCESSIBILITY PASS / keyboard, focus, reflow, reduced motion?
LIMITS / what remains a prototype, simulation or open hypothesis?
OWNERSHIP / who reviews and maintains this after publication?
04 / Pre-deploy QA
Run on the built files, then repeat the public checks after deployment.
[ ] Pages/assets return expected HTTP statuses; no unexpected 404s
[ ] Internal links, mailto, anchors and outbound URLs inspected
[ ] Home/back navigation visible from every major view
[ ] Keyboard: Tab, Shift+Tab, Enter, Space, Escape, arrows where used
[ ] Focus visible; dialog traps focus and restores it on close
[ ] Controls have accessible names and meaningful state announcements
[ ] 360px, 768px, 1440px: readable, usable, no horizontal overflow
[ ] Reduced-motion preference: no essential information lost
[ ] No-JavaScript: article and core links are still available
[ ] Page title, description, canonical, OG preview, schema and sitemap match
[ ] Copy-to-clipboard and interactive explanations actually work
[ ] Re-test on the deployed URL; local success is not production proof
05 / Content upkeep contract
Prevent a living archive from becoming an elegant collection of dead doors.
EVERY NEW PROJECT
- Check the published URL and page title.
- Add a concise human description, not a promise of future work.
- Choose one primary theme; link a second only with a reason.
- Distinguish live / experimental / not yet verified.
- Record the relevant source and last review date.
MONTHLY LIGHT PASS
- Test the top navigation, main CTA and featured projects.
- Re-read the three entry doors for relevance.
- Fix duplicate or contradictory project descriptions.
- Confirm analytics and consent behaviour, if analytics is enabled.
TRIGGER FOR A DEEP PASS
- New site architecture, new privacy policy or major redesign.
- Search console warning, persistent broken links or failed user flows.
A useful stopping rule
Do not confuse more features with more value. If the visitor can understand, act, recover from mistakes and return, the next improvement should answer a real question—not merely prove that another animation is possible.
06 / The craft is medium-specific
A website is only one kind of artifact.
The sequence question → constraint → construction → critique travels across disciplines. The proofs of quality do not.
01 / Essay
A thought becomes an argument.
Start with a tension worth examining. Choose the reader, establish scope, distinguish personal experience from general claims, and build a sequence of paragraphs that earns its conclusion.
Equivalent of usability: a reader can follow the claim without reading your mind.
Evidence: accurate attribution, well-characterised sources, fair counterarguments.
Failure mode: a good line outruns the evidence supporting it.
Define the phenomenon, variables, expected mechanisms, boundary conditions and rival explanations. Then identify what observation could change your mind.
Equivalent of usability: someone else can interpret and operationalise the terms.
Evidence: data or studies adequate for the exact claim; theoretical diagrams are not validation.
Failure mode: mathematical presentation implies more certainty than the data warrant.
Translate an emotional idea into an olfactory brief, select appropriate materials, record a formula, test stability and wear, gather descriptive feedback, and revise without claiming the same scent will mean the same thing to everyone.
Equivalent of usability: wearability, comprehensibility and responsible product information.
Evidence: formula records, stability work, appropriate safety/label review, and actual feedback.
Failure mode: poetic intention is mistaken for measured effect or safety evidence.
No specific formulation, sensory test or safety result is claimed here.
The shared craft, in one paragraph
An essay needs counterargument; a model needs falsifiability; a fragrance needs material validation; a website needs usable behavior across real devices. In each, the maker must decide what belongs, identify whose experience counts, and separate an elegant representation from the evidence of its effectiveness. The common instrument is judgment. The test changes with the medium.
07 / Sources and further reading
Show your working.
Primary observations, related original writing and independent design references are grouped separately so inspiration is never mistaken for evidence.
Guidance about focus and interaction needed for real modal dialogs.
What would upgrade this evidence? ↗
Original source files of the homepage across known dates, contemporaneous design briefs, deployment records and authorised screenshots would allow a genuine before/after comparison. A separate, consent-based study could test discoverability. Until then, numerical impact, exact production chronology and internal motivation remain unknown.
Open workshop / no vanity metrics
What would you challenge?
Spot an unsupported claim, a confusing interaction or a better design trade-off? Send a note. That feedback is more useful than pretending this is finished.