如何迭代獲得成功的內容驅動網站
已發表: 2022-03-10如果像我一樣，您將大部分時間都花在內容驅動的網站上，那麼您可能會覺得自己被排除在酷孩子的聚會之外。 在提供大量信息而不是殺手級 Web 應用程序時，敏捷、持續迭代和用戶反饋等最佳實踐並不能很好地發揮作用。
當我談論內容驅動的網站時，我指的是任何主要目的是傳達信息而不是完成任務的網站。 通常這些是營銷驅動的網站，但它們可以提供客戶支持或具有學術或新聞角色。 它們確實允許用戶完成一些任務，例如註冊時事通訊，但這只是其目的的一小部分。
不幸的是，我們中的許多人創建內容驅動網站的方式並不是很理想，我們需要為此做點什麼。
我們如何構建內容驅動網站的問題
這些網站通常從錯誤的前提開始。 我們首先問自己：“我們想說什麼？” 而不是“用戶想知道什麼？” 這種心態源於為其他渠道創建內容。 有必要抓住一個人的注意力並儘可能長時間地保持它的渠道，但在設計網站時，前提是不同的。 人們選擇訪問該網站，因此在某種程度上已經表達了興趣。 重點是讓他們滿意地回答他們的問題，而不是吸引他們的注意力。
但這並不是我們傾向於處理內容驅動網站的唯一問題。 在許多情況下，它們仍然是使用類似於瀑布而不是敏捷的過程來創建的。
- 我們創建設計並讓他們簽字。
- 我們在內容管理系統中構建設計模板。
- 我們將內容添加到 CMS。
通常設計是在我們看到任何內容之前創建的，因此兩者之間幾乎沒有關係。 內容基本上只是倒入設計桶中！
我們當中更勤奮的人拒絕開始設計，直到我們有一些真正的內容可以使用，但這通常會導致其他人急於復制以防止項目延遲。
當然，還有可用性測試。 通常它被忽略，因為我們仍在添加內容直到發布之日。 但即使它確實發生了，也往往是在項目接近尾聲時，沒有人想要改變事物的麻煩和成本。
如果這一切聽起來很熟悉，請不要灰心。 近年來，我一直在嘗試一種不同的方法，而且在大多數情況下，它似乎奏效了。 這是一種合作開發設計和內容的方法，同時允許在整個過程中進行定期測試。
啟動內容驅動網站的開發
我傾向於像您期望的那樣啟動內容驅動的網站項目。 我首先為站點建立一個業務目標的優先列表，以便我們可以衡量成功並清楚它的角色應該是什麼。 但在那之後，事情很快就偏離了我經常遇到的標準瀑布流程。
與其立即投入到有關品牌信息的設計和討論中，我更願意專注於更好地了解將訪問該網站的人。 誠然，進行前期用戶研究遠非革命性的。 但令人驚訝的是，在許多組織中這種情況很少發生——即使在 2017 年也是如此。
可能稍微不尋常的是，我的研究通常側重於確定用戶在訪問網站時遇到的問題。 來自首次訪問者和返回者的問題。
收集這些問題相對簡單。 我們首先採訪用戶。 但是，您可以與之交談的用戶數量是有限的。 另一種方法是在您現有的網站上進行調查，詢問用戶他們有什麼問題。 最後，與面向客戶的員工（例如呼叫中心的員工）交談會產生大量他們反复聽到的問題。
最終的問題清單很可能會很廣泛，但這沒關係。 然而，其中一些問題將比其他問題更重要。 我們需要識別這些以確保它們很容易找到並且不會在過多的不太重要的查詢中丟失。
這就是 Gerry McGovern 的頂級任務分析可以提供幫助的地方。 調查用戶了解他們最關心的問題或任務是一個簡單的過程。 Gerry 在 A List Apart 上寫了一篇很棒的文章，介紹了這個過程，所以我不會在這裡重複。
最重要的任務分析會給你留下一個用戶有問題的優先列表。 這可以成為網站內容的核心，並幫助我們迭代到一個有用的網站。
迭代內容和設計的保真度
在我們開始迭代我們完成的站點之前，我們首先需要建立它的信息架構。 我們的問題可以作為確定該結構的基礎。
我們可以將這些問題作為卡片分類練習的基礎，用戶將最熱門的問題組織成對他們有意義的組。 這些分組可以幫助我們在開發網站信息架構時為我們提供信息，確保網站反映用戶的心理模型，而不是組織結構。
一旦我們有了信息架構的初稿，我們就可以開始構建我們的站點並對其進行測試，即使我們沒有建立任何設計並且沒有編寫任何副本。
內容驅動的網站幾乎總是建立在內容管理系統上，因此當我們研究用戶問題時，開發人員可以將開箱即用的安裝放在臨時服務器上。
我們現在可以開始在這個 CMS 上構建反映信息架構的空白頁面。 他們需要的所有頁面都是一種在頁面（導航鏈接）和我們預計在每個頁面上回答的問題的要點之間導航的方法。
這立即給了我們一些有形的東西來測試。 即使沒有設計也沒有內容，我們仍然可以檢查信息架構。 用戶能否找到他們想要回答的問題？ 這種結構對他們有意義嗎？
有了這個，現在我們可以開始提高保真度了。 設計師可以開始向關鍵頁面介紹一些基本的排版和佈局。 同時，內容作者可以開始充實頁面，用一些初步的要點來回答頁面上的問題，或者在適當的情況下臨時交叉鏈接到現有網站上回答問題的頁面。
此時，我們可以進行進一步的測試。 我們可以看到設計師建立的視覺層次是否允許用戶發現基本內容。 同樣，我們可以測試鏈接到舊網站的內容，看看它是否回答了用戶的問題，然後我們才開始盲目地從舊網站遷移。
在下一輪迭代中，撰稿人可以開始在整個網站範圍內添加粗略的副本，而設計師可以開始使用改進的排版、顏色和其他風格元素來完善設計。 同樣，這可以通過真實用戶進行測試，以確保新副本回答問題，並且設計改進是有幫助的，而不是分散注意力。
所以這個過程繼續進行，一輪又一輪，增加了副本和設計的保真度，使網站更接近於對現有網站的改進。 此時，我們可以將其推送到現場。 但即便如此，進一步的迭代可以繼續發展並提高基本頁面的性能。
當然，這在原則上聽起來不錯，但確實需要轉變思維。
思維轉變
首先，它確實需要設計師有不同的想法。 許多設計師仍然使用 Sketch 或 Photoshop 來設計高保真模型。 這種方法表明他們在瀏覽器中迭代到最終設計。
也就是說，我不認為這兩種方法需要相互排斥。 儘早在 Sketch 中嘗試更精細的設計解決方案並沒有錯，只要理解這些會根據用戶反饋而改變。 然後可以在登台服務器上緩慢推出和測試該設計。
態度的另一個變化將圍繞內容遷移。 通常會假設我們會將內容從以前的網站遷移到新的網站。 創建所有新內容的想法似乎無法克服。
實際上，這不是我所提議的。 我們可以遷移一定程度的內容，該內容回答用戶問題。 但這不應該集體或盲目地發生。
此外，您會發現沒有必要重寫您認為的盡可能多的內容。 您幾乎肯定會發現，您認為需要遷移的大量副本可能會被淘汰，因為它沒有回答用戶的問題。 這樣做的好處是您需要維護的內容要少得多。
然而，最重要的思維轉變可能是展示正在進行的工作。 無論是設計師還是內容專家，我們中的許多人仍然渴望在讓別人看到之前讓一切變得完美。 但這種方法將內容和設計提前暴露在批評中。 這是一個具有挑戰性的心理轉變，但勢在必行。
您可能會認為讓利益相關者和客戶看到正在進行的工作是災難的根源，但事實並非如此。 事實上，根據我的經驗，他們對看到一個網站出現在他們眼前時反應良好。 他們不會在看到任何東西之前等待數週（甚至數月！），而是會在項目啟動後的幾天內開始看到網站的骨架。 從心理上講，這有很大的不同。
此外，通過看到網站的逐步發展，他們會更加參與項目並了解其發展背後的過程。 這使得利益相關者不太可能拒絕最終解決方案。
最後，如果他們確實有反對意見，這些意見會在流程的早期被識別出來，因為它們很容易解決。 當然，這比等到事情難以改變的最後一刻要好。
今天邁出第一步
我並不是說以這種方式發展一個內容驅動的網站是一個完美的解決方案，但我發現通過系統地提高設計和內容的保真度來迭代最終網站會帶來更好的結果和更少的內部阻力。
不過，不要相信我的話——你自己試試吧。 從小處著手。 對整個網站進行重大重新設計可能對所有相關人員來說都是太大的一步。 也許您可以在新的微型站點或您正在更新的站點的某個部分上嘗試這種方法。
或者，嘗試僅實施我概述的部分過程。 也許只是通過收集用戶問題來開始一個項目，而不是從您的組織想要發布的消息開始。 或者，也許您可以嘗試少量原型製作，而不是製作像素完美的設計組合。
我的觀點是，你可以挑選適合你的東西，而不需要一夜之間改變。 重要的是您開始允許用戶反饋影響您網站的設計和內容。