# 易用性測試-你的程式不在乎使用者，所以你的使用者不在乎你的程式 / 卓致遠（卓學長)

{%hackmd @ModernWeb/SyA2U6SmT %}

> 共筆請從這開始
## 改善需求與開發 對立關係的關鍵行動

不是code寫完才做易用性測試，code寫完才找使用者用那不就要重構/重寫

| | UAT(x) | Usability Test (v) |
| -------- | -------- | -------- |
| what | 驗收功能有沒有Bug | 了解使用者操作Mindset |
| when | 結案時驗收時做 | 有wireframe就該做 |
| why | 確認開發完成 | 確認開發目標 |
| how | 確認功能好用 | 確認使用流程好用 |

### 流程vs功能
舉例：
- 情境：chaxxel+
- 收藏功能找不到收藏路徑
- https://channelplus.ner.gov.tw/

易用性測試是換位思考的過程 (developer => user)

> 原則:
> - 找第一次使用的人
> - 請他講給你聽（碎碎念）（不能教）
> - 階段分析(ex: 填寫前、填寫後...)
> - 找 3-5 人做測試
> - 記錄每個頁面使用者行為以及他說的話

不能因為使用者說什麼就做什麼，要找到表徵背後的原因

舉例：
1. 自然人憑證讀取不到、除了憑證外可否有其他方式登入 => 使用在登入時需要快速簡便的登入方式

易用性測試，是證據
不應該是分工的做法，而是一起付出腦力

PM -> designer -> developer :x:
PM + designer + developer :o:

X - 了解 <=> 行動
Y - 抽象 <=> 具體

~~從第三象限順時針排序：~~
第3象限 -> 第2象限 -> 第4象限 -> 第1象限
1. 見(了解+具體-3)：觀察訪談使用者 (Discover具體現況)
2. 識(了解+抽象-2)：定義UX問題 (Define抽象原因)
3. 斷(行動+抽象-1)：設計UI解答 (Design具體產出)
4. 謀(行動+具體-4)：傳遞設計價值 (Deliver抽象價值)

## 專案中利害關係人，需要的是不同的貼心

- 使用者
- 開發者
- 管理者

### 使用者：解決前後頁面迷路找不到路的問題

工程成本很高，重構很貴

### 使用者：減少操作時的不確定感及疑惑

以「身分驗證」頁為例
#### Before
- 操作指示不明確,不知如何選擇驗證方式

#### After
- 清晰的操作指示,減少認知落差的選擇錯誤

### 使用者：協助閱讀以及解決看不懂的問題

以「提示文字」頁為例
#### Before
- 一團文字眼花撩亂...

#### After
- 分段落、列點、簡化動名詞、縮短閱讀時間

### 開發者：仔細確認使用者需求，讓開發有終點

#### Before
#### After

<!-- 這應該是第二級，前面是沒記錄到 -->
## 開發者：Force Empathy讓專案有共同目標在解決使用者問題

### Before

對立要求，承受上級壓力、時間壓力

### After

Force Empathy 看到使用者的事實

## 減少承辦人獨自檢視所花費時間

### Before

在內部討論時的會議，花時間又沒效率

### After

UX 加入後 ...

## 讓開發有原則，而且可以持續累積

### Before

來自長官及各方的意見需求不斷增加,內容錯亂、反覆又重複

### After

整理所有需求，理出可沿用的開發原則

## 做了一大堆網站之後，要做的是整理
- 以使用者旅程分類
- 從階段原則細分頁面原則

舉例
1. 了解
2. 介紹
3. 列表
3. 啟用
4. 簡化
5. 快速
5. 檢視
6. 功能

e.g. 登入註冊頁面訴求：快速簡單

## (miro DEMO)

突然出現的 QRCode 造成使用者驚慌 -> 前一個畫面多一個產生 QRCode 按鈕
指引使用者並協助使用者定位,協助使用者完成整個流程

新增受扶養親屬頁面，表單中提到的稱謂是指誰？

---

> 聊天室

slide 改標題了 XD?

所以現在都是丟給ＲＤ開發時自己想（Ｘ
> QQ
> 是長官覺得好用。才是真的好用。。 ->笑著笑著就哭了
> 我們先確認使用者是長官(O)還是使用者(X)
> 公部門網站sucks
> 你各位的後台有設計幫忙嗎ＸＤ(有0沒有1)
> > 有耶。現在就在做後台的設計。。。

> 現在畫面是browser 的書籤？太遠了看不清楚
> 那時好像是 wifi 選單，不是書籤
> 一開始說要在最前面就開始考量，但是實例也還是找已完成的系統來找問題
> 所以是通靈工程師（？）
> > 現在還有不會通靈的工程師嗎？

> 改版時拿現有版本找問題蠻合理的？
> 的確使用者的回饋需要消化一下
> 易用性測試沒通過，死畫面

> 想知道一般大家公司的PM是很OPEN MIND接受大家意見的嗎？
> 有時候要 PM 的需求是不是從大老闆降~~隕石~~聖旨來的，大老闆說要的也改不太動
> 我們PM會假傳聖旨耶

> 上面說到不是分工，是一起付出腦力，具體在瀑布流開發流程的話，想知道工程師什麼時候介入討論？
> > 瀑布就不要想了，下面的喝水吧
> >
> kick-off meeting，有時候需求就看得出未來可能會有什麼問題了

工程師也需要產品思維嗎？
> 看你是工匠還是碼農。。 。
> 猴子就不用產品思維囉
> 但是很多工程師都不想思考，請PM或設計師把文件寫清楚
> 這我認同。農太久了。。。
> 規格寫清楚應該算是責任定義的問題，解釋權在工程師身上有點奇怪
> 解釋權在工程師身上，表示要完全認同工程師的產出，PM 一般來說不應該接受這種事情，這時候當然會要求 PM 寫清楚
> 通常會出事就是交給工程師解釋但又不能完全認同（Ｘ
> > 同意上面的

想要講師的文件！！！！！！
> 我也想要
> me too
> 文件好讚（流口水）

是不是應該讓ＰＭ或業務來聽這場Ｒ（整個團隊都來好了（Ｘ
> 是，還有設計
> 直接把講師請去公司吧XDD

看起來這場很讚，去錯場惹
等後續上到IT+平台？