Sierro:打造無螢幕硬體背後的數位體驗

Sierro:打造無螢幕硬體背後的數位體驗

Sierro:打造無螢幕硬體背後的數位體驗

從 0 到 1 打造家用備用電源的手機端體驗,涵蓋首次設定、即時監控與日常控制

從 0 到 1 打造家用備用電源的手機端體驗,涵蓋首次設定、即時監控與日常控制

從 0 到 1 打造家用備用電源的手機端體驗,涵蓋首次設定、即時監控與日常控制

Role

Role

Role

Solo Product Designer

Solo Product Designer

Solo Product Designer

Timeline

Timeline

Timeline

May – June 2026 · 2 months · Pre-launch

May – June 2026 · 2 months · Pre-launch

May – June 2026 · 2 months · Pre-launch

Team

Team

Team

Founder · Engineers

Founder · Engineers

Founder · Engineers

Project Type

Project Type

Project Type

0→1 ·軟硬體整合· B2C · 手機端產品設計·iOS & Android

0→1 ·軟硬體整合· B2C · 手機端產品設計·iOS & Android

0→1 ·軟硬體整合· B2C · 手機端產品設計·iOS & Android

1. 專案亮點

1. 專案亮點

1300+ 位支持者

1300+ 位支持者

產品在 Kickstarter 平台發表,達到 1300+ 支持者

產品在 Kickstarter 平台發表,達到 1300+ 支持者

$900K+

$900K+

群眾募資金額

群眾募資金額

0→1 產品設計

0→1 產品設計

負責 5 大核心模組、20+ 關鍵流程的 UX 設計

負責 5 大核心模組、20+ 關鍵流程的 UX 設計

從設計到開發落地

從設計到開發落地

定義互動規格、介面狀態與開發所需設計素材

定義互動規格、介面狀態與開發所需設計素材

1. 專案亮點

1300+ 位支持者

產品在 Kickstarter 平台發表,達到 1300+ 支持者

$900K+

群眾募資金額

0→1 產品設計

負責 5 大核心模組、20+ 關鍵流程的 UX 設計

從設計到開發落地

定義互動規格、介面狀態與開發所需設計素材

  1. 我的貢獻

  1. 我的貢獻

作為專案中唯一的產品設計師,我負責 Sierro App 從規劃到落地的完整設計,包含核心流程、互動邏輯、產品規格、設計系統,以及上線所需的視覺素材。

作為專案中唯一的產品設計師,我負責 Sierro App 從規劃到落地的完整設計,包含核心流程、互動邏輯、產品規格、設計系統,以及上線所需的視覺素材。

0->1 體驗設計

產品規格

設計落地與上線

從首次設定到日常裝置管理,規劃 Sierro App 的完整使用體驗。

Onboarding

裝置設定

監控儀表板

通知

設定

UX

規格

交付

從首次設定到日常裝置管理,規劃 Sierro App 的完整使用體驗。

Onboarding

裝置設定

監控儀表板

通知

設定

  1. 我的貢獻

作為專案中唯一的產品設計師,我負責 Sierro App 從規劃到落地的完整設計,包含核心流程、互動邏輯、產品規格、設計系統,以及上線所需的視覺素材。

0->1 體驗設計

產品規格

設計落地與上線

從首次設定到日常裝置管理,規劃 Sierro App 的完整使用體驗。

Onboarding

裝置設定

監控儀表板

通知

設定

  1. 專案背景

  1. 專案背景

  1. 專案背景

Sierro 是一套 家用備援電力系統,能在停電時持續為冰箱、Wi-Fi 路由器、醫療設備等重要家用裝置供電;搭配的行動 App 則負責裝置設定、狀態監控與控制。

Sierro 是一套 家用備援電力系統,能在停電時持續為冰箱、Wi-Fi 路由器、醫療設備等重要家用裝置供電;搭配的行動 App 則負責裝置設定、狀態監控與控制。

Sierro 是一套 家用備援電力系統,能在停電時持續為冰箱、Wi-Fi 路由器、醫療設備等重要家用裝置供電;搭配的行動 App 則負責裝置設定、狀態監控與控制。

01 為什麼 App 如此重要?

01 為什麼 App 如此重要?

01 為什麼 App 如此重要?

硬體本身沒有螢幕或操作介面。 從初始設定、裝置狀態、能源監控、控制到異常排除,都必須透過行動 App 完成,因此 軟體成為使用者與產品互動的主要介面。

硬體本身沒有螢幕或操作介面。 從初始設定、裝置狀態、能源監控、控制到異常排除,都必須透過行動 App 完成,因此 軟體成為使用者與產品互動的主要介面。

硬體本身沒有螢幕或操作介面。 從初始設定、裝置狀態、能源監控、控制到異常排除,都必須透過行動 App 完成,因此 軟體成為使用者與產品互動的主要介面。

這也成為整個設計過程中的核心問題:

這也成為整個設計過程中的核心問題:

這也成為整個設計過程中的核心問題:

我們如何透過軟體,讓沒有螢幕的硬體系統

依然清楚、易懂且值得信賴?

我們如何透過軟體,讓沒有螢幕的硬體系統

依然清楚、易懂且值得信賴?

我們如何透過軟體,讓沒有螢幕的硬體系統

依然清楚、易懂且值得信賴?

02 為熟悉技術的使用者而設計

02 為熟悉技術的使用者而設計

02 為熟悉技術的使用者而設計

早期使用者大多熟悉家用能源與備援系統,因此對 詳細數據與進階控制 有更高的期待。但熟悉技術,並不代表介面可以省略必要的說明。

早期使用者大多熟悉家用能源與備援系統,因此對 詳細數據與進階控制 有更高的期待。但熟悉技術,並不代表介面可以省略必要的說明。

早期使用者大多熟悉家用能源與備援系統,因此對 詳細數據與進階控制 有更高的期待。但熟悉技術,並不代表介面可以省略必要的說明。

因此,Sierro App 的設計需要提供足夠的深度,同時避免把產品本身的複雜性轉嫁給使用者。

因此,Sierro App 的設計需要提供足夠的深度,同時避免把產品本身的複雜性轉嫁給使用者。

因此,Sierro App 的設計需要提供足夠的深度,同時避免把產品本身的複雜性轉嫁給使用者。

  1. 設計挑戰

  1. 設計挑戰

01 引導使用者完成第一次裝置連線

01 引導使用者完成第一次裝置連線

問題

問題

設定流程需要多項權限,但不需要一次全部取得

設定流程需要多項權限,但不需要一次全部取得

藍芽 (Bluetooth) 與區域網路 (Local Network) 權限是連線裝置的必要條件,而通知則是在完成設定後才開始產生價值。若一開始就要求所有權限,反而會在使用者理解用途前增加操作阻力。

藍芽 (Bluetooth) 與區域網路 (Local Network) 權限是連線裝置的必要條件,而通知則是在完成設定後才開始產生價值。若一開始就要求所有權限,反而會在使用者理解用途前增加操作阻力。

設計原則

設計原則

在需要的情境下提出請求,並先解釋原因

在需要的情境下提出請求,並先解釋原因

使用者意圖

使用者意圖

→

→

說明原因

說明原因

→

→

請求權限

請求權限

我將每項權限安排在最相關的操作節點:使用者選擇連線裝置時,才請求 Bluetooth 與區域網路權限;完成設定後,再請求通知權限。每次系統跳出權限要求前,都先清楚說明用途。

我將每項權限安排在最相關的操作節點:使用者選擇連線裝置時,才請求 Bluetooth 與區域網路權限;完成設定後,再請求通知權限。每次系統跳出權限要求前,都先清楚說明用途。

從「一次要求所有權限」到「在對的時機提出請求」

從「一次要求所有權限」到「在對的時機提出請求」

我沒有將所有權限集中在流程一開始,而是將每個請求安排在 使用者能理解其用途的時機。

我沒有將所有權限集中在流程一開始,而是將每個請求安排在 使用者能理解其用途的時機。

在每次權限請求前提供脈絡

在每次權限請求前提供脈絡

02 為不同監控需求選擇合適的資料視覺化

02 為不同監控需求選擇合適的資料視覺化

問題

問題

同一種圖表,無法同時滿足所有監控需求

同一種圖表,無法同時滿足所有監控需求

不同時間範圍下,使用者有時需要掌握 連續的能源變化趨勢,有時則需要 比較不同日期的數據。若所有畫面都使用相同圖表,反而會降低趨勢或比較資訊的易讀性。

不同時間範圍下,使用者有時需要掌握 連續的能源變化趨勢,有時則需要 比較不同日期的數據。若所有畫面都使用相同圖表,反而會降低趨勢或比較資訊的易讀性。

設計原則

設計原則

依照使用者閱讀數據的方式,選擇合適的視覺化

依照使用者閱讀數據的方式,選擇合適的視覺化

我根據不同時間範圍下的 監控目的與易讀性 選擇圖表,同時盡可能維持一致的操作方式。

我根據不同時間範圍下的 監控目的與易讀性 選擇圖表,同時盡可能維持一致的操作方式。

探索 — 比較不同的資料視覺化方式

探索 — 比較不同的資料視覺化方式

我比較不同圖表在 趨勢閱讀、數據比較與視覺強調 上的差異。

我比較不同圖表在 趨勢閱讀、數據比較與視覺強調 上的差異。

設計決策

設計決策

我沒有強求所有時間範圍使用相同圖表,也沒有為每個畫面設計不同形式,而是判斷哪些地方需要一致、哪些地方需要因監控目的而調整。

我沒有強求所有時間範圍使用相同圖表,也沒有為每個畫面設計不同形式,而是判斷哪些地方需要一致、哪些地方需要因監控目的而調整。

重點不是讓每個畫面都有不同的圖表,而是判斷何時「一致」更重要、何時「差異」能帶來更好的閱讀體驗。

重點不是讓每個畫面都有不同的圖表,而是判斷何時「一致」更重要、何時「差異」能帶來更好的閱讀體驗。

四種時間範圍維持一致的操作方式,只有在監控需求改變時才調整圖表:連續趨勢採用「折線+面積圖」,逐日比較則使用「雙柱狀圖」。

四種時間範圍維持一致的操作方式,只有在監控需求改變時才調整圖表:連續趨勢採用「折線+面積圖」,逐日比較則使用「雙柱狀圖」。

03 為快速瀏覽而設計的裝置管理

03 為快速瀏覽而設計的裝置管理

問題

問題

外觀相似的硬體,讓裝置辨識比想像中更困難

外觀相似的硬體,讓裝置辨識比想像中更困難

Sierro 使用者可能同時管理多台外觀相似、但支援不同家用設備的備援電源。首頁需要讓使用者能 快速辨識裝置、掌握狀態並進行控制。

Sierro 使用者可能同時管理多台外觀相似、但支援不同家用設備的備援電源。首頁需要讓使用者能 快速辨識裝置、掌握狀態並進行控制。

設計原則

設計原則

優先呈現辨識、狀態與控制

優先呈現辨識、狀態與控制

我以使用者需要快速回答的三個問題建立卡片資訊層級:這是哪個裝置?現在狀態如何?我可以做什麼?並以此作為裝置卡片與首頁架構的設計依據。

我以使用者需要快速回答的三個問題建立卡片資訊層級:這是哪個裝置?現在狀態如何?我可以做什麼?並以此作為裝置卡片與首頁架構的設計依據。

探索 01 — 什麼最能代表一台裝置?

探索 01 — 什麼最能代表一台裝置?

產品外觀 vs. 使用情境

產品外觀 vs. 使用情境

我曾嘗試以產品外觀作為主要辨識方式,但不同容量的 Sierro 機型外型相近,在小尺寸卡片上很難快速區分。

我曾嘗試以產品外觀作為主要辨識方式,但不同容量的 Sierro 機型外型相近,在小尺寸卡片上很難快速區分。

對備援電源而言,「它支援什麼」比「它長什麼樣」更有辨識度

對備援電源而言,「它支援什麼」比「它長什麼樣」更有辨識度

使用者通常是為特定需求購買備援電源,例如在停電時維持冰箱、CPAP 或 Wi-Fi 路由器運作。因此,我將 可自訂的使用情境圖示作為主要視覺線索,Sierro 型號則作為次要資訊。

使用者通常是為特定需求購買備援電源,例如在停電時維持冰箱、CPAP 或 Wi-Fi 路由器運作。因此,我將 可自訂的使用情境圖示作為主要視覺線索,Sierro 型號則作為次要資訊。

探索 02 — 使用者需要多高的資訊密度?

探索 02 — 使用者需要多高的資訊密度?

確定卡片的資訊層級後,下一個問題是:首頁的第一屏(不滑動的情況下)需要呈現多少台裝置?

確定卡片的資訊層級後,下一個問題是:首頁的第一屏(不滑動的情況下)需要呈現多少台裝置?

為常見情境設計,而非追求最大資訊容量

為常見情境設計,而非追求最大資訊容量

我比較了緊湊的網格、大尺寸列表,以及可切換網格/列表的方案。但多數使用者預期只會管理 1–3 台 Sierro 裝置,為了提高資訊密度而增加操作複雜度,對典型使用情境幫助有限。

我比較了緊湊的網格、大尺寸列表,以及可切換網格/列表的方案。但多數使用者預期只會管理 1–3 台 Sierro 裝置,為了提高資訊密度而增加操作複雜度,對典型使用情境幫助有限。

最終設計

最終設計

以典型使用情境為核心的首頁

以典型使用情境為核心的首頁

最終設計結合 以使用情境為主的裝置辨識方式,以及針對典型 1–3 台裝置 最佳化的列表版型。

最終設計結合 以使用情境為主的裝置辨識方式,以及針對典型 1–3 台裝置 最佳化的列表版型。

  1. 設計挑戰

01 引導使用者完成第一次裝置連線

問題

設定流程需要多項權限,但不需要一次全部取得

藍芽 (Bluetooth) 與區域網路 (Local Network) 權限是連線裝置的必要條件,而通知則是在完成設定後才開始產生價值。若一開始就要求所有權限,反而會在使用者理解用途前增加操作阻力。

設計原則

在需要的情境下提出請求,並先解釋原因

使用者意圖

→

說明原因

→

請求權限

我將每項權限安排在最相關的操作節點:使用者選擇連線裝置時,才請求 Bluetooth 與區域網路權限;完成設定後,再請求通知權限。每次系統跳出權限要求前,都先清楚說明用途。

從「一次要求所有權限」到「在對的時機提出請求」

我沒有將所有權限集中在流程一開始,而是將每個請求安排在 使用者能理解其用途的時機。

在每次權限請求前提供脈絡

02 為不同監控需求選擇合適的資料視覺化

問題

同一種圖表,無法同時滿足所有監控需求

不同時間範圍下,使用者有時需要掌握 連續的能源變化趨勢,有時則需要 比較不同日期的數據。若所有畫面都使用相同圖表,反而會降低趨勢或比較資訊的易讀性。

設計原則

依照使用者閱讀數據的方式,選擇合適的視覺化

我根據不同時間範圍下的 監控目的與易讀性 選擇圖表,同時盡可能維持一致的操作方式。

探索 — 比較不同的資料視覺化方式

我比較不同圖表在 趨勢閱讀、數據比較與視覺強調 上的差異。

設計決策

我沒有強求所有時間範圍使用相同圖表,也沒有為每個畫面設計不同形式,而是判斷哪些地方需要一致、哪些地方需要因監控目的而調整。

重點不是讓每個畫面都有不同的圖表,而是判斷何時「一致」更重要、何時「差異」能帶來更好的閱讀體驗。

四種時間範圍維持一致的操作方式,只有在監控需求改變時才調整圖表:連續趨勢採用「折線+面積圖」,逐日比較則使用「雙柱狀圖」。

03 為快速瀏覽而設計的裝置管理

問題

外觀相似的硬體,讓裝置辨識比想像中更困難

Sierro 使用者可能同時管理多台外觀相似、但支援不同家用設備的備援電源。首頁需要讓使用者能 快速辨識裝置、掌握狀態並進行控制。

設計原則

優先呈現辨識、狀態與控制

我以使用者需要快速回答的三個問題建立卡片資訊層級:這是哪個裝置?現在狀態如何?我可以做什麼?並以此作為裝置卡片與首頁架構的設計依據。

探索 01 — 什麼最能代表一台裝置?

產品外觀 vs. 使用情境

我曾嘗試以產品外觀作為主要辨識方式,但不同容量的 Sierro 機型外型相近,在小尺寸卡片上很難快速區分。

對備援電源而言,「它支援什麼」比「它長什麼樣」更有辨識度

使用者通常是為特定需求購買備援電源,例如在停電時維持冰箱、CPAP 或 Wi-Fi 路由器運作。因此,我將 可自訂的使用情境圖示作為主要視覺線索,Sierro 型號則作為次要資訊。

探索 02 — 使用者需要多高的資訊密度?

確定卡片的資訊層級後,下一個問題是:首頁的第一屏(不滑動的情況下)需要呈現多少台裝置?

為常見情境設計,而非追求最大資訊容量

我比較了緊湊的網格、大尺寸列表,以及可切換網格/列表的方案。但多數使用者預期只會管理 1–3 台 Sierro 裝置,為了提高資訊密度而增加操作複雜度,對典型使用情境幫助有限。

最終設計

以典型使用情境為核心的首頁

最終設計結合 以使用情境為主的裝置辨識方式,以及針對典型 1–3 台裝置 最佳化的列表版型。

  1. 設計系統

  1. 設計系統

  1. 設計系統

隨著產品擴展至更多使用流程,我建立了一套包含 20+ 個可重複使用元件 的設計系統,涵蓋基礎規範、版面配置、核心元件、表單控制、導覽、回饋、卡片與視覺素材。

隨著產品擴展至更多使用流程,我建立了一套包含 20+ 個可重複使用元件 的設計系統,涵蓋基礎規範、版面配置、核心元件、表單控制、導覽、回饋、卡片與視覺素材。

隨著產品擴展至更多使用流程,我建立了一套包含 20+ 個可重複使用元件 的設計系統,涵蓋基礎規範、版面配置、核心元件、表單控制、導覽、回饋、卡片與視覺素材。

除了可重複使用的 UI 元件外,我也定義了 互動模式、元件狀態與行為規則,確保產品持續迭代時,體驗仍能保持一致,並讓設計能直接銜接開發實作。

除了可重複使用的 UI 元件外,我也定義了 互動模式、元件狀態與行為規則,確保產品持續迭代時,體驗仍能保持一致,並讓設計能直接銜接開發實作。

除了可重複使用的 UI 元件外,我也定義了 互動模式、元件狀態與行為規則,確保產品持續迭代時,體驗仍能保持一致,並讓設計能直接銜接開發實作。

  1. 成長與反思

  1. 成長與反思

1

1

不能只設計 happy path

不能只設計 happy path

做硬體產品時,很多例外狀況其實才是設計的重點。裝置可能連不上、斷線,或出現不同狀態。我學到要更早和工程師確認這些情況,並把每個狀態下使用者會看到什麼、接下來能做什麼都想清楚。

做硬體產品時,很多例外狀況其實才是設計的重點。裝置可能連不上、斷線,或出現不同狀態。我學到要更早和工程師確認這些情況,並把每個狀態下使用者會看到什麼、接下來能做什麼都想清楚。

2

2

專業使用者也需要清楚的說明

專業使用者也需要清楚的說明

功能越複雜,越不能假設使用者自然就會懂。Sierro 有不少能源與硬體相關資訊,即使使用者本身熟悉這類產品,介面還是需要說清楚數據代表什麼、功能怎麼運作,而不是把複雜度直接丟給使用者。

功能越複雜,越不能假設使用者自然就會懂。Sierro 有不少能源與硬體相關資訊,即使使用者本身熟悉這類產品,介面還是需要說清楚數據代表什麼、功能怎麼運作,而不是把複雜度直接丟給使用者。

3

3

畫 UI 之前,先把產品想清楚

畫 UI 之前,先把產品想清楚

這個專案很多重要的設計決定,其實不是發生在畫畫面的時候。整理流程、補齊各種狀態、確認互動規則,這些工作反而讓產品變得更完整,也讓後續設計和開發更容易對齊。

這個專案很多重要的設計決定,其實不是發生在畫畫面的時候。整理流程、補齊各種狀態、確認互動規則,這些工作反而讓產品變得更完整,也讓後續設計和開發更容易對齊。

  1. 成長與反思

1

不能只設計 happy path

做硬體產品時,很多例外狀況其實才是設計的重點。裝置可能連不上、斷線,或出現不同狀態。我學到要更早和工程師確認這些情況,並把每個狀態下使用者會看到什麼、接下來能做什麼都想清楚。

2

專業使用者也需要清楚的說明

功能越複雜,越不能假設使用者自然就會懂。Sierro 有不少能源與硬體相關資訊,即使使用者本身熟悉這類產品,介面還是需要說清楚數據代表什麼、功能怎麼運作,而不是把複雜度直接丟給使用者。

3

畫 UI 之前,先把產品想清楚

這個專案很多重要的設計決定,其實不是發生在畫畫面的時候。整理流程、補齊各種狀態、確認互動規則,這些工作反而讓產品變得更完整,也讓後續設計和開發更容易對齊。

其他專案

其他專案

其他專案

其他專案

Let's connect

hanshin.shing.917@gmail.com

www.linkedin.com/in/hannah-shing

© Hannah Shing 2026

Let's connect

hanshin.shing.917@gmail.com

www.linkedin.com/in/hannah-shing

© Hannah Shing 2026

Let's connect

hanshin.shing.917@gmail.com

www.linkedin.com/in/hannah-shing

© Hannah Shing 2026