首頁

設計師必須掌握的交互知識

ui設計分享達人


交互設計 Interaction Design 也被成為IXD。交互設計建立起了人與計算機便捷溝通的通道,它的目標是創(chuàng)造可用性和用戶體驗俱佳的產(chǎn)品。作為UI設計師,我們在工作之中經(jīng)常會對接交互設計師和產(chǎn)品經(jīng)理,他們具有豐富的交互知識和經(jīng)驗。那是不是我們作為UI設計師,就只需要專心做好視覺層面的工作而不需要了解交互設計了呢?當然不是,在視覺設計層面更多地考慮布局和交互原則才可以讓我們的界面更友好,視覺設計師是交互設計中非常重要的角色。

 


UI設計如何選擇界面布局樣式?

博博

如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里

一起學設計 2018-03-15 17:32:59

什么是界面布局樣式?

界面布局樣式是指用于區(qū)分信息內容,層次的板式設計的具體方式。

總結和了解目前常用的界面布局樣式,可以讓設計師快速決策,選擇合適的設計方式。

界面布局樣式有哪些?

UI設計如何選擇界面布局樣式?

一.卡

利用「卡」設計界面,對應的是現(xiàn)在流行的「卡片式設計」,比如:APP Store 的 Today 頁面。

大海將從以下 3 點描述卡片設計的優(yōu)勢:

  • 靈活性

  • 信息區(qū)分

  • 操作性和趣味性

靈活性

示例如下,分別是 Instagram,知乎,微博的首頁。

UI設計如何選擇界面布局樣式?

Instagram 的「推薦用戶」模塊,知乎的「知乎書店」模塊,微博的「問答」模塊,都利用了可以橫向滑動的卡片設計,打破了訂閱流信息垂直展示的限制,從而展示更多的信息。

信息區(qū)分—信息類型

示例如下,分別是天貓,嚴選,微信讀書的個人中心截圖。

UI設計如何選擇界面布局樣式?

這三個「個人中心」的設計,都利用卡片設計,對不同類型的信息進行了區(qū)分和歸整。

  • 天貓:第一張卡片式用戶個人信息,以及用戶自己收藏的內容和足跡數(shù)據(jù);第二張卡片都是訂單數(shù)據(jù);第三張卡片是運營卡片,用于專門的大型活動的內容展示;

  • 考拉:第一張卡片是用戶個人信息,以及用戶自己收藏的內容和足跡數(shù)據(jù);第二張卡片都是訂單數(shù)據(jù);第三張卡片是用戶相關的其他信息;第四張卡片是卡拉提供的服務。

  • 微信讀書:第一張卡片是用戶個人信息;第二張卡片是用戶賬戶的基本數(shù)據(jù);第三張卡片是用戶自己生成的相關內容;

信息區(qū)分—時間

示例如下,分別是 APP Store,微信公眾號,微博的截圖。

UI設計如何選擇界面布局樣式?

這三個設計,都把復雜的內容信息,用卡片設計的形式,按照時間維度進行了整理和排序。

操作性和趣味性

示例如下,分別是支付寶,ZUO,探探的截圖。

UI設計如何選擇界面布局樣式?

  • 卡片是一種模擬物理世界的設計形式,擁有可操作隱喻,可以被覆蓋、堆疊、移動、劃去。

  • 支付寶卡包:模仿物理世界真實的銀行卡設計,利用用戶已有的銀行卡查看習慣,讓用戶快速理解和查看已綁定的銀行卡

  • ZUO:「ZUO」是一款小眾的,有趣新鮮創(chuàng)意的內容分享產(chǎn)品。主打追尋更美好的可能,產(chǎn)品設計別具特色。左滑卡片可以切換內容的設計,讓產(chǎn)品體驗更加靈動有趣。

  • 探探:一款陌生人社交軟件,廣告主打:左滑不喜歡,右滑喜歡的體驗,凸顯自己在同類型軟件中的體驗差異化,用戶的感受更加新鮮有趣。

卡片設計的反例

自從 iOS 11 之后,卡片設計的趨勢就被推向了高潮。設計網(wǎng)站上有很多卡片式設計作品出現(xiàn)。

卡片設計經(jīng)常會呈現(xiàn)出比較好的視覺效果,但是卡片設計用的不好,會導致浪費空間,降低效率。

示例如下:是大海從 dribbble 上找來的設計,通訊錄的設計利用了卡片設計。

當用戶需要尋找聯(lián)系人時,呈「Z字型」閱讀曲線,遠沒有微信通訊錄的「直線型」閱讀效率高。

UI設計如何選擇界面布局樣式?

二.線

「線」指的是 APP 設計中最常見的「分割線」,在分割線當中可以分為兩類:

UI設計如何選擇界面布局樣式?

貫穿式

「貫穿式」是指,線長度貫穿屏幕,左右邊距為零。貫穿式分割線可以讓被分割的信息的獨立性變強。

示例如下:分別是豆瓣的首頁,網(wǎng)易云音樂的動態(tài)截圖。

UI設計如何選擇界面布局樣式?

兩者的共同點是,每一塊信息的內容較多,關聯(lián)性弱。需要用貫穿式分割性,讓每一個信息內容,更加獨立。

內嵌式

「內嵌式」是指,線的左右邊距留有空隙。內嵌式分割線,可以有助于信息閱讀的流暢性。

示例如下:分別是 APP Store 今日主題的列表頁,36Kr 的個人中心頁面。

UI設計如何選擇界面布局樣式?

貫穿式和內嵌式經(jīng)常是同時使用的,如下圖:網(wǎng)易嚴選的填寫訂單頁面

UI設計如何選擇界面布局樣式?

圖中列表「商品合計」「運費」是相對關聯(lián)性較強的,因此這兩者之間用了內嵌式分割線。「我要開發(fā)票」和它們之間是相對獨立的,因此使用貫穿式分割線。

分割線設計的反例

分割線設計是界面當中最常用的元素,大??戳诉@么多APP,截了這么多圖,都沒有發(fā)現(xiàn)界面中一根線都沒有使用的產(chǎn)品。

分割線設計要注意是否應該使用,以及使用時線的顏色,粗細。

下圖中:知乎的「個人中心」,來源于網(wǎng)絡的日歷設計。

UI設計如何選擇界面布局樣式?

知乎:線的顏色用的過重,導致當看到這個頁面時,會感受到滿眼都是線。改進方法有兩種:把線改細,改淡;把列表文字改重??偨Y下來就是拉開文字和線的對比。

日歷:日期本身的排版已經(jīng)把信息區(qū)分的比較明顯,此時不需要使用分割線。假設 「親密」 「對比」 「重復」 足以讓信息得到區(qū)分,不使用分割線,可以讓你的設計,更加透氣簡潔。

三.間距

利用「間距」設計界面,對應的是現(xiàn)在流行的「無框設計」,不用分割線,純粹用間距實現(xiàn)信息的排版。

大海將從以下 2 點描述其適用性:

  • 圖片為主

  • 內容少且有規(guī)律

圖片為主

示例如下:分別是 Instagram,愛彼迎,紅板報的界面截圖。這些頁面中,均以圖片為主。圖片本身的邊緣具備分隔作用。

UI設計如何選擇界面布局樣式?

內容少且有規(guī)律

示例 1:愛彼迎的「故事頁面」和「搜索結果頁」,兩者都只有 2 中信息板式。內容少且有規(guī)律。

UI設計如何選擇界面布局樣式?

示例 2:輕芒的「分類頁」和「類別首頁」,分類頁只有一種板式,并橫向排版展示。類別首頁只有一屏信息。

UI設計如何選擇界面布局樣式?

總結:卡,線,間距都是頁面當中基礎元素,希望本篇文章可以幫助設計師掌握和了解這 3 個基礎元素的適用性。在設計執(zhí)行中,更加風馳電掣,如沐春風。


UI設計師如何有效的跨團隊、多角色溝通?

博博

UI設計師如何有效的跨團隊、多角色溝通?

一起學設計 2018-03-19 17:55:35

如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里

作為設計方接口人,我近期參與了某產(chǎn)品新版本的交互設計及開發(fā)跟進工作。該項目的產(chǎn)品規(guī)劃、設計、開發(fā)、運營由京深兩地四方多個團隊合作進行。結合自身項目經(jīng)歷,現(xiàn)將我對跨團隊多角色溝通的感悟與經(jīng)驗加以總結,希望對大家有所幫助。有效溝通是提升工作效率的基礎,尤其是鵝廠這種業(yè)務涉及多地、對外多有合作的大型公司,進行跨團隊的、多角色轉換的溝通是工作常態(tài)??鐖F隊合作項目通常需要我們在團隊內部、異地leader、內外部合作伙伴、第三方外包等多種角色間靈活調整溝通方式,運用有效的溝通手段,以確保溝通效果。

背景

有效溝通是提升工作效率的基礎,尤其是鵝廠這種業(yè)務涉及多地、對外多有合作的大型公司,進行跨團隊的、多角色轉換的溝通是工作常態(tài)??鐖F隊合作項目通常需要我們在團隊內部、異地leader、內外部合作伙伴、第三方外包等多種角色間靈活調整溝通方式,運用有效的溝通手段,以確保溝通效果。

索引

UI設計師如何有效的跨團隊、多角色溝通?

本文將從有效溝通的心理建設、角色分析、流程搭建+工具沉淀三個層次展開。

心理建設

有效溝通的兩點認識

為“傳”而“達”

溝通是信息的有效傳達?!皞鳌笔鞘侄危鬁贤〞r需闡明觀點;“達”是目的,指明溝通旨在使人通達理解。溝通中出現(xiàn)的自說自話、固執(zhí)己見,通常是偏執(zhí)于“傳”,而忽視了“達”。需要明確的是,所有的溝通,都應該以接收方更好的理解接受為目的,而不是自顧自的滔滔不絕。

減少損耗

信息傳達的過程伴隨著信息的損耗。因此,在溝通的各個環(huán)節(jié)都需注意減少損耗,提升觸達率。一方面,要理清自己的表達重點和思路,減少信息的輸出損耗;另一方面,要從接受方關注點出發(fā),提升對接受者的信息觸達;此外,還要靈活切換溝通方式、正確處理意見分歧等,盡量減少信息在傳遞途中的折損。

UI設計師如何有效的跨團隊、多角色溝通?

跨團隊多角色溝通的基本態(tài)度

跨團隊——秉持中立合作的態(tài)度

  • 中立——團隊不同,訴求不同,秉持中立的溝通態(tài)度,不要因個人偏向導致無意義消耗。

  • 合作——以同理心贏得各方的信任,避免抵觸情緒的產(chǎn)生,營造良好的溝通氛圍。

  • 產(chǎn)品目標導向——對有爭議的問題點,應綜合權衡用戶體驗、產(chǎn)品目標和開發(fā)成本,以產(chǎn)品目標為第一要義。

多角色——認清各方關注點的差異

  • 理解各方差異化的核心訴求——對不同團隊角色的溝通中應有不同的側重點,靈活的轉換角色,做有針對性的輸出表達。

  • 對內交流——以產(chǎn)品目標為導向,保證內部一致;對上匯報——重點明確,避免流水帳;對外溝通——目標明確,內部一致,有針對性的溝通,避免互相拆臺或雞同鴨講。

角色分析

項目組成員角色模型

項目伊始,在融入團隊的過程中,應注意理清項目組內的不同角色,明確匯報對象,做好任務分工,理清利益關系,協(xié)調各方訴求。

(具體項目組角色模型可能涉密,略)

各角色核心訴求及溝通側重點模型

不同角色的核心訴求不同,也因此在對不同角色溝通時也應該有所側重,以本項目為例:京深兩地四方的所有成員,可大致劃分為如下七種角色。

UI設計師如何有效的跨團隊、多角色溝通?

UI設計師如何有效的跨團隊、多角色溝通?

各角色核心訴求及溝通側重點小結

團隊角色 核心訴求 溝通側重點
leader 把控項目進度、確保項目實現(xiàn) 進度同步、資源申請、問題確認
設計負責人 推進項目進行,落實產(chǎn)品功能 進度同步、問題評審、資源協(xié)調
視覺 確保視覺呈現(xiàn) 視覺反饋、問題評審
技術支持 提供技術支持和監(jiān)督 尋求技術支持、評估開發(fā)成本
產(chǎn)品經(jīng)理 推動項目進行、維護運營側利益 功能確認、開發(fā)協(xié)調、運營活動落實
前端 降低前端成本、減少反復 跟進前端進度、幫助協(xié)調資源
后端 規(guī)避后端風險、降低開發(fā)成本 前端實現(xiàn)確認、開發(fā)問題跟進與協(xié)調

流程搭建

有效溝通流程模型

在有效溝通流程模型中,我按籌備、執(zhí)行、跟進三個階段,繪制出體驗地圖,將溝通中的關鍵節(jié)點按行為、心理、情緒、方法、工具五個緯度拆分,梳理各節(jié)點需注意的問題,以及相應的有效溝通方法和工具。(詳情請點擊查看大圖)

UI設計師如何有效的跨團隊、多角色溝通?

UI設計師如何有效的跨團隊、多角色溝通?

籌備階段——明確目的,同步信息

  • 明確溝通目的。無論是同步郵件、電話會議還是IM群聊,都需要在發(fā)起前明確目的,列好問題清單,帶著目的溝通。如:多方電話會議前,應事先知會各方會議主旨,準備會議提綱并在會議開始時向各方闡明,為會議提供清晰的行進框架。

  • 提前同步信息。信息同步是溝通的前提。依據(jù)溝通目的準備溝通所需的文檔,根據(jù)需要提前同步,盡量減少因信息不對稱帶來的時間浪費。明確易讀的設計輸出、正式溝通前與各方單獨的預溝通、提前郵件同步告知等,都是有效信息同步的手段。

執(zhí)行階段——抓大放小、促成共識

  • 對待爭議,抓大放小,避免僵局。評估爭議點時,先不要基于反駁避免情緒化表達,適當發(fā)問:為什么做?為什么不做?不做之后有什么后果?理智全面的做出評判。給問題點評定優(yōu)先級,抓大放小,集中精力推進主功能,高成本、低優(yōu)先級的細節(jié)問題放到最后統(tǒng)一處理,避免陷入“就是要改”vs“就是不改”的無謂消耗。根據(jù)需要及時協(xié)調第三方資源進場,尋求技術支持或資深leader的建議,避免溝通僵局的出現(xiàn)。

  • 促成共識。無結果的溝通是無效的溝通,有效溝通應促使各方達成共識。無論是待協(xié)調、暫擱置還是需改進,都需要有一個結論明確、責任人明確、截止時間明確的溝通結論,并依此執(zhí)行跟進。

跟進階段——同步落實,自我反思

  • 進度同步,問題落實。溝通過后及時同步溝通結論,設計交付、前端交付等階段性時間節(jié)點,需以正式的項目郵件,及時周知項目相關人員。對于已解決的問題,及時跟進驗收;暫時擱置的問題,做好記錄,明確時間節(jié)點和責任人;需更多資源介入的問題,及時對上反饋,申請資源解決。

  • 自我反思與補齊。每次溝通都是一次查漏補缺的過程,每次溝通后花時間反思一下本次溝通中自己在設計說明中有哪些疏忽、表述上有何不足、相關知識上有那些欠缺,以此為鑒及時調整、補齊疏漏。

工具沉淀

開發(fā)故事卡

說明:明確易讀的設計說明文檔

功能:產(chǎn)品設計說明、開發(fā)指導手冊、階段性交付走查依據(jù)

使用場景:跨團隊溝通中,便于開發(fā)人員準確的理解設計意圖;適合外部合作時模塊化開發(fā)與階段性交付,便于交付及走查。

使用要點:

  • 根據(jù)信息構架拆分產(chǎn)品模塊,分別設立索引,提供產(chǎn)品概覽,串聯(lián)各功能詳情頁。

  • 在索引和詳情頁之間由超鏈接跳轉,方便快速定位。

  • 按照功能點拆分詳情頁,提出功能需求,明確驗收標準,說明頁面細節(jié)。

  • 各頁面統(tǒng)一編號與視覺源文件一一對應,方便快速查找。

UI設計師如何有效的跨團隊、多角色溝通?

需求管理文檔

說明:需求及反饋問題的規(guī)范化管理模板

功能:需求變動及問題反饋的管理模板、開發(fā)發(fā)跟進的溝通文檔

使用場景:開發(fā)跟進階段,實時記錄變動的需求及反饋的問題點;設計側定期反饋給開發(fā)人員的規(guī)范化輸出文檔。

使用要點:

  • 明確問題及目標效果,排定優(yōu)先級依此解決。

  • 明確負責人和時間節(jié)點,保證落實。

  • 做好文檔更新維護及信息同步。

  • 按階段統(tǒng)一反饋調整,節(jié)約開發(fā)時間。

UI設計師如何有效的跨團隊、多角色溝通?

關注點推進模型

說明:不同項目階段明確核心關注點的虛擬模型

功能:輔助聚焦當下關注點,避免陷入不合時宜的細節(jié)或宏觀問題

使用場景:從宏觀到微觀的產(chǎn)品設計過程中,幫助梳理各個階段需溝通的核心問題,溝通時陷入細節(jié)或反復爭論時的自查工具。

使用要點:

  • 做好關注點的的逐步推進:探討信息構架時就不要在交互樣式上反復拉鋸;討論交互方式時就不要過度關注視覺細節(jié)。

  • 不過早陷入細節(jié)。優(yōu)秀產(chǎn)品的細節(jié)固然需打磨,但從0到1實現(xiàn)一款產(chǎn)品的過程中,將有限的資源和排期消耗在不合時宜的細節(jié)權衡上,得不償失。

  • 同樣,若因執(zhí)行時的設計挑戰(zhàn)需調整產(chǎn)品上層,也需主題限定問題范圍,不要因宏觀問題上的反復而影響執(zhí)行效率。

UI設計師如何有效的跨團隊、多角色溝通?

優(yōu)先級評估模型

說明:不同項目階段評估需求優(yōu)先級的KANO衍生模型

功能:借助KANO模型分析思路,對需求優(yōu)先級提供排定依據(jù)

使用場景:設計階段樣式取舍、開發(fā)跟進階段需求調整的先后順序、應對分歧如何抓大放小,都可以借助優(yōu)先級評估模型輔助評估。

使用要點:

  • 不同項目階段,不同溝通對象對同一需求優(yōu)先級的評定標準不同,因此應注意根據(jù)項目階段和溝通對象靈活調整。

  • 不同產(chǎn)品在用戶體驗與產(chǎn)品目標取舍上有所區(qū)別。一般而言,2C產(chǎn)品更注重用戶體驗,而2B產(chǎn)品則可能更注重實現(xiàn)產(chǎn)品目標,因此應注意具體產(chǎn)品具體分析。

UI設計師如何有效的跨團隊、多角色溝通?

藍藍設計www.sillybuy.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務


產(chǎn)品經(jīng)理分析產(chǎn)品積分體系

博博

如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里


積分的作用在整個產(chǎn)品的過程中主要是希望是圍繞著拉新、留存、促活去做的,配合著主打新功能等等根據(jù)產(chǎn)品的差異而差異化。從用戶為出發(fā)點,將積分可以分為兩大塊:一塊是獲取、一塊是消耗。

從用戶角度出發(fā),了解關于產(chǎn)品積分體系的事

首先,就積分而言,是用戶通過完成某些任務或手段來進行對應積分點的獲取,再通過相關的手段進行消耗的一個過程。

從用戶角度出發(fā),了解關于產(chǎn)品積分體系的事

所以從用戶為出發(fā)點,將積分可以分為兩大塊:一塊是獲?。灰粔K是消耗。

下面針對兩點分開來說:

一、獲取(主要是獲取的方式和對應的規(guī)則)

獲取方式,大類可根據(jù)用戶完成對應任務類型分為:

1. 新手任務類(這是一個幫助用戶熟悉產(chǎn)品同時激勵用戶使用產(chǎn)品的過程)

  • 綁定手機;
  • 綁定郵箱;
  • 上傳頭像;
  • 首次消費/發(fā)文/分享等等對應產(chǎn)品核心功能的首次使用;
  • 完善個人信息。

根據(jù)產(chǎn)品核心功能和側重點的不同而不同,一定要區(qū)別哪些信息內容是我們想從用戶處獲取的核心,哪一些并不是很重要。不要人云亦云,不要有“別的產(chǎn)品有了所以我也要有”的思想,思考一下為什么你要需要這個任務??梢远鄥⒄掌渌e分體系完善的對它們進行整理歸類,之后結合自身產(chǎn)品特性再去做自己的。

2. 日常任務類

  • 簽到(這幾乎是最基礎最常見的);
  • 對應產(chǎn)品核心功能的使用相關的任務。

3. 運營活動類

  • 節(jié)日相關類;
  • 產(chǎn)品特定日期相關類(周年等等)。

這個具體需要配合運營相關人員的推廣活動等等進行部署調整,但是一定要做好部門間的對接工作。因為活動對應分配的積分比例等等影響很深遠,一定要思考好本次活動預計需要分發(fā)出去多少積分,達到怎樣的活動效果?對積分整體有什么影響?存在那些可能出現(xiàn)的問題和漏洞?怎么去防止薅羊毛黨?等等。

4. 特定激勵用戶類

這類主要是,例如:生日,或者和用戶建立聯(lián)系的特定日期(例如:幾周年等等)。

5. 均衡刺激積分的流通

這類主要放在消耗中講,主要是抽獎類把積分當作一類獎品進行兌換。

以上算是大致講了積分的獲取,要領就是結合產(chǎn)品結合情景去進行設置。對于初次設計的人來說,就是先要找到經(jīng)典體系完整的有相關性參考價值的產(chǎn)品的積分體系,進行總結整理思考,然后再進行自己的設計,而且盡量多看多整理幾家。

二、消耗

消耗的話根據(jù)產(chǎn)品的自身屬性的不同,表現(xiàn)形式差異性比較大所以我的列舉不一定人人都適用,僅供參考。但是本質都是一樣的,都是進行積分的消耗。

1. 兌換商品

  • 虛擬商品;
  • 現(xiàn)實商品。

兌換的手段可以是純積分兌換,可以是積分+現(xiàn)實貨幣。對于兌換商品的選擇也是很重要,如果兌換給出的商品都讓用戶提不起來興趣,那么無疑是失敗的。好比二次元類搞活動積分兌洗潔精就跑的很偏了,所以選品也很重要。

虛擬產(chǎn)品的兌換最好是圍繞著核心功能or下一步主打的功能來比較好,再或者說積分體系和會員體系是相輔相成的,可以在兌換商品,這里加入兌換會員增強之間的聯(lián)系。會員體系是另外一大塊了在這里就不說了。

2. 抽獎

抽獎是最好的進行積分流動的手段,如果用戶只是一味的累積積分,無論是產(chǎn)品所提供的虛擬商品,還是現(xiàn)實商品都不和他心意提供另一個出口給用戶。或者前兩者門檻過高或需要現(xiàn)實貨幣,用戶不愿花費,抽獎都是一種低花費積分小概率抽中商品,利于積分生態(tài)的流動的措施。

具體的抽獎形式就很多了什么刮刮獎啊大轉盤啊,記得要控制好概率分配噢。

三、注意點

(1)對于整個積分體系上面都是細節(jié),在實際操作中第一步,要確定的是在公司的戰(zhàn)略上,愿意每年投入多少錢在里面,或者對于已經(jīng)盈利的公司,是拿出盈利里的多少百分比來進行用戶的一個回饋。

同時,在投入時,希望得到的反饋效果是怎樣的,都要制定好。這個可以根據(jù)數(shù)據(jù)后期的變化再進行調整,但是一定要有這樣一個概念。去估計整體的量,在這個預算下進行后期的設計,同時在后期設計完成后,在進行計算在極端情況下(兩個極端)和預期情況下,和公司整體戰(zhàn)略偏差是否在可接受范圍,如果不在那么再進行調整。

(2)積分體系可以看作是產(chǎn)品內部的貨幣體系,所以要注意積分膨脹和積分緊縮的問題,要是積分的價值盡量保持在一個波動不大可控的范圍內。無論是膨脹還是緊縮,都會影響產(chǎn)品和用戶給產(chǎn)品帶來不好的影響。請重點關注膨脹,因為多數(shù)會出現(xiàn)的情況時設計不當積分超發(fā)。

(3)做好相關數(shù)據(jù)的管理實時反饋,用戶的領取積分數(shù)據(jù),消耗積分數(shù)據(jù)等等,細節(jié)數(shù)據(jù)需要自己去扣清楚都是有價值的數(shù)據(jù)。后臺相關頁面設計到位,及時將數(shù)據(jù)反饋給相關人員進行溝通。

(4)做好風控體系,別讓羊毛黨毀了整個體系。

(5)不要讓你的積分體系一成不變,在固定的體系下,要用不同的活動內容和兌換商品的推成出新,讓用戶感覺到新鮮感。如果什么都不變化不抓著節(jié)奏走,那么用戶會失去興趣。具體要和運營等等相關人員進行討論。

(6)積分的規(guī)則一定要完善沒有漏洞,不論是給出的任務還是消耗的過程一定不要有歧義,一定要仔細?。。。。?!這點很重要?。。。?

(7)積分體系的任務應該是對用戶的留存,活躍和新增起到幫助作用的。所以不可能兼顧到所有的注冊用戶,一定要分清楚主次,誰是主要服務對象,服務的目的是什么等等。

好久沒有寫過文章了,邏輯有不順暢,內容有錯誤的地方歡迎大家指出,互相學習,謝謝閱讀。

本文由 @judyyyy 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載

藍藍設計www.sillybuy.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 平面設計服務


為何如今的產(chǎn)品總給人千人一面的感覺?

博博

如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里

編者按:這篇來自產(chǎn)品設計師 Eugen E?anu 的文章解開了我長久以來的一個疑惑,其中的思考和經(jīng)驗值得我們共勉。結尾的 One more thing 是我額外補充的內容和一點想法,和當下產(chǎn)品設計的困境相關,也是試圖補完這篇文章,希望能給你一點幫助。

為何如今的產(chǎn)品總給人千人一面的感覺?

當你在尋找一個能夠滿足你需求的應用的時候,會不會因為太多相似的產(chǎn)品而無從選擇?當你想要在兩個甚至更多相似的產(chǎn)品中進行選擇,一切都顯得那么困難。而唯一能夠進行快速區(qū)分的因素似乎是設計,但是緊接著會發(fā)現(xiàn)連設計都是那么相似。

為什么市場上所有的應用看起來都長的同一副面孔呢?

在回答這個問題之前,我想簡單澄清一些事情。為了創(chuàng)造出能夠解決需求的產(chǎn)品,通常需要采用以人為本的方法來進行設計,但是事實上,那種狀態(tài)太過于理想,幾乎沒人能夠真正做到。

以人為本的設計方法,確實能夠極富創(chuàng)造性地解決問題。當采用這種方法來為目標用戶進行設計,最終能夠得到了一個為這些用戶量身定制的解決方案。但是,這種設計方法需要設計者具備無與倫比的同理心來真正站在目標用戶的角度來思考問題,由此獲得大量的想法和靈感,建立一大堆可能有效的原型,同目標用戶分享你正在做的事情,驗證你的感受和想法,最終將你的創(chuàng)新的解決方案推向世界。但是這是理想的狀況。

那么為什么世界上那么多偉大的公司,依然無法真正采用這樣的方法成就真正優(yōu)秀的產(chǎn)品呢?因為幾乎所有的產(chǎn)品身上都有一種病毒,它的名字叫做特征蔓延。

為何如今的產(chǎn)品總給人千人一面的感覺?

產(chǎn)品開發(fā)流行病:特征蔓延

特征蔓延的英文名叫做 Feature creep,它的主要癥狀就是不斷向產(chǎn)品中添加功能。

現(xiàn)如今,絕大多數(shù)的產(chǎn)品,無論是物理實體還是存在于手機中的各色 APP,幾乎全都面對著激烈的競爭。

激烈的競爭使得每個人都面臨著壓力,產(chǎn)品所屬的企業(yè)中,從領導到產(chǎn)品經(jīng)理再到最底層的開發(fā)者和設計師,所有人都面對著來自對手和潛在對手的壓力。

這種競爭壓力基本上是源自于三個方面:價格,功能和質量。非常不幸的是,絕大多數(shù)時候,這三者的壓力從前到后是依次遞減的。價格競爭的壓力通常是最大也是最直接的,然后才是功能和產(chǎn)品質量,至于這個順序意味著什么,就不贅述了。

同時,產(chǎn)品上線的速度和順序也很重要。誰是進入市場第一人,這個是必須爭一下的。

這樣一來,想要盡快殺入市場的產(chǎn)品,在很大程度上是伴隨著「偷工減料」的。沒有足夠的時間來對產(chǎn)品進行足夠多的迭代,沒有辦法把系統(tǒng)調整到最優(yōu),沒有辦法把硬件缺陷都找出來,沒有辦法把軟件中每一個 Bug 都盡量找出來,甚至絕大多數(shù)企業(yè)的領導都抱有「沒事,我們隨后再把問題找出來解決掉。」從電腦到汽車,從 Windows 到 iOS,從來都是如此。

沒有什么 Bug 是一個補丁解決不了的,如果不行,多打幾個?!猈indows開發(fā)團隊

為何如今的產(chǎn)品總給人千人一面的感覺?

當然,能夠通過后期補丁解決的問題終究是少數(shù)。實際市場上絕大多數(shù)的產(chǎn)品確實隨著補丁和修改逐步提升了,但是絕大多數(shù)仍然沒有解決用戶的問題。

對于特征蔓延這種病癥,早在1976年就已經(jīng)被發(fā)現(xiàn),并且在產(chǎn)品設計圈當中有著非常廣泛的認知。對于這種產(chǎn)品病有一個非常學術的描述:

特征蔓延是指一產(chǎn)品(如APP)的軟件機能持續(xù)膨脹或增加的情形。產(chǎn)品基本機能以外的擴充機能,會使產(chǎn)品比原始設計要更復雜。長時間來看,額外或不需要的機能慢慢的進入系統(tǒng)中,使系統(tǒng)超出原來設定的目標。

假設我們擁有一個非常強大的產(chǎn)品團隊,設計師擁有足夠的同理心,開發(fā)和測試也非常靠譜,他們使用以人為中心的設計方法,探索了所有用戶使用場景,并且遵循產(chǎn)品流程認真設計仔細測試,最終輸出了一個用戶想要購買的優(yōu)質產(chǎn)品。假設這個問世的產(chǎn)品在各個層面上都是完美的:擁有直觀的界面,良好的感覺和優(yōu)秀的視覺,貼合用戶的體驗等等。它只有一個使命,那就是以有意義的方式滿足人們的需求,讓人們能夠更好地生活,產(chǎn)品因此而走向成功。誰都想來一個。(就像解決了信號問題的 iPhone 4)

非常不幸的是,產(chǎn)品上市之后,各種各樣的影響因素開始出現(xiàn),情況開始向著并不理想的方向發(fā)展。

  • 現(xiàn)有的用戶非常喜歡這款產(chǎn)品,但是他們想要更多的功能,各種各樣的功能,包括帶孩子。
  • 競爭對手開始推出新款,并且具備一些全新的、我們的產(chǎn)品所不具備的功能。從公司領導到用戶都開始催我們的團隊增加新功能。
  • 客戶對于產(chǎn)品總體上是滿意,但是買的人多了之后,市場趨于飽和,銷售額不可避免的下降了。是時候添加新的或者創(chuàng)新的功能來促使用戶更新或購買新版本了。

特征蔓延就是這樣出現(xiàn)的,產(chǎn)品在現(xiàn)有的功能上不斷增加更多的功能。各種各樣的理由會促使產(chǎn)品不得不增加功能,各種各樣。然后產(chǎn)品開始膨脹,臃腫,直到用戶實在不太想用或者徹底沒法用。

而在如今的市場和商業(yè)競爭中,特征蔓延并不是唯一的絕癥。

為何如今的產(chǎn)品總給人千人一面的感覺?

競爭驅動式設計的泥潭

哈佛大學教授 Youngme Moon 認為,產(chǎn)品和競品之間的攀比對抗是讓產(chǎn)品陷入千篇一律的境地的主要原因。通常,企業(yè)為了提升產(chǎn)品的市場份額,會讓自家產(chǎn)品擁有對手一樣的功能,來確保競爭力。對手的團隊協(xié)同軟件的售價是20美元?沒事,我們開發(fā)個功能一樣強大的,定價15美元好了。他們的移動端的 APP 只需要加1美元就能獲得?那我們的移動端版本直接免費和桌面端綁定好了。

當產(chǎn)品陷入和對手刺刀見紅的局面之時,兩敗俱傷的結果就不遠了。試圖逐個功能和對手競爭,必然會陷入同質化的競爭,很難讓用戶真正愛上其中的某個產(chǎn)品。

這種就是競爭驅動型設計。令人遺憾的是,即使產(chǎn)品的第一版是以用戶為中心設計出來的優(yōu)質產(chǎn)品,在競爭驅動下誕生的后續(xù)產(chǎn)品,就很難贏得用戶的真心了。

很多時候如果你想創(chuàng)造真正卓越的產(chǎn)品,你不得不花費更多的時間。而即使你創(chuàng)造出來這樣的產(chǎn)品,在市場上也不一定能在銷售排行榜上殺入前三,屈居第四是很正常的事情。那么你還愿意這么做么?

我們都聽說過先發(fā)優(yōu)勢,但是你真的知道獲得先發(fā)優(yōu)勢,將會付出什么樣的代價么?

為何如今的產(chǎn)品總給人千人一面的感覺?

用1年寫一冊暢銷書,還是花5年成就一本經(jīng)典?

以寫書來舉例也許更加直觀。當你決定寫一本關于設計的書,然后登上暢銷榜,名利雙收,好像挺不錯的。如果它的內容是之前沒人寫過的,并且確實比較有市場,在內容上稍加打磨,幾個月后引爆設計圈似乎不是太大的問題。事實上,它上架之后,和自己的預期相差不遠,挺好。不過,不知道為什么,1年之后,熱點消退,這本書也沒什么人買了。

換一個做法,寫書的過程中可能需要勒緊褲腰帶過日子,花上5年時間仔細揣摩,寫一本擁有持續(xù)價值的書,然后在之后的100年時間當中,成為設計圈中每個設計師的必讀書。寫書的過程中,你需要專門地進行研究,仔細地調整內容,對于每個細節(jié)都精雕細琢,花費更多的時間,讓這本書有對抗時間的價值。

從長遠來看,只看眼前、偷工減料的公司會自然而然過時,然后被人們所忘記。浪潮過后,誰在裸泳一目了然。

為什么總忍不住添加新的功能?

和對手的對比,總能看到自家產(chǎn)品的缺陷,然后補完缺陷,這有什么不對么?似乎沒問題,但是這種思維方式并不會打造更好的產(chǎn)品。更好的策略是:

專注于自家真正擅長的領域,并繼續(xù)深挖自己的長處。在自己的優(yōu)勢領域,集中自己的研發(fā)能力,并作為營銷重點。這樣才能讓自己的產(chǎn)品從平庸走向卓越,真正能在慘烈的紅海中脫穎而出。用更少更精銳的功能來成就自己,而不是在成堆的功能中與對手同歸于盡。

還記得一代的 Google Pixel Phone 么?他們的營銷口號是「有耳機插孔的手機」,對標的正是取消耳機插孔的 iPhone ,而這個文案正是嘲諷 iPhone 的設計太過愚蠢。令人驚訝的是,隨后的 Google Pixel 2 也跟著取消了耳機插孔。現(xiàn)在還有誰記得 Google Pixel 系列呢?

為何如今的產(chǎn)品總給人千人一面的感覺?

是聚焦長處,還是忙于跟隨?

偉大的設計需要脫離茍且的競爭和來自客戶的壓力。開始專注于你認為重要的事情,以及你目光所及的遠方。在你最優(yōu)秀的地方,集中精力。你必須確保你的產(chǎn)品是一致且連貫的。這意味著領導層需要足夠睿智,也足夠堅定,這樣才能抵擋來自用戶和市場部門不斷增加產(chǎn)品功能的各種需求。

成就最好的產(chǎn)品,設計者要屏蔽來自競爭對手的聲音,專注于用戶真實的深層需求。

不要覺得我的話是憑空而來的。Amazon 的 CEO 兼創(chuàng)始人 Jeff Bezos 也提到過類似的方法,被稱為「客戶迷戀」。在他看來,將所有精力集中在客戶的需求上,而不是競爭。重點在于三個簡單的問題上:「客戶需要的是什么?」「他們的需求如何才能滿足」「我們可以做什么來提高客戶服務和價值?」Bezos 還認為,專注于客戶才是首要目標,其他的問題會迎刃而解的。如果你一開始就被市場競爭吸引了注意力,很難作出真正對的決策。產(chǎn)品質量通常只關乎客戶和解決真實的需求。

One more thing

想要從激烈的競爭中抽身出來, 創(chuàng)造真正獨特的產(chǎn)品,是許多產(chǎn)品設計師的愿望。但是這真的不是一句話說得清楚的事情,真實的情況比我們想象中還要復雜。

競爭驅動型的設計確實是一個很難繞過的問題,驅動產(chǎn)品的不僅僅是領導和客戶的聲音,深陷市場競爭,許多時候確實身不由己。

采用以用戶為中心的設計的設計流程,還繞不開一個常見的因素:最佳實踐。經(jīng)過前人驗證、時間打磨、用戶習慣之后所獲得的最佳實踐,是設計師和產(chǎn)品在很多時候必須依托的東西。比如我們如今所看到的許多表單的設計策略和漢堡菜單的使用。用戶和市場已經(jīng)「塑造」出了許多最優(yōu)的設計策略,設計師通常會直接拿來使用,而我們感到「千人一面」的 UI設計當中,確實有各種最佳實踐所「作出的貢獻」。

為何如今的產(chǎn)品總給人千人一面的感覺?

包括我們現(xiàn)在正在不斷探索的動效設計,雖然力圖在視覺和體驗上有所創(chuàng)新,但是早在近百年前,迪士尼的動畫設計師們已經(jīng)總結出一套人性化動畫設計的策略,實際上我們今天許多優(yōu)秀的動效設計,依然是圍繞著這一套「最佳實踐」來進行設計和重設計的。

為何如今的產(chǎn)品總給人千人一面的感覺?

違反「最佳實踐」的特立獨行的設計并非不可,只不過它通常需要遵循「每次僅只能打破一個規(guī)則」的原則。在用戶已經(jīng)被市場培養(yǎng)出大量習慣的前提之下,大量采用反直覺、反習慣的設計,只會讓產(chǎn)品死的更快。

那么是不是就沒有辦法了呢?當然不是。新鮮有趣的、獨樹一幟的設計并非沒有辦法設計,設計師需要在最佳實踐以外的部分尋求改變,探索可能性,甚至等待契機。不同的設計趨勢、元素、技法、排版布局、配色、動效進行多樣化的組合,依然可以創(chuàng)造出讓人眼前一亮的設計。但是這還不夠。

為何如今的產(chǎn)品總給人千人一面的感覺?

早在上世紀30年代的時候,包豪斯設計學院的先哲們就已經(jīng)提出過「形式追隨功能」的設計箴言。這句話強調的是設計的科學性,便捷性和經(jīng)濟效益,而不再是圍繞著裝飾性和簡單的形式感來進行設計。在今天這個用戶體驗至上、以用戶為中心的設計趨勢之下,UI 和視覺所代表的「形式」所追隨的「功能」應該是用戶的真實需求。而在這個語境下試圖創(chuàng)新,或者恰如其分地融入一些貼合場景和目標的藝術元素,也許是個不錯的突破口。

正如同在上一篇文章《熟知用戶行為的這7個層面,你的設計才會走進人心》中所說的,客戶買鉆頭的時候,需要的并非鉆頭而是洞,同樣的,用戶下載一款閱讀APP 的時候,他的真實需要并非是閱讀器,他需要的是內容,是信息,是滿足他求知欲的文章,或者填補碎片時間的有趣的故事。

為何如今的產(chǎn)品總給人千人一面的感覺?

內容為王這句話早就已經(jīng)不是口號了。圍繞著內容做設計已經(jīng)成為了諸如 Medium 和 Twtter 這樣的企業(yè)的新策略,而國內的許多一線企業(yè)也開始擁有自己的「首席內容官」。讓設計追隨內容,讓真正吸引用戶的東西來撬動產(chǎn)品,拉升體量,才是正途。

設計和內容的結合方式多種多樣,根據(jù)內容所需要的語境來搭配相應的設計是目前已知的最常見的做法。根據(jù)內容本身所具備的故事性和環(huán)境特征,視覺化地表達,讓 UI 和視覺服務于內容,是許多成功的設計所驗證過的技巧。

比如下面的 voyage-electrique這個網(wǎng)站,借助 C4D 構建的 3D 可交互式的場景來呈現(xiàn)電力系統(tǒng)的運作,清新可愛的畫風和令人愉悅的音樂讓原本沉悶的主題顯得頗為有趣,讓人心生好感的設計,使得相關的信息更容易被用戶接受。流程化的信息呈現(xiàn)方式隱約具備了故事性的表達,即使你并不懂法語也會流連忘返,在點擊和探索中多停留一會兒。語言蒼白,不如點進去看看。

為何如今的產(chǎn)品總給人千人一面的感覺?

最后需要注意一個問題:人類先天就是喜新厭舊的生物,再新鮮有趣的東西,在獲得之后都會快速地適應(適應性認知偏差),并不再感到新鮮。在內容和設計策略上,適時地注入新鮮的內容(不違反基本設計規(guī)則和產(chǎn)品方向的前提下),是維持活躍度而必須做的事情。

原文作者 : Eugen E?anu

譯者/編輯 : 陳子木

譯文地址:https://www.uisdc.com/design-product-like-everyone-else

藍藍設計www.sillybuy.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務

js學習中的總結——幾種繼承模式

seo達人

如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里

     js中構造函數(shù)的幾種繼承模式淺析

一、原型鏈模式繼承

    利用原型讓一個引用類型繼承另一個引用類型的屬性和方法 。

    用的最多。

    缺點:不可傳參,不可多繼承。


        
  1. function People(name, age) {//添加公有屬性
  2. name = name || 'xiaolan';
  3. age = age || 18;
  4. this.name = name;
  5. this.age = age;
  6. }//創(chuàng)建一個名為People的類
  7. People.prototype.eat = function() {//添加私有屬性
  8. console.log(this.name + '賊能吃');
  9. }
  10. function Cat(color) {//創(chuàng)建一個名為Cat的類
  11. this.color = color;
  12. }
  13. Cat.prototype = new People('小叮當', 200);//實例化一個People類,并賦值給Cat類的原型鏈
  14. var cat = new Cat('藍白色')
  15. console.log(cat.name)//'小叮當'
  16. cat.eat();//'小叮當賊能吃'

二、混合模式繼承

    用call的方法只能繼承私有屬性,所以再加一遍一遍原型鏈模式繼承,原型鏈模式繼承又把私有屬性和公有屬性都繼承了一遍。


        
  1. function People(name, age) { //創(chuàng)建一個父級People類
  2. name = name || 'xiaolan';
  3. age = age || 18;
  4. this.name = name;
  5. this.age = age;
  6. }
  7. People.prototype.eat = function() {
  8. console.log(this.name + '賊能吃');
  9. }
  10. function Cat(color, name, age) {
  11. this.color = color;
  12. People.call(this, name, age); //通過call的形式繼承
  13. //通過call(this),將People的指向改為Cat的實例
  14. }
  15. var cat = new Cat('藍白色', '小叮當', 1);
  16. console.log(cat.name);//'小叮當'
  17. cat.eat();//報錯,
  18. //繼承不了公有屬性,所以cat.eat()會報錯;

為了繼承公有屬性,用原型鏈模式在把公有屬性和方法繼承過來,


        
  1. function People(name, age) { //創(chuàng)建一個父級People類
  2. name = name || 'xiaolan';
  3. age = age || 18;
  4. this.name = name;
  5. this.age = age;
  6. }
  7. People.prototype.eat = function() {
  8. console.log(this.name + '賊能吃');
  9. }
  10. function Cat(color, name, age) {
  11. this.color = color;
  12. People.call(this, name, age); //通過call的形式繼承
  13. //通過call(this),將People的指向改為Cat的實例
  14. }
  15. Cat.prototype = new People()
  16. var cat = new Cat('藍白色', '小叮當', 200)
  17. console.log(cat)
  18. console.log(cat.name); //'小叮當',在原型鏈繼承的時候,就近原則,cat.name 先找到'小叮當',就不往下找了
  19. cat.eat(); //'小叮當賊能吃'

三、拷貝繼承

    優(yōu)點:可以多繼承,可傳參;

    缺點:浪費資源,不能判斷父級;


        
  1. function People(name, age) { //創(chuàng)建一個父級People類
  2. name = name || 'xiaolan';
  3. age = age || 18;
  4. this.name = name;
  5. this.age = age;
  6. }
  7. People.prototype.eat = function() {
  8. console.log(this.name + '賊能吃');
  9. }
  10. function Cat(color, name, age) {
  11. this.color = color;
  12. var people = new People(name, age) //實例化一個People類
  13. for (let i in people) {
  14. this[i] = people[i]; //將people中的可枚舉屬性和方法遍歷并附給Cat類,公有屬性和私有屬性都是可枚舉屬性;
  15. }
  16. }
  17. var cat = new Cat('藍白色', '小叮當', 2);
  18. console.log(cat.name); //小叮當
  19. cat.eat(); //小叮當賊能吃

四、寄生組合方式繼承

    優(yōu)點:私有屬性和公有屬性都單獨繼承,可以傳參;

    私有屬性可以多繼承,公有屬性不可多繼承;


        
  1. function People(name, age) {
  2. name = name || 'xiaolan';
  3. age = age || 18;
  4. this.name = name;
  5. this.age = age;
  6. }
  7. People.prototype.eat = function() {
  8. console.log(this.name + '賊能吃');
  9. }
  10. function Cat(color, name, age) {
  11. this.color = color;
  12. People.call(this, name, age) //用call的形式把私有屬性繼承過來
  13. }
  14. function Fn() {} //創(chuàng)建一個中間構造函數(shù),用來接收People的公有屬性,為了防止創(chuàng)建實例Cat實例是影響原來的people構造函數(shù)
  15. Fn.prototype = People.prototype;
  16. Cat.prototype = new Fn(); //將中間構造函數(shù)Fn繼承people的公有屬性傳給Cat的原型鏈
  17. Cat.prototype.constructor = Cat; //由于上一步重置了Cat原型鏈的constructor屬性,所以要重新給賦回來;
  18. var cat = new Cat('藍白色', '小叮當', 3);
  19. console.log(cat.name); //'小叮當'
  20. cat.eat() //'小叮當賊能吃


注:若有不嚴謹與錯誤的地方,請多指教!






  1. 這里寫圖片描述



藍藍設計www.sillybuy.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務


經(jīng)驗總結!Material Design和iOS 產(chǎn)品設計的差異化思考

資深UI設計者


如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里

Material Design(以下簡稱MD)是谷歌設計的一套視覺語言設計規(guī)范,主要應用于安卓類應用。


iOS Human Interface Guidelines(以下簡稱iOS)是蘋果公司針對 iOS設計的一套人機交互指南,目的是為了使運行在 iOS 上的應用都能遵從一套特定的視覺以及交互特性,從而能夠在風格上進行統(tǒng)一。

相對來說,我們對于 iOS 的設計規(guī)范更加熟悉——因為考慮到成本,設計師進行產(chǎn)品設計的時候只會出一套 iOS 的設計稿,然后去適配安卓機型。

很少會針對安卓機型再出一套 MD風格的方案,這種現(xiàn)象雖然存在但是并不合理。不同的系統(tǒng)/平臺采用了不同的設計語言,不同的設計語言會培養(yǎng)出不同的操作習慣。

例如使用安卓手機的用戶平時見到的都是 MD風格的界面,突然下了一個 iOS風格的應用,那么操作起來就會很不習慣,增加了學習成本。

為了讓產(chǎn)品可以適用不同平臺用戶的操作習慣,提供 MD 和 iOS 兩套設計稿是非常有必要的。當然 MD 和 iOS 的差異不是一篇文章就能說清楚的,這里我就從陰影、導航和配色這三個方面來簡單分析一下 MD 和 iOS 的差異。

一、陰影

對于不太熟悉 MD 的設計師來說,MD 意味著大色塊+陰影。

為什么 MD 如此癡迷于陰影?

從它的名字就可以看出來——Material Design,這里的 material 指的是紙張;因為來源于現(xiàn)實生活,所以 MD 非常喜歡使用真實世界元素的物理規(guī)律與空間關系來表現(xiàn)組件之間的層級關系,而陰影就是最常見的表現(xiàn)形式:

同樣的賬戶注冊,安卓界面中按鈕帶有陰影而 iOS 界面中按鈕沒有陰影。

FAB(Floating Action Button),帶有陰影的浮動操作按鈕甚至成為了 MD 的一大招牌。相比較而言iOS更加扁平化。

二、導航體系

產(chǎn)品導航體系主要由菜單欄構成,而根據(jù)位置以及交互方式可以分為頂部欄菜單、底部欄菜單和側邊欄菜單。iOS 的導航體系主要由底部欄菜單構成,而 MD 大量使用了頂部欄菜單和側邊欄菜單。

下面我們來看幾個例子:

網(wǎng)易云音樂在 iOS 中采用的是底部欄菜單導航,而在安卓機型上導航欄被移到界面頂部,「賬號」被收到側邊欄中。

b站在 iOS 中有底部欄菜單有5個標簽,而在安卓機型中只有4個標簽,「我的」同樣被側邊欄收起來。

推特在 iOS 中使用的底部欄菜單導航,在安卓機型中導航欄被移到了頂部。

而 Apple Music 做的更徹底,在安卓機型上直接舍棄了底部菜單欄,采用了側邊欄作為主導航模式。

我們發(fā)現(xiàn)前兩款國產(chǎn)應用在安卓機型上都保留了底部欄菜單,而后兩款國外應用直接砍掉底部欄菜單。不只是 Apple music 和推特,很多國外的安卓類應用都沒有使用底部欄菜單。而國內的應用因為考慮到 iOS,即使 MD 化也是閹割版的,屬于 iOS 和 MD 的混血兒。甚至很多安卓應用在設計風格上往 iOS 靠攏,以b站為例,其5.11之前的安卓版本中都是沒有底部欄菜單的。

當然這里并不是去評價 MD 和 iOS 哪個導航體系更好用,我說下自己的觀點:

底部欄菜單的使用非常方便用戶在單手握持情況下的操作,但是對于大屏手機來說,單手操作會顯得很吃力。如果用戶改由雙手握持手機,那么從易用性上來說底部欄菜單沒有任何優(yōu)勢。

MD 的方案更加注重對界面空間的利用,側邊欄菜單就不說了。以底部欄菜單為例,在安卓機型中用戶滑動的時候底部欄菜單會隱藏,方便的用戶可以看下知乎,安卓版的底部欄用戶滑動的時候會隱藏,而 iOS 則是固定不動的。

側邊欄的優(yōu)勢還體現(xiàn)在可以提供更多的標簽,底部欄菜單最多可以放5個。但是側邊欄菜單需要用戶點擊才能調出來,比較隱蔽,而底部欄和頂部欄相對來說就會顯得一目了然,總之各有千秋。

至于為什么 MD 會拋棄底部欄菜單,我個人的理解是設備原因。因為安卓機型底部有三個物理按鍵,如果采用底部欄菜單作為主導航模式,容易造成用戶誤點擊。

類似的還有 web 類應用,因為瀏覽器的控件欄也在底部,所以如果采用了底部欄菜單同樣會造成用戶的誤操作。

三、配色

MD 提倡使用高飽和度的對比色來提升產(chǎn)品的視覺表現(xiàn)力,也就是我在上面提到的大色塊。同樣的一個功能,從底部欄背景色、插畫到按鈕,我們可以發(fā)現(xiàn) iOS 在色彩的使用上比較克制。

知乎之前的安卓版本使用了大面積的藍色,后來改成跟 iOS 一樣的白色。這樣的調整褒貶不一,有的用戶反饋這完全照搬了 iOS,要改回 MD。

產(chǎn)品界面設計中對比效果主要由配色、尺寸、間距和陰影來完成。MD 在配色和陰影上做的比較出彩,所以 MD風格的產(chǎn)品在視覺表現(xiàn)上更有沖擊力。而 iOS 則顯得比較小清新,追求扁平和簡潔。所以我們無法去評判這兩款設計規(guī)范的孰好孰壞,因為其各自的出發(fā)點就是不一樣的。

當然前面也提到了 MD 和 iOS 的差異不僅僅體現(xiàn)在以上說的這三點,還有一些小細節(jié)也非常值得我們思考。我們都知道在 iOS系統(tǒng)中,用戶向右滑動的時候會返回上一級頁面。因為蘋果手機沒有物理返回按鍵,所以這種機制非常受歡迎,但是在一些特定場景的時候就會有問題。例如如果我想復制微博里的「一曲肝腸斷,天涯何處覓知音」,選中光標從左向右滑動,這時就會返回上一級頁面,特別不方便。所以我只能從右向左進行復制,我后來試了一下微信和 QQ,發(fā)現(xiàn)默認復制的是整條動態(tài),這也算是一個折衷的方案。

總結

這篇文章并不是去評判 iOS 和 MD 兩種設計風格孰好孰壞,也不是讓我們現(xiàn)在就去為自己的產(chǎn)品做出兩套設計稿,這個目前來說也不太現(xiàn)實。很多國民類應用都只采用了一套設計稿,大家都這么做,整個大環(huán)境就是這樣。

但是還是那句話:存在不一定合理。出兩套設計稿雖然現(xiàn)在看起來不現(xiàn)實,但是我們也要做好準備,要有危機感。


藍藍設計www.sillybuy.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務

黃金分割在界面設計中的應用

ui設計分享達人

黃金分割大家應該早有耳聞,作為一名設計師,怎么來利用黃金分割線使其構圖更加完美呢?

說實話,構圖時是否使用黃金分割線構圖并不是絕對的,它只是方法之一。但是黃金分割比例在全世界乃至全宇宙確實都是至高無上的。


UI按鈕設計發(fā)展史

藍藍設計的小編

當我們在網(wǎng)上購物,提交我們個人信息都需要用到按鈕。網(wǎng)頁UI設計的增長很快,風格似乎也是一個月一變。最近幾年,我們經(jīng)歷過從文 本鏈接到擬物化設計再到扁平化瀑布流設計。導航是網(wǎng)頁設計中最重要的元素,并且按鈕是最重要的行為工具。

vue在ie9中的兼容問題

seo達人

如果您想訂閱本博客內容,每天自動發(fā)到您的郵箱中, 請點這里

問題總結  https://github.com/vuejs-templates/webpack/issues/260

  1. 首先npm install --save babel-polyfill

  2. 然后在main.js中的最前面引入babel-polyfill

    import 'babel-polyfill'

  3. 在index.html 加入以下代碼(非必須)

    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

  4. 在config中的webpack.base.conf.js中,修改編譯配置


    
  1. entry:{
  2. app:['babel-polyfill','./src/main.js']
  3. }

當然,如果你只用到了 axios 對 promise進行兼容,可以只用 es6-promise

npm install es6-promise --save

在 main.js 中的最前面 引入

import 'es6-promise/auto' 
  • 以上配置,ie9兼容就完成了

那么,就有一個問題了,build之后的dist文件只有放在服務器上才能查看,但本地如何查看呢,參考一下配置

  1. 修改config文件夾中的index.js文件,將build對象中的打包路徑,'/‘改為'./',由絕對路徑改為相對路徑,建議將sourceMap改為false,編譯的時候會快一點

    build: { assetsPublicPath: './', productionSourceMap: false, },

  2. 修改完之后,重新 npm run build ,得到新的dist文件夾

  3. 然后進入dist文件夾

    cd dist

  4. 全局安裝簡易node服務器

    npm install http-server -g

  5. 啟動簡易node服務器

    http-server

  6. 出現(xiàn)如下圖所示,就代表你的服務器啟動成功了,那你也能在5000端口查看編譯打包后的項目了,可以在ie瀏覽器中直接測試了

    這里寫圖片描述

  7. IE在處理日期的時候,不支持-支持/的日期方式 如 2017-01-01應該 


藍藍設計www.sillybuy.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務


日歷

鏈接

個人資料

藍藍設計的小編 http://www.sillybuy.com

存檔