完成醫院預約網站的主要畫面與操作流程規劃後，我原本以為下一步就是：

「開始把Figma的畫面切成HTML、CSS」

但實際上，如果直接看到一個畫面就開始寫HTML，很容易變成每個頁面都各寫一份。

所以在真正開始寫程式之前，我想先停下來思考一件事情：

Figma裡面設計好的畫面，到了Angular裡面要怎麼拆？

這也成為今天最重要的主題。

一、figma變成Angular概念思考

這次的專案不是單純做一個靜態網頁。

除了首頁之外，還有：

• 醫師查詢
• 醫師詳細資訊
• 登入
• 註冊
• 預約掛號
• 預約成功
• 我的預約
• 預約詳細資訊
• 個人檔案
• 就醫資訊
• 醫院介紹

如果每一個頁面都從頭開始寫，很容易遇到一個問題：

很多東西其實會一直重複。

例如網站的Header。

首頁有Header，醫師查詢頁有Header，登入頁可能也有Header。

如果每一頁都重新寫一次，不但浪費時間，之後如果要修改，也必須一頁一頁改。

所以我開始思考：

「Figma裡面已經把重複使用的UI做成Component了，那到了Angular，這次的專案不是單純做一個靜態網頁。

除了首頁之外，還有：

醫師查詢
醫師詳細資訊
登入
註冊
預約掛號
預約成功
我的預約
預約詳細資訊
個人檔案
就醫資訊
醫院介紹

如果每一個頁面都從頭開始寫，很容易遇到一個問題：

很多東西其實會一直重複。

例如網站的 Header。

首頁有 Header，醫師查詢頁有 Header，登入頁可能也有 Header。

如果每一頁都重新寫一次：

Header
Header
Header
Header

不但浪費時間，之後如果要修改，也必須一頁一頁改。

所以我開始思考：

「Figma裡面已經把重複使用的UI做成Component了，到了Angular，應該也要採用同個概念」

二、從Figma Component思考Angular Component

在Figma階段，我已經開始把重複出現的介面整理成Component。

例如：

• Button
• Header
• Footer
• Doctor Card
• FAQ
• Input

到了Angular，我希望這些設計也能轉換成實際可以重複使用的Component。

所以我開始建立這樣的對照關係：

Figma->Component->Angular Component

例如：

*Header

Header不需要每個頁面重新寫，只要建立一次，就可以在不同頁面使用。

Doctor Card

醫師查詢頁會有很多醫師卡片。

如果每一張卡片都自己寫HTML：

Doctor Card 1
Doctor Card 2
Doctor Card 3
Doctor Card 4

程式會變得很難維護。

因此可以把醫師卡片設計成：

Doctor Card Component

之後只需要提供不同的醫師資料，就可以產生不同的卡片。

這樣就不需要為每一位醫師重新設計一個卡片。

Button

按鈕也是一樣。

前面在Figma 裡，我已經統一了按鈕的設計與狀態。

到了Angular，我希望也能建立：

Button Component

讓網站中的按鈕維持一致的樣式。

例如：

• Primary Button
• Secondary Button
• Cancel Button

而不是每個頁面都自己寫一套CSS。

三、開始思考網站的整體結構

除了單一Component 之外，我也開始思考：

整個Angular 專案到底要怎麼分？

目前我的網站功能大致可以分成：

App
|
|- Header
|- Router
|
|- Home
|
|- Doctor
| |- Doctor List
| |- Doctor Detail
|
|- Login
|- Register
|
|- Appointment
| |- Appointment Registration
| |- Appointment Success
|
|- My Appointment
| |- Appointment Detail
|
|- Profile
|
|- Hospital
|
|- Footer

這時候我才發現：

Figma的頁面規劃，其實可以幫助我思考程式的架構。

前面的User Flow不只是拿來畫流程圖。

Wireframe也不只是拿來決定畫面位置。

UI Design也不只是決定顏色。

這些設計最後都會影響真正的程式結構。

四、Figma Page和Angular Component不一定是一對一

這也是我在這個階段開始注意到的一件事情。
一開始很容易產生一個想法：

「Figma有一個頁面，就建立一個Angular Component。」

但實際上不一定需要這樣。

例如：

醫師查詢頁

看起來是一個完整頁面。
但是裡面其實還可以拆成：

Doctor Search
|
|- Search Input
|- Department Filter
|- Doctor Card
|- Pagination
|- Footer

其中：

Doctor Search

比較接近一個頁面或功能。

而：

• Search Input
• Doctor Card
• Pagination

則是可以重複使用的UI元件。

所以我開始理解：

頁面是由Component組合而成，而不是每個頁面都是一整塊程式碼。

五、從「畫畫面」開始轉變成「設計系統」

做到這裡，我覺得自己對Figma的理解也和一開始不太一樣了。

一開始使用Figma時，我比較在意：

• 這個按鈕要放哪裡？
• 顏色要用什麼？
• 字體多大？
• 卡片要多寬？
• 間距是多少？

但做到後面，我開始思考：

「這個東西之後會不會在其他地方再次出現？」

如果會，就值得思考能不能把它整理成Component。

例如：

• Button
• Input
• Card
• Header
• Footer
• Doctor Card
• FAQ

這些不只是「畫面上的東西」。
它們其實也可以成為之後程式開發時的基礎。

所以我開始把設計從：

畫一個頁面

慢慢轉變成：

建立一套可以重複使用的UI

這也是我這次做專案時，第一次比較明顯感受到：

UI Design和Frontend Development其實是連在一起的。

六、為什麼這次選擇Angular？

這次專案我預計使用Angular作為前端框架。

在前面規劃技術時，我希望這個專案不只是把網站做出來，也能讓自己實際接觸企業開發常見的前端架構。

Angular本身採用Component的開發方式，這和我前面在Figma建立Component的思考方式很接近。

因此對我來說，剛好可以把前面做好的設計概念延續到程式開發。

簡單來說：

Figma Component->Angular Component

前面是在設計：

「這個UI要長什麼樣子？」

接下來則要開始思考：

「這個UI要怎麼變成真正可以運作的程式？」

七、開始思考Router與頁面之間的關係

除了Component，我也開始注意到另一個問題：

這麼多頁面要怎麼互相切換？

在Figma Prototype 裡，我是透過 Prototype Interaction 把這些頁面串起來。

但到了 Angular，就不能只靠 Figma 的 Prototype。

之後需要透過 Angular 的 Router，讓不同網址對應到不同頁面。

例如概念上：

/home
/doctors
/doctors/:id
/login
/appointments
/appointments/success
/my-appointments
/profile

這也讓我發現：

Prototype 是模擬使用者怎麼操作，而 Router 是實際讓網站頁面可以被程式管理。

兩者目的不同，但前面的 Prototype 規劃可以幫助我思考之後的路由結構。