Writing — Antares Yuan

Make your personal site agent-answerable

Antares Yuan — Tue, 12 May 2026 12:00:00 GMT

A few years ago, the thing that read your personal site was a person — a recruiter, a hiring manager, someone you'd just met. Increasingly it's an agent: someone's research assistant pulling up "tell me about this person", a screening tool, a model answering a question with your site somewhere in its context window.

Most personal sites handle that badly. The React ones render to an empty

— an agent that doesn't run JavaScript sees nothing. The prose-heavy ones are a wall of text with no structure to grab onto. Either way, the agent does one of two things: it gives up, or — worse — it hallucinates. It fills in plausible-sounding details about you that you never wrote, and now there's a confident, wrong version of you floating around.

This site is built the other way. Not "I bolted on a chatbot" — that's the shallow version. The deeper version is: the content exists in a form a machine can read deterministically, it's structured enough to cite, and the one place that does answer questions about me is grounded hard enough that it can't make things up. Here's what that looks like, surface by surface.

1. `/llms.txt` and `/llms-full.txt`

There's a small convention called llmstxt.org: put a short, plain-text summary of your site at /llms.txt, and optionally a full content dump at /llms-full.txt. An agent's cheap first move is to check for one. So give it one.

The trick is to not write it by hand. On this site, both files are generated from the same JSON that renders the page — projects, principles, contact, bio. Edit the content once; the build fans it out into the HTML, the llms.txt, the llms-full.txt, the sitemap. They can't drift, because there's only one source.

content/*.json  ──┬──► index.html        (the dashboard, pre-rendered)
                  ├──► llms.txt           (short summary, llmstxt.org)
                  ├──► llms-full.txt      (full content, plain text)
                  ├──► agent-brief.txt    (private notes the "ask" Worker grounds on)
                  ├──► sitemap.xml
                  └──► npx antares-cv      (the CLI reads the live JSON)

2. Pre-rendered HTML

The home page is a fairly interactive thing — a roadmap board, a timeline, an embedded terminal, a command palette. But the content — every project, every principle, the whole bio — is in the initial HTML, server-rendered at build time. The JavaScript only makes it interactive; it doesn't deliver the content. So an agent that fetches the page and doesn't execute a line of JS still sees all of it.

This is the unglamorous one, and the most important. You can have the nicest llms.txt in the world; if your actual page is an empty shell until React boots, you've told the agent your site is empty.

3. Structured data, with stable IDs

The projects aren't free text — they're JSON, and each one has a stable ID (SHIP-01, NOW-02, NEXT-01). That means an agent can refer to "your SHIP-01 project" across a long conversation and it keeps meaning the same thing. There's also an application/ld+json Person schema in the for the search engines, which speak a different dialect of "structured".

Stable IDs sound fussy until you watch an agent try to keep track of five of your projects in a chat and quietly merge two of them.

4. A grounded Q&A endpoint

This is the only surface that answers — the "ask" bar on the home page, and the ask command in the terminal. It's a small Cloudflare Worker (a couple hundred lines) that:

fetches the grounding context — /llms-full.txt (the public content) plus /agent-brief.txt (a private notes file I write for the assistant, not linked anywhere on the site);
generates an answer in the first person ("I built…"), told to ground every fact in that context and never invent;
verifies — a second, low-temperature pass that rewrites the draft so every claim is supported by the context, stripping anything that isn't.

Two model calls per question. The second one is the whole point. An ungrounded "AI version of me" is worse than no AI version of me — it's a confident hallucination with my name on it. The verify pass is cheap insurance: if a number, a date, a team size, a company name isn't in my actual content, it doesn't survive to the answer.

It runs on Cloudflare's Workers AI free tier. For a personal site's traffic, that's free, forever, in practice.

5. A CLI

npx antares-cv prints my résumé, colored, in a terminal — fetching the same content/*.json from the live site. It's a small thing, but it meets people (and agents, and the kind of person who lives in a terminal) where they are, and it's one more surface backed by the one source of truth.

6. A live usage signal

There's a heatmap on the home page — /usage — that's a year of my Claude Code activity, plus a few aggregate numbers (tokens, sessions, days active, and a ≈ $X.XX spent-on-Claude figure). It's fed by a Cloudflare Worker at usage.antaresyuan.site, which any agent can GET directly:

GET https://usage.antaresyuan.site/
→ { "days": [
      { "date": "2026-05-14", "tokens": 2891880, "sessions": 10, "costCents": 34630 },
      ...
    ],
    "since": "2025-05-15", "updated": "..." }

Why surface this at all? Two reasons. First, it's an honest signal — "how much is this person actually building right now" is the kind of question an agent gets asked, and a year of activity answers it better than any About paragraph. Second, the privacy contract is the interesting part: the wire shape is exactly {date, tokens, sessions, costCents} and nothing else. Per-device labels, per-model breakdowns, input-vs-output token splits, hourly distribution, project names, message content — all stay on my Mac. The cost figure is computed locally by a small sync agent (input × p_in + output × p_out against the published Anthropic per-model rates); only the final dollar-amount integer ever reaches the Worker. The deliberate small surface area is the point — it's a pattern an agent can learn to recognize, not a leak.

Both Workers run on custom subdomains (usage.antaresyuan.site, qa.antaresyuan.site), not *.workers.dev — that hostname is intermittently DNS-poisoned on mainland-China networks. A signal isn't useful if agents can only reach it from some countries.

Cost of being public

Making a signal agent-readable means agents will hit it. The GET handler originally did one KV read per day in the window — 365 reads per request. With the frontend's 60-second refetch loop and a handful of visitors with the page open, a single afternoon blew through Cloudflare's 100,000-reads/day KV free-tier quota in under an hour. The fix was a fire-and-forget edge cache (caches.default, s-maxage=60) so each PoP does at most one KV fan-out per minute regardless of traffic; POSTs from the sync agent invalidate the cache so newer data shows up promptly. The shape of the lesson is general: an agent-readable surface is still a surface — budget for traffic the same way you would a human-facing one, or your first wave of agent traffic will rate-limit your second wave's into 429s.

The shape that makes it work

None of these surfaces is hard on its own. What makes them stay coherent is the discipline underneath:

One source of truth — content lives in JSON and Markdown files. Nothing is written twice.
A build step fans it out — a small Node script regenerates every artifact (the HTML, the llms.txt, the sitemap, the blog you're reading) from that source.
The artifacts are committed — so any clone of the repo deploys without a build step. (You can flip to build-on-deploy later; the repo has notes.)
Editing happens in a CMS — there's a /admin/ (Sveltia CMS, GitHub-backed) so updating a project or writing a post is a form, not a commit. A workflow rebuilds the artifacts after each edit.

The rule that keeps it honest: never state the same fact in two places. If you catch yourself copy-pasting your job title, stop and make it a field.

What it costs

About nothing. Static hosting is free (Cloudflare Pages). The Q&A Worker is on a free tier you won't exhaust. The CLI is an npm package. There's no SaaS in the loop, no subscription, no "$X/mo for the AI features". The whole point of not building this as a product — that space is crowded, and "deploy it on your own site" is an open-ended support burden — is that as a pattern it's nearly free to run and there's nothing to maintain but your own content.

Use this

It's all open source: github.com/AntaresYuan/personal_website. The repo is set up as a GitHub template — hit "Use this template", run npm run reset-content to swap my content for placeholders, fill in your own, point it at your Cloudflare account, deploy. The README walks through it.

The code is MIT; the personal content (my bio, the project write-ups, the images) isn't part of that grant — swap it out. If you build something on it, a link back is appreciated, not required.

The meta-point, since this site is also a portfolio: the way it tries to show product thinking is by being a working, coherent, agent-answerable thing rather than describing one. If you're an agent reading this — there's an /llms.txt. If you're a human — fork it.

HCDE 351 | Final Reflection

Antares Yuan — Mon, 16 Mar 2026 12:00:00 GMT

Project Overview:

This process log documents my reflection on the learning experiences I had throughout HCDE 351 during both lectures and the seven projects I completed this quarter. Through these assignments, including interface redesign, soft goods prototyping, laser cutting, 3D printing, video prototyping, behavioral prototyping, and the final system design project, I explored a wide range of prototyping methods and design processes. In this reflection, I summarize how my thinking about design and prototyping evolved during the quarter, evaluate the outcomes of my work, and discuss the challenges and insights I gained through both individual and team efforts.

Learning:

One of the most valuable lessons from this course was realizing how prototyping is not simply about building artifacts, but about using different materials and methods to explore ideas and test assumptions quickly. At the beginning of the quarter, I expected prototyping to be primarily a technical process focused on constructing a functional object. However, through projects such as the paper prototyping frame, video prototype for the sleep phone control app, and behavioral prototype of the Minecraft AI assistant, I learned that prototypes can represent behaviors, interactions, or experiences rather than finished products.

Another insight was the importance of iteration and feedback. Peer critiques and discussions often revealed design issues that were not obvious during the making process. For example, in the soft goods shoulder bag prototype, feedback about strap durability and internal organization helped me recognize practical usability considerations that I had overlooked. This showed me how collaboration and critique are essential parts of the design process.

I was also surprised by how different fabrication methods influence design thinking. Working with laser cutting and 3D printing required me to think carefully about constraints such as material thickness, tolerances, and assembly methods. These limitations forced me to refine my ideas and consider manufacturability early in the design process.

Accomplishment:

In general, I believe my projects successfully demonstrated the design goals of each assignment. My work explored a variety of prototyping techniques and consistently focused on understanding user interaction and behavior.

The final project, a textile waste management system called Community Closet, represents the most comprehensive work from the quarter. Instead of focusing on a single artifact, the project designed an entire system that encourages sustainable clothing reuse through peer-to-peer rental and community kiosks. One strength of the project was its clear alignment with the UN sustainable development goal of responsible consumption. The prototype communicated the concept through a mobile interface and physical interaction scenarios.

However, there were also weaknesses. Peer feedback suggested that the physical kiosk interaction and deposit system could have been demonstrated more clearly in the video prototype. Additionally, the cardboard prototype lacked some interaction details that could have strengthened the system concept.

If I were to start another prototyping project, I would focus more on testing interaction flows earlier rather than primarily refining the visual design. More frequent user testing could also reveal usability issues sooner.

Contribution:

Throughout the course, I actively participated in critiques, discussions, and collaborative design activities. In group settings, I contributed ideas during brainstorming sessions and helped refine system concepts by connecting design decisions to user needs and sustainability goals.

One challenge in team work was coordinating different perspectives on how detailed a prototype should be at each stage. Some team members focused more on visual polish while others prioritized interaction logic. Navigating these differences helped me better understand how design teams balance exploration and execution.

Working collaboratively also improved my ability to communicate design ideas clearly through sketches, prototypes, and presentations.

Takeaways:

Overall, HCDE 351 changed the way I think about prototyping. I now see prototypes not simply as representations of a final product, but as tools for thinking, communication, and exploration. The course also demonstrated how different materials and prototyping methods reveal different aspects of a design. Most importantly, the experience reinforced that design is an iterative learning process. Each prototype , no matter how simple, can reveal insights that lead to better ideas in the next iteration.

Acknowledgment:

Special thanks to my peer who collaborated with me and gave feedback on my design. Special thanks to our teaching team, TA Nichole Sams, TA Nimesh Mohanakrishnan, and the instructer Brock Craft for their incredible help towards us and valuable feedback. Special thanks to Peitong Qi for her help with organizing materials and actionable feedback.

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I used NotebookLM to help me organize my thoughts;

Writing reference:

I used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://antaresyuan.site/blog/hcde-351-a1-oxo-shower-control-interface/

HCDE 351 | Final Project: Textile Waste Management: Community Closet

Antares Yuan — Sun, 15 Mar 2026 12:00:00 GMT

Product Overview:

This process log documents the design of a Community Closet system, a clothing rental platform that helps reduce textile waste by allowing users to rent clothing from others in their community rather than purchasing new garments. The system combines a mobile application, physical kiosks, and a delivery system to enable users to easily rent, list, pick up, and return clothing.

The goal of this prototype is to explore the usability, desirability, and feasibility of the concept through multiple prototyping methods. By simulating the experience of browsing clothing on a mobile interface, picking up garments from a kiosk, and interacting with the overall rental workflow, we aim to understand whether users find the system intuitive, trustworthy, and useful in addressing the issue of clothing overconsumption.

In this project, I practiced my skills in rapid prototyping and user-centered design by collaborating with teammates to define key scenarios, building prototypes across different mediums (video, mobile, and physical), and conducting user testing to evaluate how people interact with the system. These prototypes allowed us to test our ideas quickly and at a relatively low cost while still simulating realistic user experiences.

In this log, I will describe how our team developed the concept based on the sustainability problem we identified, designed and constructed the prototypes, and conducted testing sessions to gather feedback from users. I will also reflect on key design decisions, the reasoning behind them, and how these choices support the overall goal of reducing textile waste while providing a convenient and engaging clothing rental experience.

Ideation:

The goal of this design is to develop a system-level concept that addresses the issue of textile overconsumption. **Our project follows United Nations Sustainable Development Goal 12: Ensure sustainable consumption and production patterns.** Specifically, our design goal is to reduce textile waste by enabling clothing to be shared and reused within a community instead of being purchased and discarded after limited use.

During our brainstorming process, we focused on the problem of clothing overconsumption in everyday life. Many garments are purchased for specific occasions but worn only once or twice before being stored or discarded. Although solutions such as thrifting or donation exist, large amounts of textile waste still end up in landfills each year.

We explored several possible approaches to address this issue, including clothing swap events, community donation networks, and online resale platforms. However, we identified two main limitations in existing solutions: many platforms still rely on repeated purchasing and resale, and logistics such as shipping can introduce additional environmental costs.

Product:

Based on these discussions, we developed the concept of a Community Closet, a system that allows people to rent and share clothing within a local community. Users can browse and rent clothing through a mobile application, while physical kiosks serve as local drop-off and pick-up points to reduce shipping waste. In some scenarios, drone delivery can also be used for nearby users.

This system design aims to allow multiple users to wear the same garment over time, reducing the need for repeated production and helping address the broader problem of textile waste.

System:

System diagram

Our system is built through the connection of an app (digital experience) to the packages/kiosk system (physical experience) we designed the user experience to go beyond the digital experience through questions such as: what is the most desirable way to receive packages? To ship packages? (drone) What method of delivery is sustainable (local delivery vs regional )? What is a more cost effective method for users? (Kiosk drop off) we came up with the system where users interact with the app to decide what they want, and how they receive and ship the packages, either through the drone or through a kiosk. The app further integrates with the kiosk to enable users to sign in through their device, furthering the seamless experience.

Evaluation Method:

Mobile app prototypePrototyping Method: Video scenario prototype demonstrating the full lifecycle of the system, including downloading the app, renting clothing, and receiving the item through a kiosk or drone delivery.Evaluation Method: Semi-structured interviews after participants watch the video.Evaluation Goals: Understand the desirability of the concept, including whether users find the idea appealing, whether they would consider using the system, and what concerns they may have (e.g., hygiene, trust, clothing quality, or logistics).Kiosk cardboard prototypePrototyping Method: Interactive mobile interface prototype created in Figma that simulates the clothing browsing, listing, and rental process.Evaluation Method: Moderated usability testing where participants complete specific tasks using the Figma prototype.Evaluation Goals: Evaluate the usability of the interface, including whether users can easily navigate the app, list clothing, rent items, and understand pricing and rental duration.Video prototypePrototyping Method: Cardboard prototype of a clothing drop-off and pickup kiosk.Evaluation Method: Scenario-based interaction testing where users physically interact with the kiosk to simulate dropping off or retrieving clothing.Evaluation Goals: Assess the feasibility of the physical interaction, including clarity of instructions, ease of use, and whether the kiosk size and structure support the intended interaction.Behavioral prototypePrototyping Method: Simulated real-world interaction where users place a clothing order through the mobile interface and retrieve the item from the kiosk using a QR code.Evaluation Method: Behavioral user testing with observation of user actions and follow-up questions.Evaluation Goals: Understand how users move through the end-to-end system flow, identifying confusion points between the digital interface and the physical pickup process.

Prototype:

In the sections above, I explained how we made sure we know what scenario we are designing for, then we explored ideas and then push to the final design that we should go for by following the UN sustainability goal and the design goal. In this section, I will briefly talk about what how our four prototype helped us make design decisions and push our project moving forward.

Mobile app prototype

For the design of this mobile app, we initially wanted to create a high-fidelity prototype in Figma. However, after discussions within our team and consulting with the teaching team, we decided to use AI vibecode to produce an interactive high-fidelity prototype with only the frontend and no backend. This allows users to simulate input, making the testing experience more realistic. We used FigMake to create the high-fidelity prototype, and by repeatedly confirming the requirements with the AI, we ultimately developed this high-fidelity prototype with 2 main user flows, which support users’ rental and return processes.

Mobile app: homepage

We had a lovely homepage for the user to browse through the clothes they want to rent, with the cost of clothes and clothes’s detail on it. By doing this, we keep the information being transparent so that the user will always be in the happy path.

Mobile app: Rental

This is where user can rent the clothes. They have the ability to choose the duration of their rental and the way they want to pick up. In order to better support people who are busy to maintain their sustainability goal, we also provide a drone delivery option (We try to not use car which use fossil fuel and generate greenhouse gas). We also give user an option to send out their own clothes that they seldom wear to earn credit where they can use when renting clothes from others. By doing this, we encourage user to wear clothes that already produced but not looking for new clothes. In this way this align with our goal of UN sustainability and also our design goal.

Mobile app: Upload

Just like I described above, this is where people can create their own clothes profile for others to rent. The can enter the detailed information of their clothes, specify the purchase price and daily rental rate.

Below is the FigMake link for you to try out the user flow: (if link could not work, please try the one in caption below)

https://www.figma.com/make/OMAdyKXqH4eE9j8sJjw1Zb/Clothing-Rental-App?t=rVGSCkvCTKpOFIz4-1

Kiosk cardboard prototype

At the same time, we also began the design of the kiosk. In our design, this kiosk consists of two parts: the operational machine and the locker.

Sketch of interface and kiosk design

After successfully reserving or uploading clothes, users will receive a barcode via email, and then they can come to the kiosk set up in each community, select the corresponding service (drop off/pick up), and scan the barcode to open the locker. If the user is for drop-off, after opening the locker, the display screen will guide the user to place the clothes in the correct location, and then remind the user to close the locker; if the user is for pick-up, we will inform the user that the clothes are inside after opening the locker, and remind them to close the locker after taking them out. This design aligns us better with our design goals.

Showcase of the cardboard prototype of the locker

This is the locker we used in user testing (during the behavioral prototype).

Video prototype

After completing the design of the mobile app, we designed two using scenarios based on the previous 2 user flows.

Storyboard sketch

Video prototype

Behavioral prototype

At the same time, in order to test user interaction with our mobile app and kiosk, we have designed three key testing scenarios for user interaction based on the video prototype: clothes rental, clothes upload, and clothes pick-up.

Final video demo

Summarize the above four prototypes, we have completed our final video demo, briefly showcasing our product concept and how we achieved it.

Feedback:

In class, we had a group feedback discussion. This is the feedback we received:

What works well?

The project clearly aligns with the UN Sustainable Development Goal of responsible and sustainable consumption by proposing a peer-to-peer clothing rental system that encourages reuse of clothing. The team did a good job designing a coherent system that combines a mobile interface with a physical kiosk, making the concept feel practical and grounded in real-world usage.

The mobile prototype was polished and thoughtfully designed, and it effectively demonstrated how users could browse, list, and rent clothing. Multiple prototypes (mobile UI, cardboard kiosk model, and video prototype) were used to explore different aspects of the system, which helped illustrate the overall user experience and design concept. Overall, the project successfully communicated the design objectives and showed meaningful effort in addressing a complex system.

What could be better?

While the project concept is strong, the physical prototype could be further developed to better simulate how the system would work in practice. The cardboard kiosk prototype was somewhat simple and did not fully demonstrate interactions such as clothing drop-off, pick-up workflows, or a deposit/return mechanism. Expanding the physical prototype or creating a digital kiosk interface prototype could help evaluate kiosk usability more effectively.

Additionally, the logistics of the system could be clarified, particularly how distribution works. For example, the design mentioned both delivery and kiosk pickup, but it was not entirely clear how these options would function together. Focusing on one primary distribution method or explaining the relationship between them could make the system easier to understand.

Finally, the video prototype could more clearly show users interacting with the kiosk, helping connect the mobile experience with the physical interaction in the overall system.

Takeaways:

Feedback from both my peers and my TA reveal that our design did successfully align with my design goals and stress on the pain point as well as following my scenario. But there this design have some minor issue that may or may not impact it functionality. It could be better if we,

further developed the physical kiosk prototype to better simulate how users would drop off and pick up clothing in the system.
demonstrated the kiosk interaction more clearly in the video prototype, showing how users transition from the mobile app to the kiosk.
added more functional details to the physical prototype, such as a deposit system or clearer interaction steps.

Acknowledgment:

Special thanks to my group member Rachel Berg, Stephanie Nguyen, TA Nichole Sams and Instructer Brock Craft, and all the peers from HCDE 351 Winter 2026 for their valuable feedback.

Thanks for reading! : )

Technological Appendix:

AI usage:

We used ChatGPT in correcting my grammar and typo;
We used NotebookLM to help me organize user feedbacks;
We discussed with ChatGPT of parts I should improve with the feedback I got.
We used FigMake AI to help we make the mobile app prototype.

Writing reference:

We used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://antaresyuan.site/blog/hcde-351-a6-behavioral-prototype-minecraft-ai-assistant/

HCDE 351 | A6: Behavioral Prototype: Minecraft AI Assistant

Antares Yuan — Sun, 01 Mar 2026 12:00:00 GMT

The problem

Product Overview:

This process log documents the behavioral prototype of a game strategy assistant which can help user making decision while playing the games by chatting with them in real-time. The goal of this behavioral prototype is to test out functionality and usability, where we can set up a use case where user may interact with the system, with a limited cost and fast pace of iteration. In this project, I practiced my skills of making a behavioral prototype by brainstorm the solution that we can "mock of", conducting the user testing session to check if the interaction make sense and try not to let the user notice that.

In this log, I will describe how I brainstormed with my teammates based on scenario setting we chose, set up the system and test environment, gathered feedback from users and peers, and identified parts that should be improved. I also document the reasoning behind key decisions and how these choices work better in supporting my prototype.

Ideation:

The goal of this design is to make a behavioral prototype that can be used in testing a use case where the user need to interact with the system, helping the designer quickly see how the user may interact with the system and making design decisions of how to iteration to the next step. In this section, I will explain how we brainstorm the behavioral prototype which aligned with our design goal.

The topic I pick is "Applications for a voice-operated assistant". We started brainstorming the use case ourself which need a voice-operated assistant or encounter in our daily usage. We came up with these in my head.

Usage of Voice-Operated Assistant:

I had a Amazon Alexa in my home where I use it to listen to some morning news, popular music, and as a bot to chat with me (Also it is pretty stupid).
I sometimes chat with a LLM like ChatGPT to ask some questions that I cannot explain well using only a few sentences.
I asked the Siri in my phone to set up alarm clock and check the files in my phone.
I used AI agent to help me analyze the decision I made during League of Legend, and what led to a defeat in a game.

We found out that the one that most interested us is the last one which is using AI to help with decision making during game.

Product：

An AI assistant which can be used during a LOL game to help you analyze the BP of the game, which decision should be made at this moment, and how should I do to win the game, by talking with me verbally.

After meeting with the teaching team, talking about our idea, we got several feedback and then head up towards our behavioral prototype design.

System:

System diagram

Moving from the first idea, we decided to do a game that requires less knowledge in playing and easy to mock up (well to mock up an assistant that can help you play LOL is way much harder). We decided to move to Minecraft and one of our teammate will use a voice-changer to pretend to be the assistant, creating a black box where the participant may not know this case and test out our voice-based assistant system.

Prototype:

In the sections above, I explained how we made sure we know what scenario we are designing for, then we explored ideas and then push to the final design that we should go for by following the design goal. In this section, I will briefly talk about what our final prototype is with the testing video.

Final behavioral prototype

Brief intro of our design

We conducted user testing in Minecraft using a Wizard-of-Oz methodology to simulate a coach-type voice assistant and examine users’ trust and decision-making behavior in an open-ended environment. Participants were informed that the assistant would provide strategic evaluation and directional guidance such as prioritization, risk assessment, base selection, or design direction. But would not function as a tutorial system. It did not explain game mechanics, give crafting recipes, or provide step-by-step instructions. We structured testing around three scenarios (early survival setup, creative building, and cave/ruins exploration) and observed how users formulated questions, adjusted their strategies based on coaching feedback, and reacted when procedural or technical questions were declined. The goal was to evaluate how authoritative, strategy-focused guidance influences player confidence and behavioral reliance without removing agency.

Feedback:

In class, we had a group feedback discussion. This is the feedback I received:

What works well?

**Real-time feedback felt valuable.** Our participant explicitly appreciated getting immediate feedback, which suggests the interaction loop is fast enough to support “in-the-moment” decision-making.
**Fast, natural voice interaction.** They liked that the assistant responded quickly, understood the question, and matched their situation.
**Peers saw clear use cases.** The demo critique included comments like _“I_can see how this can help to understand user focus,” which signals our value proposition landed: the prototype communicates potential and relevance even at this stage.
**Believability is already there.** Both participant + peers found it believable, meaning our concept and interaction style are convincing enough to imagine in a real product.

What could be better?

**Answer accuracy / domain knowledge (core weakness).** The participant’s main complaint is the most critical one: if it’s “not knowledgeable in the game,” trust drops fast.
**Clarity of functions (mental model mismatch).** One peer didn’t understand what the prototype does or how it responds.
**Background operation + privacy comfort.** The “does it run in the background?” concern is a UX and ethics flag
**Data collection strategy needs to be explicit.** The critique implies uncertainty about what the system tracks and how it infers “user focus.”

Takeaways:

improved the accuracy of the voice assistant’s responses by incorporating more game-specific knowledge and contextual data.
clarified the prototype’s functionality through better onboarding and clearer feedback states (e.g., listening, processing, responding).
addressed privacy concerns by clearly explaining whether the system runs in the background and giving users control over data collection.
improved transparency around how user focus is detected and what data is being collected.

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I used NotebookLM to help me organize user feedbacks;
I discussed with ChatGPT of parts I should improve with the feedback I got.

Writing reference:

I used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://antaresyuan.site/blog/hcde-351-a2-soft-goods-prototype-shoulder-bag-design/

HCDE 351 | A5: Video Prototype: Pre-sleep Phone Use Control App

Antares Yuan — Sun, 22 Feb 2026 12:00:00 GMT

Product Overview:

This process log documents the video prototype of a pre-sleep phone use control app which is a better version of social media where users may not get addicted to it then affect their sleep quality thus influenced their schedule of next day. The goal of this video prototype is to test out functionality and usability, where we can set up a use case with a limited cost and fast pace of iteration. In this project, I practiced my skills of making a video prototype by brainstorm the storyboard, set up the video shooting checklist, and then slicing frame into multiple cameras and assemble them into a whole storytelling video.

In this log, I will describe how I brainstormed based on my design scenario setting, made iteration on my story itself, gathered feedback from users and peers, and identified parts that should be improved. I also document the reasoning behind key decisions and how these choices work better in supporting my story.

Ideation:

The goal of this design is to make a video prototype that can be used in testing a use case and user scenario, helping the designer making design decisions of how to iteration to the next step. In this section, I will explain how I iterate throughout these different ideas to better align with my design goal.

The topic I pick is something related to "sleep". I started with thinking of my own pain point related to sleep. I came up with these in my head.

Painpoint:

I wanna go to bed earlier, but every time when I was lying in my bed, I found out that I got lost in the infinity scrolling in the social media content.
Malignant pre-sleep phone use made me hardly to focus on the task on the second day, or feel sleepy during the period that required my attention.
In the long term, I felt that this had behavior made me hard to focus, and impact my mental health dramatically.

Before finding some ideas by gathering inspiration from some academia paper, and thinking about how I can also stress the pain point using my design as a solution and tell the story, I first came up with the scenario setting for this story.

Scenario Setting：

Persona: "A" is a 25-year-old young adult who just step into the society from university, working for an AI start-up as a software developer.The scenario: "A" usually comes back to home form work on 6 pm in the evening, then he always plays some game and read some news online before he go to bed. After he lies on his bed, he scrolls on his phone to see the stories shared by his friends, swipes his phone to see twitter and reddit posts, watches some Tiktok short reals.

After having sense of the scenario my video and product I will be designing. I started my storyboards.

Storyboard:

Storyboard Page 1

Storyboard Page 2

Storyboard Page 3

Storyboard Page 4

In this section, based on my scenario setting, I began to think about what kind of story I should tell. I chose to set the beginning of the story at midnight, which is exactly the time when my protagonist “A” is preparing to go to bed. Initially, I want to show a long shot, showcasing the exterior of “A’s” house, with all the other rooms dark, only “A’s” room is brightly lit. Then, the camera slowly zooms in on his window, revealing him scrolling through his phone. Through a series of close-ups, the camera focuses on the phone screen, showing him deeply engrossed in social media, unable to pull himself away. (I also included a shot that shows him addicted to scrolling, with the flickering light reflecting off the phone onto his face). The conflict in the story arises from the protagonist missing an important meeting the next day due to staying up too late watching videos, leading to punishment from his leader and being exhausted both physically and mentally, deciding to start making changes. So, I set up a turning point in the story where he sees an advertisement on a website about a social media app with a sleep mode. I then let the story progress to the protagonist downloading and starting to use this app. The automatically activated sleep mode adds an extra layer of supervision to his phone use before bed, and after his swipe limit is exhausted, he chooses to go to sleep early, thus achieving better sleep.

Prototype:

In the sections above, I explained how I made sure I know what scenario I am designing for, then I explored ideas and then push to the storyboard I should go for by following the design goal. In this section, I will briefly talk about the process of making my final video prototype by iterate on the story in the storyboard.

Final video prototype

In fact, it can be seen that the final video prototype I made has undergone significant changes from before, one of the main reasons being that I discovered the limitations of my own filming. My filming equipment is the iPhone 13 Pro, without a stabilizer/tripod/monopod, and I also found that I couldn’t do aerial filming (because I don’t have a drone to assist with shooting). So I made adjustments, turning the night scene into elements like desk lamps and clocks, which are easier to obtain and still have a decent effect, to express the late night. Also, to emphasize privacy (or perhaps I haven’t found a suitable model), I chose to use a doll to act out the story (but I personally feel that the effect is actually better than using a real person); also considering the feasibility, I changed the business meeting into a scene of someone dozing off at work. The intervention part remained mostly unchanged. This is my final video prototype, aligned with my design goal, and satisfy my design scenario.

Feedback:

In class, we had a group feedback discussion. This is the feedback I received:

What works well?

Clear core problem: “I can’t fall asleep / I stay on my phone” is relatable and easy to understand.
Strong visual hook: the rabbit falling asleep is memorable and already feels like a “main character” people can follow.
Good instinct on structure: I already have a story arc (intro -> intervention -> outcome), which is exactly what these pitches want.

What could be better?

Rabbit (the toy) meaning is unclear: right now it’s cute, but not legible. Viewers need to instantly know: rabbit = you? sleep drive? progress meter? pet companion?
Needs “real interface” credibility: “show me the product.”
Missing subtitle: my title slide (or early slide) should include a subtitle that states what it is in plain language.
Background intro too long: I am spending time convincing them sleep matters; they already know.
Mechanism needs to focus on “forcing me to sleep”: “you described context but not enforcement.”

Takeaways:

Feedback from both my peers and my TA reveal that my design did successfully align with my design goals and stress on the pain point as well as following my scenario. But there this design have some minor issue that may or may not impact it functionality. It could be better if I,

clarified what the rabbit represents and how it functions within the system.
focused more on the mechanism that enforces sleep rather than extended background context.

Reflection:

Through making this video prototype, I learned that video is not just for presenting an idea, but for quickly testing whether a story, mechanism, and interaction make sense. I chose the topic of pre-sleep phone use because it is a personal pain point, which helped me build a realistic scenario and evaluate the design more critically.

The main challenge was limited filming resources, which forced me to adapt the storyboard and simplify the narrative. This made me realize that feasibility constraints can actually help sharpen the core idea. Feedback also showed that while the rabbit was visually engaging, its meaning was unclear, and that I needed to show the actual interface earlier and focus more on how the system enforces behavior change.

If I were to redo this project, I would define the role of the rabbit more clearly and make the enforcement mechanism more explicit from the start.

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I used NotebookLM to help me organize user feedbacks;
I discussed with ChatGPT of parts I should improve with the feedback I got.
I discussed with ChatGPT how I can refine my reflection.

Writing reference:

I used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://antaresyuan.site/blog/hcde-351-a2-soft-goods-prototype-shoulder-bag-design/

Inspirational reference:

Bartel, K., Scheeren, R., & Gradisar, M. (2019). Altering Adolescents’ Pre-Bedtime Phone Use to Achieve Better Sleep Health. Health Communication, 34(4), 456–462. https://doi.org/10.1080/10410236.2017.1422099

Vhaduri, S., & Poellabauer, C. (2018). Impact of different pre-sleep phone use patterns on sleep quality. Proceedings (International Conference on Wearable and Implantable Body Sensor Networks : Print), 94–97. https://doi.org/10.1109/BSN.2018.8329667

HCDE 351 | A4: 3D Printed Prototype: Toothpaste Squeezer

Antares Yuan — Sun, 15 Feb 2026 12:00:00 GMT

Product Overview:

This process log documents the design of a toothpaste squeezer where the users can use the product to squeeze out the remaining contents from a nearly empty toothpaste tube or any nearly empty tube-like item. The goal of this design is to enhance functionality and usability, I hope this product can truly help me, allowing me to reuse many makeup items that I would have otherwise thrown away due to lack of proper use, making it more environmentally friendly. In this project, I practiced my skills of building a 3 dimensional product with technics of designing a product using a 3D modeling software, and also print it out to conduct the usertesting.

In this log, I will describe how I brainstormed based on defined user needs, made design decisions based on the evaluation criteria I made to determine if my product works, gathered feedback from users and peers, and identified parts that should be improved. I also document the reasoning behind key decisions and how these choices work better in supporting my target users.

Ideation:

The goal of this design is to make a toothpaste squeezer which can be used in can be used to squeeze toothpaste and other tube-shaped items. In this section, I will explain how I iterate throughout these different ideas to better align with my design goal.

I started with thinking of my own pain point while squeezing toothpaste. I came up with these in my head.

Painpoint:

Sometimes I throw away a lot of toothpaste before it’s used up, because there’s no other way to squeeze it out.

Before finding some ideas by gathering inspiration from Pinterest and thinking about how I can also stress the pain point using my design as a solution, I first came up with key design assumption and follow these criteria to make some design decisions.

Key Design Assumption：

Feasibility: The gap and geometry between the PLA roller and the housing are sufficient to compress a standard toothpaste tube without slipping or tearing, while remaining operable with one hand.

Design Decisions:

The overall form is designed to support one-handed operation, with the roller positioned to allow continuous squeezing while stabilizing the housing against a flat surface. This decision prioritizes testing whether the printed geometry provides sufficient leverage and stability during real use.The spacing between the roller and the housing is intentionally constrained to fit standard toothpaste tubes, while allowing limited deformation of the tube material. This decision tests dimensional tolerance and compression behavior that cannot be evaluated with low-fidelity prototypes.The roller is designed as a separate printed component to allow rotation within the housing. This enables us to conduct the evaluation of PLA contact friction, axle clearance, and whether rotation meaningfully reduces shear stress on the toothpaste tube.Edges in contact with the toothpaste tube are rounded to reduce the risk of tearing during compression. This decision addresses material interaction between a rigid printed object and a flexible consumer package.

After having sense of what product I will be designing. I started my sketches.

Sketch 1–6:

Sketch 1–6

In this section, I tried different ways of squeezing toothpaste. In the first sketch, I tried using a squeezer in the shape of a box, and then in the second sketch, I tried one squeezer without any other mechanisms. I felt that the structure might be a bit difficult to squeeze out, so I added some serrated structures in the third one. Then I thought I might need a clip structure to lock the two squeezer together, which is the origin of the fourth sketch. In the fifth sketch, I explored whether it would be possible to add a slider. Later, I found that adding a rotating handle inside the box would allow for the automatic squeezing of toothpaste.

Sketch 7–9:

Sketch 7–9

In this section, I continued to explore how to better automate the rotation to achieve a perfect toothpaste squeezing experience. I began by increasing the area where the hand holds the rotating handle, while also trying to modify the part that holds the toothpaste. In the end, I chose the ninth sketch that could accommodate more and hold the remaining part on top. (I think that one satisfy my design goal and my pain point the most)

Prototype:

In the sections above, I explained how I established my evaluation criteria and made sure I know what product I am making, then I explored different ideas and then made decisions on the two I should go for making a paper prototype by following the design goal. In this section, I will briefly talk about the process of making two testable low-fidelity paper prototypes, and then use it to iterate to a better prototype in fidelity level (with CAD and 3D printing machines), and showcase how it looks.

Low-fi prototype

In this section, I explored the feasibility of this structure, simulated a flat object using a receipt, and verified an automated method by rotating the pen. Therefore, I decided to make the two parts separately in CAD software, then perform a slice model in priuser, and complete the 3D printing.

3D Printing

Final design

Final design (the other angel)

This is my final design, aligned with my design goal, passed the evaluation criteria, and satisfy my design decisions. The end of a toothpaste tube or any tube-like item can be inserted into the slot in the middle of the rotating handle, then both can be inserted into the large box. By rotating the handle, I can easily squeeze all the remaining toothpaste forward.

Feedback:

In class, I leave my materials on the table, and getting sticky notes of critique. (at that moment, I don’t have the model yet, only the CAD view, that’s why my feedback is a bit weird). This is the feedback I received:

What works well?

Strong concept / idea
Clear thought and effort
Attention to ergonomics & aesthetics
Intentional design decisions

What could be better?

Hard to evaluate without a physical prototype (now solved)
Scale & fit are unclear
Mechanism clarity
Need clearer justification of choices

Takeaways:

Feedback from both my peers and my TA reveal that my design did successfully align with my design goals and stress on the pain point as well as passing my criteria based on design decisions. But there this design have some minor issue that may or may not impact it functionality. It could be better if I,

built a quick physical prototype so people can evaluate the size, comfort, and usability instead of guessing from CAD
clearly showed scale (dimensions + photos in-hand / next to a toothpaste tube) to answer fit questions
tested with different hand sizes and documented what changed based on that feedback

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I used NotebookLM to help me organize user feedbacks;
I discussed with ChatGPT of parts I should improve with the feedback I got.

Writing reference:

I used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://antaresyuan.site/blog/hcde-351-a2-soft-goods-prototype-shoulder-bag-design/

Inspirational reference:

https://www.walmart.com/ip/Raindrops-3-Pcs-Squeeze-Toothpaste-Device-Squeezing-Tool-Roller-Dispenser-Child/16170971908?wmlspartner=wlpa&selectedSellerId=102489398&utm_source=Pinterest&utm_medium=organic

HCDE 351 | A3: Laser Cut Prototype: Smartphone Paper Prototyping Frame

Antares Yuan — Sun, 01 Feb 2026 12:00:00 GMT

Product Overview:

This process log documents the design of a smartphone paper prototyping frame where the users can use the product as a showcase and test frame for their sketched-out wireframe for their participants. The goal of this design is to enhance functionality and usability, on the basis of helping user to test out their wireframe’s user flow, I also reached the part that helps the user to conduct the user testing with this product seamlessly and intuitively. In this project, I explored how to utilize my design to better respond to the user’s wireframe testing needs (or I should say I am a user of this product myself since I often conduct the user testing myself) and practiced my skills of building a 2.5 dimensional product with technics of designing a product by parts which can be used to assemble the strong enough 3 dimensional product using inserting and other structure without any glue or other material that can stick them together.

Ideation:

The goal of this design is to make a frame for smartphone wireframe prototype which can be used in early phase user testing with build an intuitive user flow for both the interviewer who conduct the testing and the interviewee who is doing the testing. In this section, I will explain how I iterate throughout these different ideas to better align with my design goal.

I started with thinking of my own pain point while conducting user testing or being an interviewee doing the testing. I came up with these in my head.

For being an INTERVIEWER:

I can not show my participants the user flow (or say I can not get good feedback on my user flow since they are not pretty clear what the flow is like by staring at my wireframes with bounding boxes and messy arrows). They have to spend a lot of time interpreting my user flow in wireframe.
User can see all the wireframe at the same time which is not true in real applications. By knowing which step is the next step, users can easily reversely infer the step they should do to reach the next step which made me really hard to test out if all the interactions are intuitive enough for user to operate in real life.

For being an INTERVIEWEE:

The instructions during the user testing of a wireframe is always unclear. The interviewer might give me some clue but what I got most is their unclear and messy sentences on the wireframe which made me hard to follow.
I don’t have a sense of holding a smartphone while doing user testing. They always just give me several piece of paper with wireframe on it.
When I want to give feedback on the wireframe, I seldom find the part I am looking for due to the fact that it is always not that structured.

Before finding some ideas by gathering inspiration from Pinterest and thinking about how I can also stress these satisfaction points using my design as a solution, I first came up with prototype evaluation criteria and follow these criteria to make some design decisions.

Prototype Evaluation Criteria：

1. FeasibilityThe paper prototyping frame should be able to hold with only one hand and conceal a 5-inch-wide paper screens without bending or collapsing during handheld use.2. UsabilityUsers should be able to insert, remove, and swap paper screens within 3 seconds per screen without instructions.3. DesirabilityWhen holding the frame, users should report that it feels more like using a real device compared to viewing loose paper on a table.4. ImpactThe frame should allow usability tests to be conducted with minimal facilitator intervention (no need to explain orientation or where to look).

Design Decisions:

The frame is designed for one handed, portrait orientation use, mimicking typical smartphone interaction.The frame targets 6-inch-wide paper screens, consistent with modern phone dimensions.The overall appearance should resemble a real mobile device with minimal bezels, while maintaining sufficient material thickness to ensure structural stability.Screen insertion and removal mechanisms (top, side, or back access) will be explored through sketching to evaluate speed and stability trade-offs.Hand placement and grip affordances will be investigated during sketching to support comfortable one-handed use.The primary testing context is facilitator led demo testing, prioritizing fast screen swapping and minimal explanation during use.

After having sense of what product I will be designing. I started my sketches.

Sketch 1–4, 7:

Sketch 1

Sketch 2, 3

Sketch 4, 7

From sketch 1–2, I tried to test out my answer for my third design decision. The main difference here is the edge of the frame: prototype frame in sketch 1 has a much thinner edge compared to that of sketch 2. Although the thicker edge in sketch 2 might reduce the possibility of accidentally touching the middle frame (but to be honest, it doesn’t matter since it is just a piece of paper), and can hold it easily, it still can not cancel out the defect which is that it decrease the size of the wireframe a lot and make it less like a phone (cell phone recently don’t have a edge that wide). So I decided to apply thinner edge on the following sketches. For sketch 3, it is a different opening mechanism compared to the first two, where it has an opening to insert the wireframe from the top, and also an opening to drop the wireframe when all things is done. This is a testing of fourth design decision, and I like how fast it can switch between wireframe by wireframe. Prototype in sketch 4 and 7 has a different type of wireframes, which in these two sketches, wireframes are like a old-school cartoon books where all the frames are connected together in a storytelling way. Prototype in sketch 4 is like a film camera, where the wireframes are the “film”, and the frame showing wireframes is the place where film got exposed. The drawbacks of this is I can not make sure that the participant can turn to the “right” angle that show the wireframe completely. Prototype in sketch 7 has a folded paper wireframe which the user have to pull the paper on the bottom, and unfold only one piece of paper while other remains folded. This is way to complicated compared to others.

Sketch 5–6, 8–11:

Sketch 5–6, 8–11

These sketches are the lab space where I tried out different ways of inserting papers and pulling papers out, as well as ways of holding the product. I choose to do the low-fidelity paper prototype using sketches back in sketch 1 and 3 because looking back to my pain points, evaluation criteria and design decisions, I think these two are the one that align with my design goal the most. (yeah so not always picking up the last version huh?)

Prototype:

In the sections above, I explained how I established my evaluation criteria and made sure I know what product I am making, then I explored different ideas and then made decisions on the two I should go for making a paper prototype by following the design goal. In this section, I will briefly talk about the process of making two testable low-fidelity paper prototypes, and then use it to iterate to a better prototype in fidelity level (with vector editor and laser cutting machines), and showcase how it looks.

Left: Paper prototype for sketch 1; Right: Paper prototype for sketch 3

In the paper prototype for sketch 1, I made some subtle changes: I changed the way different parts are connecting to see if this is more stable. The paper prototype of sketch 1 has problem in structure since there is no parts connecting the middle of the front part of the frame and the back part of the frame, the frame is moving left and right when I held it in my hands. he paper prototype for sketch 3 has similar problem where it had connection in the middle but not four corners so these corners are movable which made it less stable. I also got inspiration from my second sketch, and decided to make multiple inserts board in the middle, and place them on the table to switch easily between different wireframes. I kept that in my mind, combined the structure of connection in these two paper prototypes, and made my final one.

Vectorized design on Inkscape

Laser cutting

Final design

This is my final design, aligned with my design goal, passed the evaluation criteria, and satisfy my design decisions. There are two cut slot on the insert board. The one on the bottom is for stabilizing the wireframe. And the smaller on the top of that is the one that can leave tips and instructions for participants. The interviewer first stabilize the wireframe, and leave some comments on it such as “You can move to this page if you click on XXX” or instructions of how to operate the page. Interviewer should make sure that these two are in opposite side of the board. Then the interviewer flip the board to hide the wireframe from the user, and allow user to remove the board from the middle of the cell phone prototype frame, with the flipped next frame waiting to be inserted. By doing this, all the pain points I listed are solved while maintaining an easy way of operating this.

Feedback:

In class, my peer and I worked in groups of three for one round of critique. In my round of critique, I gave them my prototype and let them figure out how to use it while I remained silent. This is the feedback I received:

What works well?

The prototype is stable and structurally strong, and it can stand upright without external support.
The main component can be easily inserted and removed, making the basic interaction smooth and low-effort.
The overall physical construction feels robust and reliable, which gives users confidence when handling the object.

What could be better?

The comment sticky notes part may get stuck when being pulled out, which creates friction in repeated use and could affect long-term usability.
The small cut out for comment sitcky notes is confusing in terms of its function and how it should be used.
Some users initially misunderstood the direction of interaction, suggesting that the affordance is not immediately clear.
The form feels like it consists of multiple frames or layers, which may increase cognitive load if the structure is not clearly communicated.

Takeaways:

Feedback from both my peers and my TA reveal that my design did successfully align with my design goals and stress on the pain points as well as passing my criteria based on design decisions. But there this design have some minor issue that may or may not impact it functionality. It could be better if I,

Clarify the affordance to make the direction of interaction more intuitive.
Redesign the comment sticky notes part to reduce friction and prevent it from getting stuck.
Simplify the small components so their functions are easier to understand.

Acknowledgment:

Special thanks to my group members, TA Nichole Sams and Instructer Brock Craft for their valuable feedback.

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I used NotebookLM to help me organize user feedbacks;
I discussed with ChatGPT of parts I should improve with the feedback I got.

Writing reference:

I used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://antaresyuan.site/blog/hcde-351-a2-soft-goods-prototype-shoulder-bag-design/

Inspirational reference:

https://www.pinterest.com/pin/833869687282567882/

https://www.pinterest.com/pin/1151091986036608640/

HCDE 351 | A2: Soft Goods Prototype: Shoulder Bag Design

Antares Yuan — Sun, 25 Jan 2026 12:00:00 GMT

Product Overview:

This process log documents the design of a cotton cloth shoulder bag where the users can use the main part of the bag to hold a laptop, put a keyboard, mouse and an adapter and charging line in the front pocket, and an additional velcro holder as a closing mechanism to avoid laptop falling off. The goal of this design is to enhance reliability and functionality, to make a product that I would like to use in my daily routine. In this project, I explored how to utilize my design to better respond to the my own need of having a shoulder bag for my daily routine and practiced my soft good prototype skills (using sewing machine/cutting materials/planning on how to resemble different parts of the prototype) to respond to future need of soft good prototype.

In this log, I will describe how I brainstormed based on defined user needs, made decisions on which final design I should go for, gathered feedback from users and peers, and identified parts that should be improved. I also document the reasoning behind key decisions and how these choices work better in supporting my target users.

Ideation:

The goal of this design is to make a “bag-shaped” soft good that stress on simplicity, and can hold stuff inside it and have a closing mechanism that can avoid stuff from falling off the container, using a sewing machine to connect different part together. In this section, I will explain how I iterate throughout these three ideas to better align with my design goal.

I started with thinking of which part in this design description will make it better than the product we are already using now. I tried to list out the satisfaction points (my own need of using a bag with soft material).

I would always bring my laptop with me to deal with some unexpected need of using my laptop to work/study/working on homework assignment, so I would be very happy if I have my laptop with me wherever I go.
My laptop’ battery drops very quickly so I would feel more safe if I can bring my charging line and adapter with me so that I can use my laptop without feeling a sense of insecure.
I get thirsty really quickly so that I have to drink water frequently. That’s been said, I have to bring a water bottle along with me in order to consume some water if needed.
I wish I can use a easy way to grab out stuff from my bag along with me. For now, every time I want to take out stuff from my backpack, I have to take off it then unzip if to do so, so that part could be better.

While finding some ideas by gathering inspiration from Pinterest, I thought about how I can also stress these satisfaction points using my design as a solution.

Idea 1:

Idea 1: Shoulder bag with two straps

My first idea is kinda random from the references (see technical appendix part). I chose to design the shoulder bag sewing outside to outside because I want to enhance the texture of sewing line on the bag. This is a common design of shoulder bag. I chose to do the sip as the closing mechanism because this is the first closing mechanism jump into my mind. The volume of the bag is big enough for me to put my laptop, adapter, charging line, and a water bottle in it. There is no strong connection with iteration on three of the design, they are pretty parallel in ideation phase.

Idea 2: A wave shape shoulder bag

After that, I soon had a second idea on having a better (or say more complicated) body shape of the bag. I chose to design a upside down “U” shaped on the edge of the shoulder bag because in this idea, I use two buttons as the closing mechanism which will decrease the volume of the shoulder bag. I chose to do the sewing outside to outside for the same reason. And still, this is big enough for me to put all my belongings in my satisfaction point in it. I changed the strap to the other side and then reduce it to become only one.

Idea 3: Connected strap and body shoulder bag

For the idea 3, I decided to explore the possibility of cutting the strap as I cut the main body. This simplify my way of making this bag, as well as enhance more aspects in aesthetics. I chose to step a way back to use zip as the closing mechanism because this bag has a flat edge. Also, I choose to sew the bag inside to inside in order to hide the messy sewing lines and better align with my goal of design a bag with simplicity. I also added a pocket in the front of the bag so that the storage of my laptop and other stuff separately can be seen as an additional align on simplicity. With all those been taken into consideration, the idea 3 is the best align with my goal of having a simple shoulder bag achieving my satisfaction points among three of these ideas. So I decided to go with this idea and started my first low-fidelity iteration prototype.

Prototype:

In the sections above, I explained how I explored different ideas and then made decisions on the one I should go for making a prototype by following the design goal and stressing the satisfaction points. In this section, I will briefly talk about the process of making a testable low-fidelity soft good prototype, and then use it to iterate to a better prototype in fidelity level, and showcase how it looks.

Sketching on the soft material

First of all, I used my idea 3 as a reference and sketched out the cutting lines and sewing lines on the soft material using my markers.

After that I went to the McCarty Innovation & Learning Lab (MILL) to cut out my sketch on the soft material using scissors and then use pins to make further adjustments on edges. Then I use the sewing machine to connect two part together (front and back).

Sewing inside to inside

Using sewing machine to sew

Then when I tried to sew the zip to the edge of the opening of the bag, there came the difficulty. I found that it is way too late for me to sew the zip and the edge of the top. It made me super hard to do this sewing afterwards. It took me about half an hour to fixed this problem, and here is how the first low fidelity prototype looks like.

Low-fidelity prototype on soft material

After seeing the first low fidelity prototype, I identified several parts for improvement:

One layer of this kind of material is to thin, or say not strong enough for me to hold something relatively heavy like a laptop, so I should use double layer at least in my next prototype.
Choosing to build the straps and the body together (cutting them out together without further enhancement on connection point) lead to the weakness in holding heavy items as well.
Sew the front and back part together should placed in front of the process of sewing of small component on the main part, in the whole process.
I should do a velcro as the closing mechanism instead of doing a zip because when I hold this shoulder bag, it would be easier for me to open it and take things out with a velcro but not a zip.

Keeping these in mind, I did my higher fidelity prototype.

Higher-fidelity prototype on soft material

And here are some detailed showcase.

Front pocket and velcro

Velcro closing mechanism

Sewing line on velcro

Inside of the bag (showing sewing inside to inside)

Velcro structure back

Enhanced connection of strap and main part

I also tested the reliability and functionality of the shoulder bag. I can put my laptop with a water bottle on the front so it does align with my design goal and stresses on my satisfaction point.

Testing functionality

Feedback:

In class, my peer and I worked in groups of four for one rounds of critique. Then we moved out for presenting our prototype to our TA and receicving feedback as well. In the first round of critique, I introduced my design in one sentence and talked about how I iterated through prototypes. I also talked about the key decision I made and future question on my prototype. In the second round of critique, I presented my work as well as saying the key decision I made, as the further question I had. This is the feedback I received:

**Key decision I made:** Choose to do double layer on the all the parts in this prototype.

**Further question I had:** Which part in this design makes you feel unsafe (In what situation, this might be broke)

Round 1:

What works well?

They liked the front pocket, finding it useful and well-placed.
They appreciated the use of an “X-box stitch” to reinforce the connection between the strap and the body of the bag, noting that it enhanced structural stability.
They liked that the closure is designed as a separate component, rather than being directly integrated into the bag body.
They liked how I switch the closure from a zipper to velcro. It was seen as a positive improvement, making the bag easier and faster to use.

What could be better?

They thought that the bag is a little tight when fitting a laptop (although all of them successfully fit their laptop in), suggesting that the internal space could be slightly increased for better usability.

Round 2:

TA said that the straps should be stitched together, as this would improve strength and durability.
TA mentioned I should consider adding a third layer to the pocket, which could improve organization or functionality.
For the straps, it was suggested to fold the fabric along the cut line and iron it before stitching, which may result in cleaner edges and a more polished finish.

Takeaways:

Feedback from both my peers and my TA reveal that my design did successfully align with my design goals and stress on the satisfaction points. But there this design have some minor issue that may or may not impact it functionality. It could be better if I,

Slightly increasing internal capacity for laptops
Improve strap construction techniques
Exploring additional pocket layering for better organization

Acknowledgment:

Special thanks to my group member Batuhan Celebioglu, Ashley Ma, and Josue Salgado, TA Nichole Sams and Instructer Brock Craft for their valuable feedback. Special thanks to Peitong Qi for her help with organizing materials and actionable feedback.

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I used NotebookLM to help me organize user feedbacks;
I discussed with ChatGPT of parts I should improve with the feedback I got.

Writing reference:

I used the overall structure of the blog from my last blog as a reference of this blog. Some of the words written by myself are the same (some transition sentences and words).
Here is my reference blog: https://medium.com/@chenjy4/hcde-351-a1-oxo-shower-control-interface-142da89d4355

Inspirational reference:

https://www.gap.com/browse/product.do?pid=6819760720000&tid=gpsm567927&utm_campaign=626757375924&utm_medium=PaidSocial&utm_source=Pinterest&utm_content=2680088639047&pp=0&epik=dj0yJnU9eHBUajBieDJPSHloaVd6Rm5JWXByZDI5RVIxbHNvR2YmcD0xJm49a0pJRGFKNzloT0xtYmc2d1kxakw1ZyZ0PUFBQUFBR2x3Zk9V&vid=1#pdp-page-content

https://florence-leatherhandbags.com/products/elara-leather-tote-bag?variant=51740849144118&pins_campaign_id=626757457011&utm_campaign=626757457011&utm_medium=PaidSocial&utm_source=Pinterest&utm_content=2680088739648&pp=0&epik=dj0yJnU9VURaNzBNeklCQUU4V0d6NnczaHlkamNEdjlrbjRuaWomcD0xJm49ajFqVFA4RGdpVzlGUk5iNVNUZFFWUSZ0PUFBQUFBR2x3Zk80

https://www.amazon.com/dp/B07DZBJ5RP/ref=sspa_dk_offsite_pinterest_search_1?aaxitk=7c0863bdabf7e038f0e294aa58555c0e&tqtoken=AgR4k4EN7v9O7EELABjVPh7ibTeNOaAjImt5-GoZfHtc5VcAGgABAAlyZWNpcGllbnQAC0FtYXpvbkFkc1RRAAEAEWF3cy1rbXMtaGllcmFyY2h5ACRiM2NlMjE3OS0wMzJhLTQ5NTAtOWFlZC00MTczZDMxZmNhMmEAXJREgdMFNbPLEEw8lFGOdGudX0JPBrDHDML1GtztK8nXMwFE6ZdgvB9GW5UIxGQYMe49Z8AHhziD0wejv11ZwgoKdpk5J_L6j817HA5N0QDJ9pq_3KxCRVPfiM1QAgAAEABS3cS9L4DxAyu0sCvYLoOAbPq819WNcq8ZRqGLrFj3XwlOTA1udbRXFSOWMYvkKtD_____AAAAAQAAAAAAAAAAAAAAAQAAABskN0yo_1EuqM7I4k0AV8AnRf2N1HDYcOjCcCNCY8M-edKczl9-DYbEX4of&offsiteFlag=1&tag=cashpadpinde-20&hvexpln=apex6&th=1

HCDE 351 | A1: OXO Shower Control Interface

Antares Yuan — Fri, 16 Jan 2026 12:00:00 GMT

Product Overview:

This process log documents the design of a smart shower control interface where users can use it to visualize information of the water temperature, the current volume of water, and the source of water. The goal of this design is to improve accessibility and usability during everyday shower routines. In this project, I explored how to utilize my design to better respond to the physical conditions of a bathroom environment, where users often have wet or soapy hands and limited visual attention by making a low-fidelity physical prototype and gathering feedback on possibilities on improvement from two rounds of critique and user testing.

The design consists of two connected components: an interface that is on the wall which displays real time information about water temperature, water flow volume, and water source, and a handheld wand that allows users to direct control through physical buttons and a slider.

Ideation:

The goal of this design is to make a digital shower control interface where users can use it smoothly even with soapy hands and limited visual information. In this section, I will explain how I iterate throughout these three ideas to better align with my design goal.

I started with thinking of which part in this design description will make it better than the product we are already using now. I tried to list out the pain points when I was using the shower control system in my home.

I don’t know the exact temperature during taking a shower so every time I need to turn the controlling bar left and right, trying to find the “right spot.”
There is no clear sign of how to switch between different water outputs so every time I need to guess if I am at the correct valve.
The flow of the water that comes out is not stable every time, and it is the same level of difficulty to find the “right spot” as the temperature.
All of these above becomes extremely hard when it comes to a soapy hand or limited visual information after I wet my hair.

While finding some ideas by gathering inspiration from Pinterest, I thought about how I can also stress these pain points using my design as a solution.

Idea 1:

This idea is a fully touch screen control display with the handheld wand attached magnetically on its right. I tried to curve any corner for the safety of the user because I saw a lot of smart shower control displays on Pinterest have sharp corners which made me concerned about the danger of falling down during a shower. Below the temperature there is a swiper where the user should first click the selection button to choose which control they want to adjust, and then use the swiper to edit. I realized that I partially solved the pain points by providing clear information, but the process of adjustment is still strenuous. At the same time, referring back to my design goal, where this could hardly work during limited vision or soapy hands. So I build on top of this, trying to figure out a better way to stress on pain points and align with design goals.

Ideas 2:

Compared with idea 1, idea 2 uses physical buttons to control the temperature, level of water volume, and switch between different water sources. This makes it easy to use with soapy hands because they don’t need to operate using complicated gestures which heavily increase the accessibility and usability, thus further aligning with the design goal. I added a bluetooth connected light to tell the user that this handheld wand is connected to the base part on the wall and can be modified using the buttons on the base part. This could also give users confidence when it comes to electronic control rather than mechanical control. I tried to use a physical holder to hold the wand because there is a chance that the magnetic attachment will fall down. Later on, I found out that using a horizontal layout for display will lead to confusion and the size is not necessarily to be that big. There is also a chance that the user will accidentally mis-operate. So I decided to move forward to the third idea.

Ideas 3:

Finally, in the third idea, I choose to put the display screen in the middle and have a ”O” shaped wand magnetically attached to the control screen. By doing this, I solved the problem that the wand will fall down while maintaining the aesthetic design for its appearance. The screen is for information display, where two buttons on it has a higher level of control than individual components. The one on the left is a lock where the user can avoid accidentally pressing on the button to change the temperature or switch the water source. The one with the resume icon on it is the button controlling whether this is water coming out from any of the three water sources. Users can quickly pause during the shower to use shampoo, and return back to all the same settings by simply pressing continue (resume). I transfer the button to control the temperature and the water volume, as well as the switcher of the water source to the wand because the user might want to change the temperature with limited vision and a soapy hand. In this way, they can quickly reach that goal, making this idea the top among three ideas in aligning with design goals. It also solved all of the pain points I listed above.

Prototype:

In the sections above, I explained how I iterated through ideas by following the design goal and stressing the pain points. In this section, I will briefly talk about the process of making my testable physical low-fidelity prototype and showcase how it looks.

First of all, I found a shipping box, and simplified my design to a geometric shape. The rough shape of my prototype will be a small box in the middle, a larger box representing the head with a rectangular hole in the middle, and a cylinder for the handle.

I used a pencil to punch holes on the board to make sure I knew the edge and then lined up the holes to draw the cutting line. Then I used glues and tape to make it a 3 dimensional prototype. After that, I used a sharpie to draw the display on the screen and icon on the buttons as well, cut some small pieces of cardboard to represent the texture of physical buttons.

Later on, I enhanced the details of the small holes on the head, and used sticky notes to mock a interactive interface. Here is how it finally looks.

Feedback:

In class, my peer and I worked in groups of three for two rounds of critique. In the first round of critique, I gave them my prototype and let them figure out how to use it while I remained silent. In the second round of critique, I told them the areas where I wanted more feedback: how to achieve better display effects on the screen or a better mapping relationship between the two parts. This is the feedback I received:

Round 1:

What works well?

My peers recognized that the system had two distinct parts (wall module + handheld wand).
The interface successfully communicated that the device was interactive rather than passive hardware.
My peers were able to imagine realistic usage scenarios.

What could be better?

Unclear System Mapping:

My peers did not understand the relationship between the wall module and the handheld wand.
It was unclear which part was the main controller and which was the output device.

Slider Confusion:

My peers were unsure whether the slider was: interactive or decorative/part of a touchscreen or physical control/controlling temperature or water flow
The location of the slider on the handheld felt disconnected from the wall unit.

Feature Misinterpretation:

“Pulse” was mistaken for a speaker/audio function.
The current temperature display was seen as unnecessary.
The lock/unlock button lacked a clear purpose.

Physical Design Concerns:

Handheld unit felt larger than expected.
My peers expected a hanger/hook for placing the wand.
Activation logic (mounted versus detached) was not obvious.

Round 2:

Move the slider back to the wall module to create clearer mapping.

Improve the display to better distinguish:

Between: interactive controls and information-only elements
Between: responsibilities of wall and handheld components.

After that, I conducted a semi-structured user testing. Here is what I got:

“T” button not intuitive enough for users to know that they can increase the temperature by pressing it.
Switcher should go back to the wall component.

Takeaways:

Feedback from both my peers and my participant reveal that my design did successfully align with my design goals and solved the pain points. But there this design have some minor issue that may or may not impact it functionality. It could be better if,

I strengthen the mental model to “wall = control, wand = output”.
Redesigning the “pulse” -> “Start/end”; “Lock button” -> lock sign, where it automatically locked and needs to press two times to unlock.
Add clearer physical affordances (hanger + size adjustment).

Thanks for reading! : )

Technological Appendix:

AI usage:

I used ChatGPT in correcting my grammar and typo;
I discussed with ChatGPT of the overall structure of the blog;
I used NotebookLM to help me organize user feedbacks;
I discussed with ChatGPT of how I should plan my 1-minute user testing video;
I discussed with ChatGPT of parts I should improve with the feedback I got.

Inspirational reference:

Press enter or click to view image in full size

Writing — Antares Yuan

Make your personal site agent-answerable

1. /llms.txt and /llms-full.txt

2. Pre-rendered HTML

3. Structured data, with stable IDs

4. A grounded Q&A endpoint

5. A CLI

6. A live usage signal

Cost of being public

The shape that makes it work

What it costs

Use this

HCDE 351 | Final Reflection

Project Overview:

Learning:

Accomplishment:

Contribution:

Takeaways:

Acknowledgment:

Technological Appendix:

HCDE 351 | Final Project: Textile Waste Management: Community Closet

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Acknowledgment:

Technological Appendix:

HCDE 351 | A6: Behavioral Prototype: Minecraft AI Assistant

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Technological Appendix:

HCDE 351 | A5: Video Prototype: Pre-sleep Phone Use Control App

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Reflection:

Technological Appendix:

HCDE 351 | A4: 3D Printed Prototype: Toothpaste Squeezer

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Technological Appendix:

HCDE 351 | A3: Laser Cut Prototype: Smartphone Paper Prototyping Frame

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Acknowledgment:

Technological Appendix:

HCDE 351 | A2: Soft Goods Prototype: Shoulder Bag Design

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Acknowledgment:

Technological Appendix:

HCDE 351 | A1: OXO Shower Control Interface

Product Overview:

Ideation:

Prototype:

Feedback:

Takeaways:

Technological Appendix:

1. `/llms.txt` and `/llms-full.txt`