起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端產品設計：系統命名需要注意這幾點
在B端產品設計中，系統內不同部件的命名也是很重要的一個環節，隨便取的名字可能會加大實施難度和操作錯誤。本文作者從自身經驗出發，分享了系統命名需要注意的幾個問題，希望對你有用。
在B端產品經理認識范疇內，前端的設計經常被放到最后，做的粗糙，認為那是錦上添花的事，重點都放在流程、邏輯的梳理，所以涉及前端的很多內容就被忽視。其實，前端是產品心靈的窗戶，用戶最對產品最直接的感受，能說不重要么？
今天我主要就想說說系統前端范疇里“取名字”這回事，我在團隊里會經常的提到要重視這點，看到莫名其妙的名字我就會大批一頓，后來看別的團隊做的系統，也是如此，我想，是意識的問題。
B端產品設計時涉及到名字的類型有幾類，每一類都有要注意的地方，下面做一些分析。
一、0-1的產品命名
0-1的產品命名，這種只要技術負責人不太水，一般都會比較重視，會進行名字的征集，畢竟產品的命名關乎風水，就像一個人的名字一樣重要，一般會根據系統的定位和所支持的業務來選擇名字。
比如核心業務系統可能會要一個大氣沉穩的名字，我們常說要鎮得住，這樣系統才不會老出問題，青龍、盤古等等這樣的名字就出來了，像財務系統可能會選擇一些聽起來就很專業嚴謹或者跟錢相關的名字，客服系統的名字可能會更加親民和諧。
俗話說，名字取得好，成功了一半，TO B的產品也還是要在企業內推行，如何讓使用部門一次就記住呢，是成功實施的重要一個因素。
二、業務模式命名
為何會提到業務模式的命名呢，因為系統的更新迭代往往是伴隨著業務的變更，所以在做系統項目時往往會以業務模式來命名，業務模式命名又往往會被植入在系統的某個角落，可能是新的菜單名字，新的表字段名字，新的功能按鈕名字，還有在業務邏輯說明里面，業務模式命名可能是由業務方提出的，但是往往業務方也是隨便取，這個時候產品經理完全可以提出異議，要求更改名字，或者系統內部使用名字單獨取。
三、系統菜單命名
菜單就是功能模塊，功能模塊的命名，一方面是讓系統用戶容易明白，也就是要切合該功能支持的業務來取名，不在乎好聽或者什么文藝之類的，而是通俗易懂，用戶才會覺得你是務實而了解現場的產品經理，另一方面要簡潔，不要一個菜單名字十來個字，菜單欄得很寬才能全部展示，或者要換行，這樣做又丑而且開發起來難度大一些，這里就有點考語文水平了，有時候也許業務人員可以給你很好的建議或者提示。
四、字段命名
我這里說的字段命名是指字段的中文名，數據庫字段名姑且不說，通常會在前端頁面展示的一般是具有業務意義的，系統里面的字段命名一般有以下幾點要注意：
（1）盡量用行業的專有名詞
每個行業有每個行業的一些專有名詞，產品經理如果是該行業的老司機，一般在這塊會好些，但也要看是否有這個意識去積累，如果你是這個行業的菜鳥，那么在做設計的時候一定要多問身邊的人，或者上行業網站多看看，這個體現你的行業專業度，而且這樣做出來的系統也更容易為人所接受和理解
（2）命名與業務含義要契合
有些字段確實沒有行業專有叫法的，就要自己命，那就一定要想清楚你這個字段的核心業務含義是什么，什么用途，再來取名，還是那個原則，盡量讓用戶一看就能明白、簡潔
（3）名字要統一
同一個系統內不同功能模塊里用的同一個字段值的，在各功能模塊叫法都要一樣，上下游系統也要保持一致，這個問題很常見，產品經理是個很有主見的人，覺得你取得不好，我要換個，或者說我的系統我做主，等等這樣的想法，這是成全了自己無聊的欲望，傷害了自己的名聲，也傷害了用戶和后繼者，所以，產品經理在這上面還是要有點大局觀。
五、功能按鈕命名
除了增刪改查幾類通用型按鈕外，往往由于業務的需要會有很多別的功能按鈕，這個命名也要注意，還是要契合該功能按鈕背后的實際操作結果，不要張冠李戴，或者隨便取個名字，用戶看了不明白，增加培訓難度和實施難度，也可能造成后來的操作錯誤。
TO B的產品是粗糙的還是細致的，通過前端其實是很容易感覺出來的，也直接的反應產品經理的專業度和用心程度，不管是TO B還是TO C的產品，最終用戶都是人，就得注重體驗，千萬別認為這些只是面上的小事。
本文由 @lena 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于 CC0 協議
- 目前還沒評論，等你發揮！
