iT邦幫忙

2026 iThome 鐵人賽

DAY 25
0

這篇進入使用者真正看得到的部分:畫面。

🧱 地基概念

兩種資訊,兩種輸入方式

  • 結構化資料(年齡、身高、體重、活動量):後面要丟進固定公式算 BMR / TDEE,必須是精準的數字或固定選項,所以用輸入框跟選項卡片
  • 模糊的生活細節(愛吃什麼、哪餐外食):很難用選項窮舉,所以留一個自由文字欄位交給 AI 理解

https://ithelp.ithome.com.tw/upload/images/20261008/201839591AVnU1NyWw.png
https://ithelp.ithome.com.tw/upload/images/20261008/20183959wqoViBdmMM.png

🔧 欄位設計

基本資料:只問公式真的用得到的

  • 生理性別(單選):BMR 公式男女係數不同,所以問的是「生理性別」而不是一般的性別認同
  • 年齡、身高、體重:同樣是 BMR 公式的必要輸入。三個欄位並排,因為它們本質上是同一類「身體數據」,視覺上放一起使用者比較不會覺得在填很多東西
  • 畫面上直接標註適用範圍:「僅適用於一般成年人,不含兒童、長輩、疾病或孕婦」。這不是免責聲明而已,是誠實告訴使用者這個工具的邊界,避免特殊族群拿到不適合的數字

活動量:

  • 三個等級,「較低(靜態居多)/中等(每週運動約 3 天)/較強(每週運動約 5 天)」。其實應該還有「較高」「激烈」這兩個選項,但因為要長時間運動或體力勞動才達成條件,一般上班族幾乎用不到,所以這次專案沒有使用。
  • 每張卡片都附一句具體描述(每週運動幾天),因為「中等」對每個人的定義都不一樣,不給錨點,使用者只能靠感覺亂選
  • 用卡片而不是下拉選單:三個選項一眼看完,不用點開才知道有什麼

飲食風格:像標籤一樣的按鈕

普通、高蛋白、低脂、高碳水,用圓角標籤式按鈕。這裡的選項沒有「描述」需求,字面就夠清楚,所以做得比活動量卡片更輕量。

生活型態:只問會影響菜單的事

  • 有吃消夜、平常會自己煮飯:
    用 checkbox,是非題,一秒完成
  • 外食比例(很少/偶爾/常常/幾乎都外食):
    這個最影響 AI 要設計什麼樣的菜單,因為外食族要選便利商店、便當店買得到的東西,自煮族可以給食材清單。用四段按鈕,不讓使用者填百分比,因為沒人真的算得出自己外食幾 %
  • 飲食禁忌/過敏原(選填):
    放最後而且標「選填」。過敏原關係到安全,所以一定要有位置;但不是人人都有,所以不強迫
  • 捨棄進食時間:
    本來有設計要填寫三餐的進食時間,但後來沒有在畫面上做成欄位。因為多數人時間不固定,硬填反而失真,這類細節改交給自由文字欄位描述

自由文字:用範例降低「不知道寫什麼」的壓力

空白的大輸入框最可怕,使用者不知道要寫什麼,所以我做了兩件事:

  • 標題用「跟我們聊聊你平常怎麼吃」,語氣像聊天,不像填表
  • 放一段灰色虛線框的範例:「早餐常常不吃,中午吃便當,晚上家裡煮口味偏鹹……」。看過範例,使用者就知道要寫到什麼程度

並且標示「選填」,因為不寫也能得到基本結果,只是菜單比較通用。

結果區塊的順序:模擬人接收資訊的節奏

  1. ResultsPanel:先看數字(RMR、TDEE、三大營養素)
  2. FoodGroupPanel:再看目標(六大類各吃幾份)
  3. DietaryAnalysisPanel:再看 AI 懂了什麼
  4. MenuPanel:最後看菜單

這個順序是從「我的身體需要多少」到「那我該吃什麼」,由抽象到具體。第三步特別重要:先讓使用者看到 AI 對自己的理解,再看菜單,菜單才有說服力。沒填結果前,畫面不是空白,而是一個提示框說明「填完後這裡會顯示什麼」,讓使用者知道方向。

Yes

Hover 說明:專有名詞不能讓人看不懂

RMR、TDEE、豆魚蛋肉類、全穀雜糧類,對營養師是常識,對一般人是外星語。所以每張結果卡片滑過去會跳出說明(六大類還會附舉例)。專業名詞不省略,但是把解釋放在「需要的時候才出現」,畫面才不會被說明文字塞滿。

白天/夜間模式:

使用者可能在晚上、昏暗的房間裡填表或看菜單,一整面白底的畫面會很刺眼。所以右上角放了一顆切換按鈕,一鍵就能在白天模式跟夜間模式之間切換。夜間模式用咖啡棕、陶土紅、米白這組顏色,白天模式維持明亮的綠色系,呼應「飲食、營養」的溫馨的主題。切換時整個畫面(表單、卡片、提示框)是一起換色,不會出現只有一半變深色的狀況

⚙️ 技術選用:只講跟設計有關的

  • React state + 即時計算:欄位值存在 state,改了畫面自動更新,才做得到早期的即時回饋
  • npm workspaces 共用型別:前端直接 import 營養計算模組的型別與函式,欄位的選項(像活動量的 sedentary、light)在前後端是同一份定義,不會出現前端選項後端不認得的狀況
  • Tailwind:樣式直接寫在元件上,要調間距、斷點很快,適合邊做邊改畫面的階段

小結

前端不只是「把欄位排出來」。結構化資料用精準的輸入、模糊的生活細節交給自由文字,能選的不讓人打,專有名詞用 hover 隨需解釋,結果依資訊接收的節奏排序,這些才是畫面真正的設計。不過目前表單按下按鈕之後,資料到底會送去哪裡?下一篇 Day26 來串接真正的 API。


上一篇
Day24 - S3 到底是不是 Database?
系列文
營養師想做一個飲食建議產品 共 25 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言