為甚麼我們開始做 goodomo？

創作完成的那一刻，常常不是事情結束的那一刻。作品還要被說明、被理解，最後交到另一個人手上。我們開始做 goodomo，是想認真看待這段容易被當成「雜務」的過程。

一份筆記、一套模板、一個教學檔案，可能很小；但讓它成為一件別人願意使用的作品，需要很多判斷。哪些內容要留下？應該給誰看？對方需要甚麼工具才能打開？這些問題，不會在按下「匯出」之後自動消失。

這篇創刊筆記談的是我們的設計出發點，也是一份給獨立創作者的發佈前檢查表。即使你不使用 goodomo，下面的思考仍然可以帶到自己的網站、電子郵件，或任何交付作品的地方。

作品之外，也有值得設計的事

我們很容易把作品想成一個檔案。但對第一次接觸它的人來說，檔案只是其中一部分。他還需要知道，這是甚麼、適不適合自己，以及下一步該怎樣做。

例如，你做了一套每週規劃表。創作者知道每一欄的用途，讀者卻未必知道它能否列印、需要哪一種軟件，或能不能修改。這個例子不是顧客案例，只是一個常見的設計練習：試着站在尚未讀過說明的人那一邊。

把這三層分開看，便能發現問題到底出在哪裏。內容本身不清楚，要回到作品；使用方式不清楚，要補說明；取得方式不清楚，則需要重新設計交接。換一個平台，未必能代替前兩件事。

我們希望工具能減少反覆解釋的工作，同時把創作者應該作出的判斷，留在創作者手上。

先把三個交接說清楚

一個清楚的發佈過程，不一定需要很多功能。它需要讓人知道自己正處於哪一步，以及完成這一步之後會發生甚麼。

第一個交接，是把自己的理解翻譯成別人能理解的說明。第二個交接，是讓雙方對安排有相同預期。第三個交接，才是把內容交出去，讓對方真的能開始使用。

這三步可以由同一個頁面完成，也可以分散在不同地方。重點是資訊能否接得上，而不是某一個畫面是否看起來很完整。

一個可以立即做的練習

把作品頁交給一位沒有參與製作的人，先不要在旁邊解釋。請他只根據頁面，回答下面四個問題：

1. 這件作品想幫我處理甚麼？
2. 我需要哪些軟件、知識或準備？
3. 我拿到的內容包括甚麼，不包括甚麼？
4. 取得之後，我的第一步是甚麼？

答不出來的地方，通常就是最值得先補上的說明。這不是一個測試使用者是否聰明的方法，而是讓創作者找到自己習以為常、卻沒有寫出來的資訊。

清楚，比看起來萬能更重要

選工具時，一串很長的功能清單，容易讓人誤以為每個問題都有了答案。我們想先把注意力放在更具體的事上：作品能否被理解，安排能否被確認，以及內容能否被妥善交付。

下面的表不是平台排名，也不是價格比較。它把創作者需要先作的決定，與工具可以協助的地方分開。

工具能提供結構，卻不能替創作者決定作品的價值，也不能保證每一個人都能得到相同結果。承認這個界線，才比較有機會做出值得信任的工具。

為甚麼從小範圍開始

goodomo 的起點，是獨立創作者的數碼作品展示與交付。我們希望先把這個範圍理解清楚，再決定哪些事情值得加入。這是設計方向，不是所有功能都已完成或已開放的聲明。

我們不想把每一種發佈經驗都塞進同一個版型。需要安靜閱讀的文章，與需要比較內容的作品頁，應該有不同的節奏。共同的視覺語言可以讓人辨認出它們的關係，但不應該讓內容服從同一種排列。

對我們來說，小範圍也意味着可以把限制說清楚。未完成的部分，不應該藏在看似成熟的畫面後面；尚未驗證的想法，也不應該被寫成對使用者的保證。

把說明當成作品的一部分

清楚的文字，不只是語氣上的禮貌。它影響一個人能否找到資訊、理解選項，或知道自己應該做甚麼。W3C 的無障礙寫作指引建議使用有意義的標題、連結文字與清楚的指示。我們把這些建議當作編輯工作的起點，而不是靠版面漂亮就能取代的事。〔1〕

同樣地，圖片也應該有工作要做。需要傳達資訊的圖，要有文字替代；複雜的內容，則要在頁面上提供相應的解釋。W3C 的圖片替代文字決策樹，提供了可用來檢查這些選擇的方法。〔2〕

你可以先從這幾件小事開始：

• 把「按這裏」改成描述目的地的連結文字。
• 在作品說明中寫出檔案格式與使用前提。
• 為有資訊的圖片補上替代文字與圖說。
• 把限制放在作決定之前，而不是交付之後。
• 刪掉一段讀者不需要、只是自己捨不得刪掉的介紹。

這些事情不需要等待新工具。它們是今天就能為下一位讀者做的整理。

Press，是把思考留下來的地方

我們希望 goodomo Press 能留下這些過程：一個選擇為甚麼如此，一個限制怎樣被發現，一個原本不清楚的安排，怎樣變得可以理解。

這裏會從創作、工具與獨立發佈的日常開始。文章可以談我們正在做的事，也可以談與產品無關、卻對創作者有用的問題。能不能讓讀者帶走一個可以使用的想法，會比文章能不能導向註冊更重要。

開始做 goodomo，不是因為我們已經知道所有答案。而是我們認為，作品完成之後的那一段路，值得被更仔細地照顧。這是我們願意先把問題寫下來、把限制說清楚，再逐步往前做的理由。

本文談設計原則與編輯立場，不構成產品功能、交易開放狀態或成效的承諾。