Tess Field — a minimal research and design notebook
Build a complete original portfolio for Tess Field, a fictional researcher and designer. The site is a small notebook of inquiries into everyday spaces and shared work. Its primary material is careful writing, supported by simple original diagrams. The design should resemble a readable publication with a contents page, not a software dashboard or agency landing page. Avoid cards, feature grids, client-logo strips, inflated credentials, giant promotional slogans and decorative interface chrome. Minimalism should make the distinctions in the writing easier to see.
The research reference is baytas.net, reached through the DesEngs minimum directory. The actual reference presents a practice and a categorized record of work directly, without a conventional marketing funnel. Tess takes the principle of clearly labeled work into a different visual language: warm paper, serif reading type, a ruled masthead and an editorial contents list. Do not copy the reference's identity, qualifications, clients, talks, dark palette, content or code. Tess has no real academic credentials or participant research claims. The scenes and inquiries are original fictional examples.
Deliverable
Create five complete pages: index.html, waiting-room.html, shared-table.html, leaving-notes.html and about.html. Each inquiry has a direct relative URL and a complete essay. Use static HTML, a local stylesheet, a small local script and original SVG/WebP diagrams. Use system Georgia and Arial stacks so no remote font request is needed. Include credits identifying the research source and the original nature of the content. The footer Collection link leads two directory levels upward. Every contents entry, article-section anchor and next-note link must work.
The index is the notebook's title page and contents. The three essays use a repeated evidence structure: scene, interpretation, proposal, limits and next question. The About page explains this structure and the fictional nature of the work. Do not add a search system for three notes, an account, saved reading lists or fabricated publication citations. A simple reading-size toggle on article pages is the only scripted interaction. It changes the local presentation, not the content or any stored preference.
Editorial visual system
Use a warm paper background, #f8f6ef, and dark green-gray text, #30332c. Secondary metadata is #646b5c. Rules use #b9beaf, with a stronger two-pixel dark line above the masthead. The main shell is approximately 940 pixels wide, centered, with 30-pixel horizontal padding and 55 pixels above. Georgia body copy is 18 pixels with a 1.7 line height. This is a reading website; its body text should feel generous. Arial is used only for navigation, metadata, captions and small interface controls at 14 or 15 pixels.
The title-page h1 is about 42 pixels, regular weight, with a 1.2 line height. It reads Paying attention to ordinary things. This is an editorial title rather than a giant marketing hero. The introduction follows in a measure of about 640 pixels and explains the interests in welcome, unspoken rules and unfinished handovers. A small line identifies the original inquiries and date range. On phones reduce the title to about 34 pixels and use 17-pixel body text. Do not compress the whole design into tiny type to preserve desktop proportions.
The masthead places Tess Field / Research & design on the left and Notes plus About on the right. It is in normal flow, not sticky. On a phone, maintain readable labels and enough spacing for touch. No hamburger is needed. The rule above and below makes the site feel like a small publication. The masthead should not become a large logo or contain a decorative seal. The calm identity comes from the relationship between serif essays and sans-serif apparatus.
Contents page
After the introduction, show a section labeled Contents with three ruled entries. Each row has a small note number, title and kind, plus a date at the far side. The titles are around 24 pixels, regular serif type. The kind and date are 14-pixel Arial. The entire entry is an ordinary anchor, and hover can underline the title without moving the row. On phones place the date beneath the title and keep the number in a narrow separate column. Do not truncate titles; their wording is the most important information in the index.
The three notes are What a waiting room tells us, The rules around a shared table, and Notes for the person who comes next. Their labels are Observation study, Service inquiry and Design reflection. These categories describe the mode of inquiry, not evidence of completed field research. Beneath the contents, add A note on evidence. Explain that the scenes are fictional and the writing separates description, interpretation and proposal. Link to the About page. The footer remains small, ruled and practical, with Credits and Collection.
Essay structure
Each essay begins with note number, kind and date, then title and introductory paragraph. The reading layout below has a narrow 150-pixel section-navigation column and a flexible article column separated by about 50 pixels. The navigation links to The scene, Interpretation, Proposal and Limits. It may be sticky on desktop with a modest top offset. On mobile it becomes a wrapping horizontal set of links above the essay. Anchors use appropriate scroll margins and must land at visible headings.
Inside the article, place the reading-size button first, then the central question as an italic pull question with a subtle left rule. The question is not a quote from a research participant; it is the author's framing. Follow with The scene and An interpretation, then an original diagram, A design proposal, What this does not establish and The next question. Each section contains concrete original prose. Do not add invented participant quotes, percentages, interview counts, citations or success claims. The explicit limit is part of the design, not a footnote to hide.
The first essay considers a waiting room that tells a visitor to wait without confirming that their arrival is known. The interpretation is that acknowledgment, rather than another instruction, may be missing. The proposed card explains the next step while avoiding exposure of other visitors' information. The essay states that no participants were observed and names the need for consent and actual service context in a real study. Preserve these distinctions. The design proposal is a hypothesis, not a validated service intervention.
The second essay considers uncertain permission around a communal table. The fictional room includes shared objects, personal materials and temporary use. The proposed labels are shared, please ask and in use. The idea is to make permission legible without eliminating conversation. The essay must explain that categories could fail if they do not match the room's actual practices. The next inquiry concerns whether newcomers and regular users interpret them similarly. Do not portray the labels as a universal behavior-management system.
The third essay considers a repair-bench handover that says almost done without identifying what remains uncertain. The proposal is a three-line note: ready, uncertain, next. It is deliberately plain enough to write by hand. The essay distinguishes a useful uncertainty from a generic green status badge. It explicitly states that the fictional repair example is not professional safety guidance or a tested procedure. Preserve that limit and the question of whether readers understand the next action accurately.
Diagrams
Create one original diagram for each essay at 1200 by 620. Use a pale green-gray field and three outlined pill-like nodes connected by simple directional lines. The node labels are ordinary text: arrival, acknowledgment and next step for the first; noticing an object, understanding permission and using or asking for the second; ready, uncertain and next for the third. Add the note number and central question as small contextual lines. These diagrams are proposed sequences, not observed journeys or analytical charts.
Keep the diagrams visually simple and fit them within the article measure. They should not become an excuse for elaborate illustrations, icons or animated flowcharts. Include source SVG and optimized WebP files. The caption explicitly says A proposed sequence, not an observed result. Alternative text names the sequence so the meaning survives without the image. Use explicit dimensions to reserve space. The library preview uses the first diagram as hero.webp, while the website index itself remains text-first.
Reading-size interaction
The button initially says Use compact reading size and has aria-pressed false. Clicking adds a compact class to the article body, changes body text to 16 pixels with a 1.65 line height, slightly reduces the pull question and changes the button text to Use comfortable reading size. Clicking again restores the default. The button remains outside any replaced HTML, so focus is not lost. Do not save this choice or send it anywhere. It is a local reading aid, not a theme system or accessibility claim.
The control uses native button behavior and a clear visible focus outline. A person using a keyboard can operate it without a pointer. The change should not animate the whole page or scroll the reader unexpectedly. Keep all headings, links and section anchors intact. The compact mode must still be readable; it is not a way to fit more content into a screenshot. Verify both text and aria state after each click, and measure the computed font size to ensure the CSS actually changes.
About and evidence boundaries
The About page begins Questions before conclusions. Explain that Tess is fictional and the notes are original exercises in noticing, interpreting and proposing. Present a short list defining scene, interpretation, proposal and limit. A scene describes what is present in the example; an interpretation proposes why it might matter; a proposal makes the idea concrete; a limit states what the example cannot establish. This framework is the content of the portfolio and should not be replaced with a generic design process diagram.
Explain the diagrams and reading control honestly. No preference or personal information is saved. Use [email protected] as a plain example address with instructions to replace it when adapting the template. Do not fabricate academic affiliations, publications, credentials or social profiles. A researcher portfolio is especially dependent on accurate evidence claims. The design should support that accuracy by making caveats legible and keeping them in the same reading flow as the proposal.
Accessibility and quality
Use exactly one h1 per page, logical h2 sections, semantic navigation and a skip link. Figures have captions and meaningful alt text. Links remain underlined where their role could be ambiguous. Focus outlines have sufficient contrast. Maintain a readable serif body and sans-serif metadata on phones. The article navigation must not overlap the text, and the diagrams must fit within the document without horizontal scrolling. Footer links may wrap. The system font stack avoids font-loading shifts and external dependencies.
Test every page directly. Check contents, section anchors, next-note links and return links. Inspect desktop title-page and essay composition, then all routes at a measured 390-pixel viewport. Verify the reading-size toggle through real browser interaction and computed font size. Check local diagram files and source links. Do not claim real research validation, deployment or a performance score unless separately established. The exact original content and implementation below are provided as a reconstruction reference, including the distinction between scene, interpretation and proposal. Preserve that distinction as carefully as the layout.
Exact original content and implementation
The following data and source specify every essay, diagram, route, reading-state behavior and responsive rule. They make the prompt directly usable for reconstruction. They are not an invitation to add a backend, collect participant data or invent further evidence.
data.mjs
export const notes=[{id:'waiting-room',number:'01',title:'What a waiting room tells us',kind:'Observation study',date:'May 2026',question:'How does a person know that they have arrived correctly?',intro:'This independent study considers the information in a waiting space before any conversation begins. It treats the room as an interface: a place that communicates what to do, where to sit and whether someone has noticed your arrival.',observation:'The fictional scene contains a door, a reception desk, several chairs and a sign asking visitors to wait. The sign explains the action but not the state. A person can follow it perfectly and still wonder whether the appointment has been registered. That uncertainty is the starting point of the study.',interpretation:'The missing information is not another instruction. It is acknowledgment. A visible arrival confirmation could reduce ambiguity without asking the visitor to interrupt the person at the desk. The confirmation should name the next step and avoid exposing other visitors’ details.',proposal:'The design proposal is a small arrival card: “You’re in the right place. Please take a seat; we’ll call your first name.” It is paired with a clear place to ask for help. The card is an interface sketch, not a claim that a sign alone can resolve every problem in a service environment.',limit:'No participants were observed or interviewed for this concept. The scene is fictional and used to reason about information states. A real study would need consent, an appropriate setting and attention to language, access needs and the actual service process.',next:'I would ask whether visitors can explain what will happen next in their own words. I would also look for cases where the proposed acknowledgment is misleading, such as a delayed appointment or a person who cannot hear their name being called.',diagram:['Arrive','Be acknowledged','Know the next step']},
{id:'shared-table',number:'02',title:'The rules around a shared table',kind:'Service inquiry',date:'November 2025',question:'Which rules are visible, and which are learned by making a mistake?',intro:'Shared table is an original service-design inquiry into the informal rules of a communal work area. It asks how a space can explain expectations without covering every surface in instructions.',observation:'In the fictional setting, people share a large table, power outlets and a shelf of materials. Some objects are free to use and others belong to someone. The room is friendly, but ownership is not obvious. A newcomer has to ask several small questions before feeling able to begin.',interpretation:'The friction comes from uncertain permission. A label that says “shared” does more than identify an object; it gives someone confidence to use it. The design challenge is to make that permission legible without creating a bureaucratic system for a small social space.',proposal:'The proposal uses three ordinary labels: shared, please ask, and in use. The labels attach to places rather than to people. A small welcome note explains the pattern and gives a human contact for exceptions. The system remains deliberately incomplete because conversation is still part of the space.',limit:'This is a fictional inquiry with no fieldwork or measured outcome. The labels are a design hypothesis. They could fail if the room’s actual practices differ from the categories, or if people interpret “please ask” as a barrier rather than an invitation.',next:'The next study would examine whether newcomers and regular visitors interpret the labels similarly. I would pay particular attention to objects that move between shared and personal use during the day.',diagram:['Notice an object','Understand permission','Use or ask']},
{id:'leaving-notes',number:'03',title:'Notes for the person who comes next',kind:'Design reflection',date:'June 2025',question:'What makes a handover useful after the author has left?',intro:'Leaving notes studies the small documents that connect one person’s work to another’s. The focus is not a formal process diagram but the everyday note left beside a task, object or unfinished decision.',observation:'A fictional repair bench has a half-finished object and a note reading “almost done.” The phrase communicates progress but not what remains. The next person must inspect the object to discover whether the remaining work is cosmetic, structural or waiting for a part.',interpretation:'A useful handover names the uncertainty. It does not need to narrate every action already taken. The most valuable sentence may be “I have not checked this joint yet,” because it prevents the next person from mistaking appearance for completion.',proposal:'The design proposal is a three-line note: what is ready, what is uncertain, and what to do next. The structure is intentionally plain and can be handwritten. Its purpose is to support judgment rather than replace it with a green status badge.',limit:'The repair scene and notes are fictional examples. This is not a tested safety procedure or professional repair guidance. In a real high-consequence setting, a more formal process and appropriate expertise would be necessary.',next:'I would compare how people describe the next action after reading several versions of a note. The question is whether the wording preserves the important uncertainty, not whether readers prefer the shortest version.',diagram:['What is ready','What is uncertain','What happens next']}];
site.css
*{box-sizing:border-box}body{margin:0;background:#f8f6ef;color:#30332c;font:18px/1.7 Georgia,'Times New Roman',serif}a{color:inherit;text-underline-offset:4px;text-decoration-thickness:1px}h1,h2,p{margin:0}h1,h2{font-weight:400}h1{font-size:38px;line-height:1.2;letter-spacing:-1px}h2{font-size:24px;line-height:1.35}.shell{max-width:940px;margin:auto;padding:55px 30px 35px}.masthead{border-top:2px solid #30332c;border-bottom:1px solid #b9beaf;padding:15px 0;display:flex;justify-content:space-between;gap:25px;align-items:baseline;font:15px/1.5 Arial,sans-serif}.masthead a{text-decoration:none}.masthead nav{display:flex;gap:25px}.title-page{padding:70px 0 50px;max-width:660px}.title-page h1{font-size:42px;margin-bottom:25px}.title-page p{max-width:640px}.small,.meta{font:14px/1.6 Arial,sans-serif;color:#646b5c}.title-page .small{margin-top:25px}.contents{border-top:1px solid #b9beaf;margin-top:25px}.contents h2{font:15px Arial,sans-serif;padding:20px 0}.entry{display:grid;grid-template-columns:45px 1fr 150px;gap:25px;padding:22px 0;border-top:1px solid #d6dacd;text-decoration:none;align-items:baseline}.entry h3{font-size:24px;font-weight:400;line-height:1.4;margin:0}.entry p{font:14px/1.6 Arial,sans-serif;color:#646b5c;margin-top:6px}.entry time,.entry .number{font:14px Arial,sans-serif;color:#646b5c}.entry:hover h3{text-decoration:underline}.index-note{margin-top:50px;max-width:650px}.index-note h2{margin-bottom:20px}.article-head{margin:55px 0 35px}.article-head .meta{margin-bottom:18px}.article-head h1{max-width:730px;margin-bottom:25px}.article-head>p:last-child{max-width:700px}.article-grid{display:grid;grid-template-columns:150px minmax(0,1fr);gap:50px}.article-nav{font:14px/1.6 Arial,sans-serif;align-self:start;position:sticky;top:25px}.article-nav a{display:block;margin-bottom:12px}.article-body section{margin-bottom:38px;scroll-margin-top:25px}.article-body h2{margin-bottom:18px}.article-body p{margin-bottom:20px}.question{font-size:26px;line-height:1.4;font-style:italic;border-left:2px solid #8d987f;padding-left:25px;margin:20px 0 40px}.diagram{margin:35px 0}.diagram img{display:block;width:100%;height:auto}.diagram figcaption{font:14px/1.6 Arial,sans-serif;color:#646b5c;margin-top:12px}.reading-toggle{font:14px Arial,sans-serif;border:0;border-bottom:1px solid #8d987f;background:none;padding:10px 0;cursor:pointer;color:#30332c;margin:0 0 25px}.article-body.compact{font-size:16px;line-height:1.65}.article-body.compact .question{font-size:22px}.next{border-top:1px solid #b9beaf;padding-top:25px;margin-top:55px;display:flex;justify-content:space-between;gap:25px;font:14px/1.6 Arial,sans-serif}.about{max-width:700px;margin:55px 0 70px auto}.about h1{margin-bottom:30px}.about p{margin-bottom:25px}.about h2{margin:35px 0 20px}.about ul{padding-left:23px}.about li{margin-bottom:13px}footer{border-top:1px solid #b9beaf;margin-top:65px;padding-top:25px;display:flex;justify-content:space-between;gap:25px;font:14px/1.6 Arial,sans-serif;color:#646b5c}footer nav{display:flex;gap:20px;flex-wrap:wrap}a:focus-visible,button:focus-visible{outline:2px solid #536345;outline-offset:5px}.skip{position:absolute;top:-90px;background:white;padding:12px}.skip:focus{top:10px}@media(max-width:700px){body{font-size:17px}.shell{padding:30px 22px}.masthead{font-size:14px;gap:15px}.masthead nav{gap:17px}.title-page{padding:45px 0 30px}.title-page h1{font-size:34px}.entry{grid-template-columns:28px 1fr;gap:15px}.entry time{grid-column:2}.entry h3{font-size:23px}.article-head{margin-top:38px}.article-head h1{font-size:32px}.article-grid{display:block}.article-nav{position:static;display:flex;gap:18px;flex-wrap:wrap;margin-bottom:30px}.article-nav a{margin:0}.question{font-size:24px;padding-left:18px}.about{margin:40px 0}.about h1{font-size:32px}footer{display:block}footer nav{margin-top:15px}.next{gap:20px}}
site.js
(()=>{const toggle=document.querySelector('[data-reading]');toggle?.addEventListener('click',()=>{const body=document.querySelector('.article-body');const compact=body.classList.toggle('compact');toggle.setAttribute('aria-pressed',String(compact));toggle.textContent=compact?'Use comfortable reading size':'Use compact reading size';});})();
build.mjs
import fs from'node:fs';import sharp from'sharp';import{notes}from'./data.mjs';const src='scripts/tess-field',out='public/demos/tess-field';function art(n){return`<svg xmlns="http://www.w3.org/2000/svg" width="1200" height="620"><rect width="1200" height="620" fill="#ebece1"/><g fill="none" stroke="#66735c" stroke-width="2">${n.diagram.map((x,i)=>`<rect x="${50+i*395}" y="210" width="310" height="160" rx="75"/>${i<2?`<path d="M${360+i*395} 290h85m-20-14 20 14-20 14"/>`:''}`).join('')}</g><g font-family="Georgia,serif" fill="#30382b">${n.diagram.map((x,i)=>`<text x="${205+i*395}" y="295" text-anchor="middle" font-size="23">${x}</text>`).join('')}<text x="55" y="95" font-size="20">Field note ${n.number} / a proposed sequence</text><text x="55" y="535" font-size="20">${n.question.replaceAll('&','&')}</text></g></svg>`;}function shell(title,body){return`<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>${title} — Tess Field</title><meta name="description" content="Tess Field, original research and design reflections on ordinary spaces and shared work."><link rel="stylesheet" href="site.css"></head><body><a class="skip" href="#main">Skip to content</a><div class="shell"><header class="masthead"><a href="index.html">Tess Field / Research & design</a><nav aria-label="Main"><a href="index.html">Notes</a><a href="about.html">About</a></nav></header><main id="main">${body}</main><footer><span>Independent inquiries. Fictional settings.</span><nav aria-label="Footer"><a href="assets/CREDITS.txt">Credits</a><a href="../../">Collection ↗</a></nav></footer></div><script src="site.js"></script></body></html>`;}export async function buildTessField(){fs.mkdirSync(`${out}/assets`,{recursive:true});for(const f of['site.css','site.js'])fs.copyFileSync(`${src}/${f}`,`${out}/${f}`);for(const n of notes){const svg=art(n);fs.writeFileSync(`${out}/assets/${n.id}.svg`,svg);await sharp(Buffer.from(svg)).webp({quality:94}).toFile(`${out}/assets/${n.id}.webp`);}fs.copyFileSync(`${out}/assets/waiting-room.webp`,`${out}/assets/hero.webp`);fs.writeFileSync(`${out}/index.html`,shell('Field notes',`<section class="title-page"><h1>Paying attention<br>to ordinary things.</h1><p>I’m Tess, a fictional researcher and designer. These notes explore the information in everyday spaces: the welcome, the unspoken rule, the unfinished handover.</p><p class="small">A small collection of original inquiries, 2025–26.</p></section><section class="contents"><h2>Contents</h2>${notes.map(n=>`<a class="entry" href="${n.id}.html"><span class="number">${n.number}</span><div><h3>${n.title}</h3><p>${n.kind}</p></div><time>${n.date}</time></a>`).join('')}</section><section class="index-note"><h2>A note on evidence</h2><p>These are design inquiries built around fictional scenes. They separate observation, interpretation and proposal, and name the questions that would need real fieldwork.</p><p><a href="about.html">Read about the approach →</a></p></section>`));notes.forEach((n,i)=>fs.writeFileSync(`${out}/${n.id}.html`,shell(n.title,`<article><header class="article-head"><p class="meta">Field note ${n.number} / ${n.kind} / ${n.date}</p><h1>${n.title}</h1><p>${n.intro}</p></header><div class="article-grid"><nav class="article-nav" aria-label="Article sections"><a href="#scene">The scene</a><a href="#interpretation">Interpretation</a><a href="#proposal">Proposal</a><a href="#limits">Limits</a></nav><div class="article-body"><button class="reading-toggle" data-reading aria-pressed="false">Use compact reading size</button><p class="question">${n.question}</p><section id="scene"><h2>The scene</h2><p>${n.observation}</p></section><section id="interpretation"><h2>An interpretation</h2><p>${n.interpretation}</p></section><figure class="diagram"><img src="assets/${n.id}.webp" width="1200" height="620" alt="Proposed sequence: ${n.diagram.join(', ')}"><figcaption>A proposed sequence, not an observed result.</figcaption></figure><section id="proposal"><h2>A design proposal</h2><p>${n.proposal}</p></section><section id="limits"><h2>What this does not establish</h2><p>${n.limit}</p></section><section><h2>The next question</h2><p>${n.next}</p></section></div></div><nav class="next" aria-label="Note navigation"><a href="index.html">← Contents</a><a href="${notes[(i+1)%3].id}.html">Note ${notes[(i+1)%3].number} →</a></nav></article>`)));fs.writeFileSync(`${out}/about.html`,shell('About',`<article class="about"><h1>Questions before conclusions.</h1><p>Tess Field is a fictional researcher and designer created for this portfolio. The notes are original exercises in noticing, interpreting and proposing. They do not report real participant research.</p><p>I am interested in the information people need before they can act with confidence. Sometimes it is an instruction. Often it is a small acknowledgment, an explanation of permission, or a clear account of what remains uncertain.</p><h2>A working distinction</h2><ul><li>A scene describes what is present in the example.</li><li>An interpretation proposes why that arrangement might matter.</li><li>A design proposal makes the interpretation concrete enough to question.</li><li>A limit states what the example cannot prove.</li></ul><h2>Using these notes</h2><p>The diagrams are original and intentionally simple. They show proposed sequences rather than measured journeys. The reader can change the article's type size; no preference or personal information is saved.</p><h2>Correspondence</h2><p>Example address: [email protected]. Replace it with your own details when adapting this portfolio.</p><p><a href="index.html">Return to the contents →</a></p></article>`));fs.writeFileSync(`${out}/assets/CREDITS.txt`,'Tess Field — original fictional research portfolio, essays and diagrams. Reference https://baytas.net viewed through the DesEngs minimum directory. The reference informed direct categorization of practice and work; no credentials, content or visual identity reused. System Georgia and Arial font stacks.');const prompt=fs.readFileSync(`${src}/PROMPT.md`,'utf8');fs.writeFileSync(`${out}/PROMPT.md`,prompt);fs.writeFileSync('public/prompts/tess-field.md',prompt);return{prompt};}if(process.argv[1]?.endsWith('/tess-field/build.mjs'))await buildTessField();