首頁(yè)

你常常忽略的7個(gè)具有破壞性的體驗(yàn)鴻溝

資深UI設(shè)計(jì)者

若想戰(zhàn)勝競(jìng)爭(zhēng)對(duì)手,產(chǎn)品無(wú)疑需要在設(shè)計(jì)上做好提前規(guī)劃,并時(shí)刻樹(shù)立優(yōu)化意識(shí),盡量滿足用戶的體驗(yàn)期望。然而研發(fā)團(tuán)隊(duì)有時(shí)總?cè)菀紫萑胝`區(qū),本篇文章里,作者就產(chǎn)品研發(fā)過(guò)程中可能忽略的、對(duì)用戶體驗(yàn)具有破壞性的因素做了總結(jié),一起來(lái)看一下。

毫無(wú)疑問(wèn),要想獲得出色的用戶體驗(yàn) (UX) 需要在數(shù)字世界中保持競(jìng)爭(zhēng)優(yōu)勢(shì)。盡管如此,由于某些關(guān)鍵盲點(diǎn),改善用戶體驗(yàn)的努力并不總能取得成功。如果忽略這些盲點(diǎn),那么無(wú)論預(yù)算大小和團(tuán)隊(duì)的努力如何,失敗都會(huì)預(yù)先留存在項(xiàng)目中。事實(shí)上,如果實(shí)施不準(zhǔn)確,可能會(huì)導(dǎo)致所謂的“經(jīng)驗(yàn)差距”造成的設(shè)計(jì)上的損失。

你常常忽略的 7 個(gè)具有破壞性的體驗(yàn)鴻溝

上圖所示的具體案例:某銀行投資了近 50 萬(wàn)美元改進(jìn)其手機(jī)銀行應(yīng)用程序,卻導(dǎo)致整體客戶滿意度下降。其根本原因是金融公司未能發(fā)現(xiàn)和預(yù)防不同級(jí)別的內(nèi)部經(jīng)驗(yàn)差距。那么,該如何及時(shí)識(shí)別和避開(kāi)這些盲點(diǎn),以保障耗資巨大的大規(guī)模數(shù)字化項(xiàng)目的成功呢?

一、即使預(yù)算龐大,用戶體驗(yàn)工作也可能失敗 UX efforts can fail even with huge budgets

在過(guò)去十年中,大量研究證實(shí),用戶體驗(yàn)對(duì)公司市場(chǎng)效率存在優(yōu)先影響。根據(jù)甲骨文的一份報(bào)告,如果糟糕的用戶體驗(yàn)導(dǎo)致多個(gè)業(yè)務(wù)問(wèn)題,那么積極的用戶體驗(yàn)會(huì)增加推薦、保留率和收入,因?yàn)?86% 的客戶愿意為更好的用戶體驗(yàn)支付更多費(fèi)用。

看起來(lái)一切都很簡(jiǎn)單——只要增加預(yù)算和成本,就足以提供最好的體驗(yàn)?但在實(shí)際操作中,這并不容易。根據(jù)貝恩公司的研究,80% 的 CEO 認(rèn)為他們提供了卓越的體驗(yàn),而只有 8% 的客戶同意這一點(diǎn)。

其主要原因可以用“經(jīng)驗(yàn)鴻溝”來(lái)解釋——這是客戶期望的體驗(yàn)與他們從數(shù)字服務(wù)中獲得的體驗(yàn)之間的負(fù)面差異。如果體驗(yàn)比預(yù)期的差很多,就會(huì)產(chǎn)生許多令人不快的后果,比如客戶忠誠(chéng)度下降、大量負(fù)面評(píng)論,甚至客戶決定離開(kāi)品牌。

在大多數(shù)情況下,人們往往無(wú)法認(rèn)識(shí)到真正的經(jīng)驗(yàn)鴻溝。

即使公司的領(lǐng)導(dǎo)和員工覺(jué)得有些地方不對(duì)勁,他們也往往不明白“要改進(jìn)什么”以及“為什么要改進(jìn)”。如果沒(méi)有意識(shí)到某件事,就不可能管理它。

二、現(xiàn)實(shí)生活中的例子:行動(dòng)中的經(jīng)驗(yàn)鴻溝 Real-life example: Experience gap in action

為了解釋“經(jīng)驗(yàn)鴻溝”可能導(dǎo)致麻煩的基本原理,我想分享一個(gè)現(xiàn)實(shí)生活中的例子。

幾年前,一家知名且受人尊敬的中歐銀行開(kāi)始了大規(guī)模的數(shù)字化轉(zhuǎn)型之旅。當(dāng)時(shí),該銀行的應(yīng)用程序的評(píng)級(jí)為 3.5,并且已經(jīng)過(guò)時(shí)。所以,為了實(shí)現(xiàn)數(shù)字化、提升銀行形象,并在不斷增長(zhǎng)的數(shù)字市場(chǎng)中獲得競(jìng)爭(zhēng)機(jī)會(huì),管理層打算緊急創(chuàng)建并推出一款現(xiàn)代化的銀行應(yīng)用程序。因此,最初的設(shè)計(jì)和開(kāi)發(fā)周期為 6 個(gè)月。

盡管如此,銀行還是花了三倍時(shí)間(1 年零八個(gè)月)自主構(gòu)建新應(yīng)用程序。無(wú)論從時(shí)間來(lái)說(shuō),還是從投資預(yù)算來(lái)說(shuō),這都可以稱得上是一個(gè)重要項(xiàng)目。從項(xiàng)目的范圍、所做改進(jìn)和時(shí)間表來(lái)看,總成本估計(jì)在 50 萬(wàn)左右。

然而,結(jié)果完全沒(méi)有達(dá)到預(yù)期。新應(yīng)用發(fā)布后,它從之前的 3.5 下降到 2.4,并且因?yàn)樗鼪](méi)有改進(jìn),以至一年后,其評(píng)分仍在下降,其用戶體驗(yàn)也日漸惡化。

銀行盡一切努力改善用戶體驗(yàn),整個(gè)團(tuán)隊(duì)努力工作近兩年,怎么會(huì)發(fā)生這種情況?

這種情況的產(chǎn)生,正是由于“經(jīng)驗(yàn)鴻溝”的存在。盡管該銀行啟動(dòng)數(shù)十名頂級(jí)專業(yè)人士花費(fèi)了 20 個(gè)月和 50 萬(wàn)來(lái)改良產(chǎn)品,但它仍未滿足用戶的期望。

雖然客戶不滿意的真正原因是無(wú)意識(shí)的“體驗(yàn)鴻溝”,但公司往往傾向于通過(guò)指責(zé)外部環(huán)境來(lái)解釋它。例如市場(chǎng)的變化、競(jìng)爭(zhēng)對(duì)手的活動(dòng)、創(chuàng)新的出現(xiàn)、消費(fèi)模式的變化。當(dāng)然,這也是客觀事實(shí),但一家適應(yīng)性強(qiáng)的公司應(yīng)該考慮將這些因素用于其增長(zhǎng),而不是作為“替罪羊”。

但衡量適應(yīng)效果的最重要方式是公司服務(wù)在多大程度上滿足甚至超過(guò)了消費(fèi)者的期望。沒(méi)有意識(shí)到他們服務(wù)和客戶期望之間存在差距的公司注定無(wú)法適應(yīng)外部環(huán)境的變化。

在某些情況下,公司的行為甚至?xí)?dǎo)致經(jīng)驗(yàn)鴻溝擴(kuò)大到臨界水平。這通常會(huì)導(dǎo)致目標(biāo)客戶對(duì)公司產(chǎn)品和服務(wù)的需求急劇下降。

如果我們回到這個(gè)例子,似乎管理層對(duì)重大改進(jìn)是否可以成功充滿信心,并投入了大量資金和精力進(jìn)行廣告宣傳。同時(shí),那些宣傳此應(yīng)用程序現(xiàn)代、創(chuàng)新和友好的廣告,激發(fā)了消費(fèi)者的高期望,以至于大大超出了其服務(wù)的實(shí)際質(zhì)量。

結(jié)果,當(dāng)產(chǎn)品最終發(fā)布時(shí),客戶驚訝地發(fā)現(xiàn)他們的期望落空了,新應(yīng)用程序比改良前更糟糕。并且相關(guān)的負(fù)面評(píng)論不僅出現(xiàn)在 App Store 和 Google Play 上,也在社交媒體上大量涌現(xiàn),人們?cè)谕铺厣喜粩嘀S刺該銀行失敗的數(shù)字化項(xiàng)目。

三、對(duì)鴻溝的不了解是主要威脅 Unawareness of the Gap is the main threat

接下來(lái),讓我們探討一下數(shù)字服務(wù)和用戶期望之間的鴻溝是如何形成的,以及為什么沒(méi)有人能夠阻止它。

事實(shí)上,最大的挑戰(zhàn)是大家往往很難注意到這些差距。他們的原因并不明顯,并且可以同時(shí)存在于各個(gè)組織架構(gòu)之上。此外,它們的影響令人難以察覺(jué),以至于最終會(huì)導(dǎo)致意想不到的破壞性后果。最終,直到團(tuán)隊(duì)面對(duì)產(chǎn)品在市場(chǎng)上的失敗,才有人明白原因是什么。

彌合鴻溝的主要困難在于,級(jí)別越高,對(duì)經(jīng)驗(yàn)鴻溝的不了解程度越高。實(shí)際上,在組織架構(gòu)的頂部,通常會(huì)找到造成鴻溝的根源。級(jí)別越低,離用戶越近,員工越能覺(jué)察到問(wèn)題和差距,但他們往往沒(méi)有權(quán)力和能力去消除它們,他們受制于文化。

在這種特殊情況下,售后部門(mén)每天都會(huì)接到數(shù)千個(gè)關(guān)于產(chǎn)品問(wèn)題的電話,但由于業(yè)務(wù)流程分散,他們對(duì)此也無(wú)能為力。

客戶的挫敗感變得更加強(qiáng)烈。即使是最簡(jiǎn)單的日常場(chǎng)景,他們面臨的問(wèn)題也難以執(zhí)行,但他們從銀行員工那里得到的反饋是,他們并不是唯一產(chǎn)生困惑的人,而且目前銀行正忙于交付新功能,而不是修復(fù)當(dāng)前問(wèn)題。

使事情變得復(fù)雜的是,經(jīng)驗(yàn)鴻溝背后的內(nèi)部流程是由過(guò)去促進(jìn)公司生存和增長(zhǎng)的相同機(jī)制引起的。該公司受制于過(guò)去的成功。就像諾基亞一樣,這家全球最大的以硬件為中心的手機(jī)工廠,在蘋(píng)果智能手機(jī)引領(lǐng)的軟件革命中被徹底擊敗。

由于任何組織都有惰性,這些機(jī)制受到內(nèi)在信念和價(jià)值觀的影響,對(duì)適應(yīng)市場(chǎng)和彌合經(jīng)驗(yàn)鴻溝造成了阻礙。

首先,應(yīng)該在管理層面解決鴻溝。因此,級(jí)別越低,離領(lǐng)導(dǎo)層越遠(yuǎn),離客戶越近,就越能感受和認(rèn)識(shí)到鴻溝的存在。自然,一線員工將擁有從那些期望沒(méi)有得到滿足的客戶那里得到最多的數(shù)據(jù)。

四、7 種體驗(yàn)鴻溝盲點(diǎn) The 7 types of experience gap blind spots

主要的體驗(yàn)鴻溝可能是由組織中七個(gè)層次(文化、反饋、執(zhí)行、設(shè)計(jì)、價(jià)值、品牌承諾、情感聯(lián)系)中的一個(gè)或幾個(gè)盲點(diǎn)造成的。

你常常忽略的 7 個(gè)具有破壞性的體驗(yàn)鴻溝

1. 文化鴻溝

在文化層面缺乏以顧客為中心的理念,員工無(wú)法使服務(wù)更接近客戶期望導(dǎo)致了“文化鴻溝”。在具有“文化鴻溝”的公司中,有助于以客戶為中心的流程和活動(dòng)都是處于低優(yōu)先級(jí)的,相應(yīng)的,它們也不會(huì)得到相關(guān)的資源。

2. 反饋鴻溝

缺乏關(guān)于客戶期望和他們對(duì)產(chǎn)品或服務(wù)的體驗(yàn)數(shù)據(jù)會(huì)造成“反饋鴻溝”。在這種情況下,公司可能經(jīng)常收集數(shù)據(jù),但沒(méi)有對(duì)其進(jìn)行分析,也沒(méi)有采取任何措施來(lái)改善這種情況。

3. 設(shè)計(jì)鴻溝

即使優(yōu)先考慮以客戶為中心的方法,并且收集了大量有關(guān)客戶期望的數(shù)據(jù),但在設(shè)計(jì)能力和方法上仍可能存在鴻溝。擁有合適的專業(yè)知識(shí),就可以構(gòu)建高質(zhì)量的數(shù)字產(chǎn)品生態(tài)系統(tǒng),從而根據(jù)客戶需求提供最佳服務(wù)。

4. 執(zhí)行鴻溝

這種鴻溝與糟糕的設(shè)計(jì)執(zhí)行有關(guān)。如果不優(yōu)先以用戶為中心的來(lái)設(shè)計(jì)產(chǎn)品,那么創(chuàng)建最終產(chǎn)品和服務(wù)的決策和努力將注定是低質(zhì)量和低效率的。這決定了公司在數(shù)字時(shí)代創(chuàng)造有競(jìng)爭(zhēng)力的服務(wù)和產(chǎn)品的能力。

5. 價(jià)值鴻溝

如果設(shè)計(jì)生態(tài)系統(tǒng)在 價(jià)值金字塔的五個(gè)層次(功能、可用性、美學(xué)、地位、使命)上不符合用戶的期望,就會(huì)形成價(jià)值鴻溝。

6. 過(guò)度承諾的鴻溝

正如我在上述銀行案例中所表明的那樣,如果一家公司只顧著積極推廣其服務(wù),承諾一些產(chǎn)品無(wú)法提供的東西,它會(huì)導(dǎo)致用戶對(duì)期望的更大失望。因此,由于廣告承諾與現(xiàn)實(shí)不符,對(duì)該服務(wù)的負(fù)面評(píng)價(jià)可能會(huì)翻倍。

7. 情感鴻溝

如果品牌傳播是純粹的信息傳播,專注于功能特征,那么就無(wú)法與用戶形成情感聯(lián)系。由于人類(lèi)基于情感做出決策,因此基于情感構(gòu)建服務(wù)價(jià)值會(huì)對(duì)客戶期望和最終用戶體驗(yàn)產(chǎn)生積極影響。

五、彌合經(jīng)驗(yàn)鴻溝 Bridging the experience gap

每個(gè)客戶都會(huì)不知不覺(jué)地根據(jù)自己的期望來(lái)評(píng)估他們所接受的服務(wù)。用戶體驗(yàn)質(zhì)量所引發(fā)的情感將形成品牌的聲譽(yù)。

在現(xiàn)代世界,數(shù)字渠道已成為品牌的主要“營(yíng)銷(xiāo)”和公關(guān)渠道。

一個(gè)應(yīng)用程序,即使有一百年的服務(wù)客戶歷史和其他渠道的優(yōu)質(zhì)服務(wù),負(fù)面體驗(yàn)也會(huì)破壞品牌推廣的所有努力。

這僅僅是因?yàn)樵跀?shù)字時(shí)代,移動(dòng)渠道占主導(dǎo)地位,對(duì)于某些人來(lái)說(shuō),它正在成為與品牌互動(dòng)的唯一途徑。這就是為什么了解如何彌合數(shù)字產(chǎn)品出現(xiàn)的七個(gè)體驗(yàn)鴻溝的方法如此重要。

1. 彌合文化鴻溝

在文化方面,轉(zhuǎn)型基于高層心態(tài)的改變并將這種影響滲透到整個(gè)的公司文化和內(nèi)部?jī)r(jià)值觀。特別是,可形成“以客戶為中心”的體驗(yàn)思維模式。

2. 彌合反饋鴻溝

在銀行案例中,開(kāi)始彌合反饋鴻溝的第一步,是深入了解社交媒體上的負(fù)面評(píng)論以及致電售后部門(mén)的電話。接近這些客戶才容易消除反饋鴻溝。事實(shí)上,他們比管理層更了解應(yīng)解決哪些問(wèn)題,并且往往渴望積極分享自己的情緒并希望得到傾聽(tīng)。如果一家公司足夠開(kāi)放并準(zhǔn)備好接受批評(píng),它可以使用這些數(shù)據(jù)來(lái)彌合鴻溝并提高產(chǎn)品迭代的敏捷性。

3. 彌合設(shè)計(jì)鴻溝

通過(guò)整合設(shè)計(jì)方法和設(shè)計(jì)思維來(lái)制定彌合鴻溝的策略,可以使用設(shè)計(jì)金字塔。該框架從五個(gè)層次(流程、團(tuán)隊(duì)、行動(dòng)、結(jié)果和價(jià)值)確定了能夠提高公司整體效率的設(shè)計(jì)集成。

4. 彌合執(zhí)行鴻溝

組織必須將經(jīng)過(guò)驗(yàn)證的設(shè)計(jì)執(zhí)行方法(例如設(shè)計(jì)思維、HCD 或 UX 設(shè)計(jì)方法)與分步系統(tǒng)相結(jié)合,以設(shè)計(jì)符合客戶期望并能夠彌合執(zhí)行鴻溝的數(shù)字產(chǎn)品。

5. 彌合價(jià)值鴻溝

產(chǎn)品的功能級(jí)別為客戶創(chuàng)造真正的價(jià)值和利益并通過(guò)提供卓越的可用性進(jìn)行功能擴(kuò)展;美學(xué) ——令人驚嘆的視覺(jué)識(shí)別;狀態(tài) —— 針對(duì)產(chǎn)品特定受眾的個(gè)性化,最后是建立產(chǎn)品的價(jià)值觀與使命。

6. 彌補(bǔ)過(guò)度承諾的鴻溝

數(shù)字時(shí)代的客戶要求透明、關(guān)懷、誠(chéng)實(shí)和開(kāi)放的溝通。由于網(wǎng)絡(luò)效應(yīng),幾乎不可能銷(xiāo)售劣質(zhì)產(chǎn)品,因?yàn)槊總€(gè)人都可以在社交媒體上發(fā)布負(fù)面反饋,而這些負(fù)面反饋將深深地?fù)p害客戶的信任。因此,做出不僅可以兌現(xiàn),甚至可以超額兌現(xiàn)的承諾至關(guān)重要。

7. 彌合情感鴻溝

對(duì)客戶的同情和關(guān)懷比以往任何時(shí)候都更加重要。在品牌與客戶之間建立情感聯(lián)系對(duì)于確保長(zhǎng)期忠誠(chéng)度和需求至關(guān)重要。這種聯(lián)系是通過(guò)之前涵蓋的所有階段建立的——將客戶放在第一位的正確心態(tài);收集反饋并在此基礎(chǔ)上進(jìn)行改進(jìn);使用正確的工具和方法來(lái)創(chuàng)建產(chǎn)品設(shè)計(jì)和生態(tài)系統(tǒng);創(chuàng)造真正的價(jià)值和利益,最后,通過(guò)誠(chéng)實(shí)和超額兌現(xiàn)承諾。

六、成為深受喜愛(ài)品牌的途徑 The pathway toward becoming a beloved brand

該途徑涵蓋了可能破壞數(shù)字產(chǎn)品創(chuàng)造的 7 個(gè)主要體驗(yàn)鴻溝,以及可以幫助避免和解決這些鴻溝的 7 個(gè)橋梁。如果一個(gè)品牌能意識(shí)到這些盲點(diǎn),它可以立即獲得比仍處于盲點(diǎn)的競(jìng)爭(zhēng)對(duì)手的顯著市場(chǎng)優(yōu)勢(shì)。

僅憑意識(shí)就可以產(chǎn)生巨大的差異,但將意識(shí)與行動(dòng)相結(jié)合會(huì)導(dǎo)致長(zhǎng)期成功,成為一個(gè)需求量很大和深受喜愛(ài)的品牌。

本文翻譯已獲得作者的正式授權(quán)(授權(quán)截圖如下)

你常常忽略的 7 個(gè)具有破壞性的體驗(yàn)鴻溝

藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼ben_lanlan,報(bào)下信息,會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

文章來(lái)源:人人都是產(chǎn)品經(jīng)理  作者:TCC翻譯情報(bào)局

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


在線音樂(lè)殺出個(gè)程咬金

資深UI設(shè)計(jì)者

今日,有消息稱字節(jié)跳動(dòng)將會(huì)推出一款名為“飛樂(lè)”的音樂(lè)流媒體產(chǎn)品。字節(jié)跳動(dòng)的入局,或?qū)⒁鹨魳?lè)行業(yè)的新波瀾。本文作者對(duì)此發(fā)表了自己的觀點(diǎn),一起來(lái)看看吧。

擅長(zhǎng)“四路出擊”的字節(jié)跳動(dòng),又雙叒叕出手了……

長(zhǎng)期以來(lái),關(guān)于字節(jié)跳動(dòng)擴(kuò)張的消息就一直不斷。前有抖音內(nèi)測(cè)“心動(dòng)外賣(mài)”進(jìn)軍外賣(mài)領(lǐng)域,后有字節(jié)跳動(dòng)收購(gòu)VR公司的消息登上熱搜……近日,有報(bào)道稱字節(jié)跳動(dòng)將于今年下半年推出一款音樂(lè)流媒體產(chǎn)品,產(chǎn)品的名稱暫定為“飛樂(lè)”,項(xiàng)目?jī)?nèi)部代號(hào)為“l(fā)una”。而字節(jié)跳動(dòng)的再次入局,或?qū)⒁鹨魳?lè)行業(yè)的新波瀾。

一、堅(jiān)持不懈的音樂(lè)夢(mèng)

今年4月,字節(jié)跳動(dòng)成立了音樂(lè)事業(yè)部;7月份的時(shí)候,字節(jié)跳動(dòng)將音樂(lè)升級(jí)為P1優(yōu)先級(jí)業(yè)務(wù),與游戲業(yè)務(wù)和教育業(yè)務(wù)平級(jí);不久之后還內(nèi)測(cè)了音樂(lè)代理發(fā)行平臺(tái)“銀河方舟”。除了自身做音樂(lè)之外,字節(jié)跳動(dòng)還投資了校園音樂(lè)平臺(tái)。這一系列動(dòng)作無(wú)一不展現(xiàn)了字節(jié)跳動(dòng)發(fā)力音樂(lè)領(lǐng)域的決心,而字節(jié)跳動(dòng)之所以如此看重音樂(lè)業(yè)務(wù)也是有一定原因的。

首先,音樂(lè)業(yè)務(wù)有助于字節(jié)跳動(dòng)獲取新流量。據(jù)CNNIC發(fā)布的第47次《中國(guó)互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告》顯示,截至2020年12月,我國(guó)的網(wǎng)絡(luò)音樂(lè)用戶規(guī)模達(dá)6.58億,與2020年3月相比增長(zhǎng)了2311萬(wàn),占網(wǎng)民整體的66.6%。其中,手機(jī)網(wǎng)絡(luò)音樂(lè)用戶規(guī)模達(dá)6.57億,與2020年3月相比增長(zhǎng)了2379萬(wàn)。隨著短視頻領(lǐng)域流量見(jiàn)頂,字節(jié)跳動(dòng)亟需找尋到新的流量增長(zhǎng)點(diǎn)。

其次,音樂(lè)行業(yè)用戶的付費(fèi)意愿在逐步增強(qiáng)。據(jù)前瞻產(chǎn)業(yè)研究院發(fā)布的相關(guān)報(bào)告顯示,我國(guó)的網(wǎng)絡(luò)音樂(lè)付費(fèi)用戶規(guī)模已經(jīng)由2016年的2017萬(wàn)人,增長(zhǎng)至2020年的7192萬(wàn)人,網(wǎng)絡(luò)音樂(lè)付費(fèi)滲透率也由2016年的4.0%增長(zhǎng)至2020年的10.9%。網(wǎng)絡(luò)音樂(lè)用戶的月度消費(fèi)金額也由2017年的8.5元,增長(zhǎng)至2020年的9.5元。

以騰訊音樂(lè)為例,據(jù)其最新發(fā)布的二季度財(cái)報(bào)顯示,截至2021年6月30日,騰訊音樂(lè)的在線音樂(lè)付費(fèi)用戶人數(shù)達(dá)到了6620萬(wàn),同比增長(zhǎng)了40.6%,與今年一季度相比凈增長(zhǎng)了530萬(wàn)人;付費(fèi)率為10.6%,與去年同期和今年一季度的付費(fèi)率相比均有所提升。

最后,音樂(lè)業(yè)務(wù)與字節(jié)跳動(dòng)旗下的短視頻業(yè)務(wù)相輔相成。配樂(lè)是制作短視頻必不可少的環(huán)節(jié)之一,配樂(lè)和內(nèi)容契合度極高的優(yōu)質(zhì)短視頻往往能收獲很高的播放量,但也正因短視頻配樂(lè)使抖音多次陷入侵權(quán)局面,不少短視頻也因其所使用的音樂(lè)無(wú)版權(quán)而被做下架處理。倘若字節(jié)跳動(dòng)推出音樂(lè)產(chǎn)品,就能夠?yàn)槎桃曨l用戶提供更為方便的曲庫(kù)支持,有利于短視頻用戶進(jìn)行創(chuàng)作。

二、逐夢(mèng)音樂(lè)有“加成”

7月24日,國(guó)家市場(chǎng)監(jiān)管總局責(zé)令騰訊音樂(lè)解除其網(wǎng)絡(luò)音樂(lè)獨(dú)家版權(quán);8月31日,騰訊發(fā)布了《關(guān)于放棄音樂(lè)版權(quán)獨(dú)家授權(quán)權(quán)利的聲明》。眾多音樂(lè)平臺(tái)不再被音樂(lè)版權(quán)“卡脖子”,字節(jié)跳動(dòng)于此時(shí)再度發(fā)力數(shù)字音樂(lè),自然也能享受到行業(yè)大環(huán)境變化所帶來(lái)的重大利好。除此之外,還有其他原因也會(huì)對(duì)字節(jié)跳動(dòng)發(fā)展音樂(lè)業(yè)務(wù)產(chǎn)生積極影響。

其一,是其擁有龐大的流量?jī)?yōu)勢(shì)。據(jù)抖音發(fā)布的《2020抖音數(shù)據(jù)報(bào)告》顯示,截止2020年12月,抖音的日均視頻搜索次數(shù)突破4億;截止2020年8月,抖音的日活躍用戶數(shù)量突破6億。有抖音這一巨大流量池為其引流,無(wú)論是音樂(lè)流媒體產(chǎn)品的用戶獲取,還是音樂(lè)作品宣發(fā)都會(huì)容易一些。

9月9日,工信部相關(guān)業(yè)務(wù)部門(mén)召開(kāi)了“屏蔽網(wǎng)址鏈接問(wèn)題行政指導(dǎo)會(huì)”,提出有關(guān)即時(shí)通信軟件的合規(guī)標(biāo)準(zhǔn),要求9月17日前各平臺(tái)按標(biāo)準(zhǔn)解除屏蔽。隨著屏蔽外鏈的解除,字節(jié)跳動(dòng)也將從中獲益,迎來(lái)新一波流量增長(zhǎng)。

其二,是創(chuàng)作者扶持計(jì)劃成效顯現(xiàn)。早在2018年,抖音就啟動(dòng)了“看見(jiàn)音樂(lè)計(jì)劃”以扶持原創(chuàng)音樂(lè),隨著不斷進(jìn)行的音樂(lè)扶持計(jì)劃,抖音的音樂(lè)生態(tài)也在逐漸完善。據(jù)《2020抖音音樂(lè)生態(tài)數(shù)據(jù)報(bào)告》顯示,2020上半年抖音的音樂(lè)人入駐數(shù)量增長(zhǎng)近3萬(wàn);近半年抖音音樂(lè)人漲粉累計(jì)超3億,其中漲粉超1000萬(wàn)的音樂(lè)人有6位,漲粉超500萬(wàn)的音樂(lè)人有23位。

而抖音扶持音樂(lè)計(jì)劃的成功,也給字節(jié)跳動(dòng)的音樂(lè)流媒體產(chǎn)品打了樣。字節(jié)跳動(dòng)在發(fā)展音樂(lè)業(yè)務(wù)時(shí),也可以采用類(lèi)似的策略進(jìn)行音樂(lè)產(chǎn)品內(nèi)容生態(tài)的完善。另外,部分抖音音樂(lè)人也可能成為字節(jié)跳動(dòng)音樂(lè)業(yè)務(wù)的潛在音樂(lè)人,為字節(jié)跳動(dòng)音樂(lè)業(yè)務(wù)的發(fā)展添磚加瓦。

其三,算法優(yōu)勢(shì)助力音樂(lè)業(yè)務(wù)發(fā)展。眾所周知,算法是字節(jié)跳動(dòng)的一大特色,今日頭條和抖音能取得當(dāng)前的成績(jī),與字節(jié)跳動(dòng)的算法推薦不無(wú)關(guān)系。據(jù)悉,字節(jié)跳動(dòng)的音樂(lè)業(yè)務(wù)主要由前臺(tái)和市場(chǎng)、算法兩大中臺(tái)支持構(gòu)成。在中臺(tái)方面,由抖音的市場(chǎng)團(tuán)隊(duì)承擔(dān)國(guó)內(nèi)音樂(lè)人合作與版權(quán)宣發(fā),算法團(tuán)隊(duì)負(fù)責(zé)提供智能配樂(lè)、安全風(fēng)控等技術(shù)支持。

三、在線音樂(lè)硝煙起

無(wú)論是后版權(quán)時(shí)代的來(lái)臨,還是字節(jié)跳動(dòng)自身的優(yōu)勢(shì)都對(duì)其發(fā)展音樂(lè)業(yè)務(wù)大有裨益,但機(jī)遇與挑戰(zhàn)并存,字節(jié)跳動(dòng)在迎來(lái)重大利好的同時(shí),依然面臨著不小的挑戰(zhàn)。

一方面,騰訊音樂(lè)的霸主地位難以動(dòng)搖。在“取消網(wǎng)絡(luò)音樂(lè)獨(dú)家版權(quán)”尚未落地之前,騰訊音樂(lè)憑借海量的正版歌曲曲庫(kù)以及持續(xù)建設(shè)的內(nèi)容生態(tài),穩(wěn)居行業(yè)頭部。據(jù)騰訊音樂(lè)發(fā)布的財(cái)報(bào)顯示,今年二季度騰訊音樂(lè)的在線音樂(lè)月活躍用戶數(shù)為6.23億,僅月活躍用戶數(shù)這一項(xiàng)指標(biāo),字節(jié)跳動(dòng)在短時(shí)期內(nèi)就很難與之相匹敵。

另一方面,網(wǎng)易云音樂(lè)的音樂(lè)社區(qū)文化別具一格。在被音樂(lè)版權(quán)“卡脖子”的時(shí)期,網(wǎng)易云音樂(lè)憑借其音樂(lè)社區(qū)文化,成功地從眾多音樂(lè)平臺(tái)中脫穎而出,濃郁的社區(qū)氛圍也極大地提高了用戶的黏性。另外,網(wǎng)易云音樂(lè)不斷推出的扶持計(jì)劃也增強(qiáng)了其內(nèi)容競(jìng)爭(zhēng)力。

網(wǎng)易云音樂(lè)的這些特色化優(yōu)勢(shì),也將為其在今后的發(fā)展中提供助力,但對(duì)字節(jié)跳動(dòng)來(lái)說(shuō),擁有這些差異化優(yōu)勢(shì)的網(wǎng)易云音樂(lè),無(wú)疑是一位強(qiáng)勁的對(duì)手。

另外,快手也在音樂(lè)領(lǐng)域有所布局。早在2018年的時(shí)候,快手就推出了一款音樂(lè)產(chǎn)品“光音Mulight”;今年2月26日,快手推出了音樂(lè)K歌APP“回森”;5月份的時(shí)候,快手推出了音樂(lè)APP“小森唱”,該軟件的核心功能是AI創(chuàng)作詞曲用戶進(jìn)行演唱,在演唱之后還可以通過(guò)點(diǎn)贊評(píng)論等方式進(jìn)行互動(dòng),最終達(dá)到社交的目的。隨著快手在音樂(lè)領(lǐng)域的不斷加碼,也會(huì)對(duì)字節(jié)跳動(dòng)音樂(lè)流媒體產(chǎn)品的發(fā)展產(chǎn)生影響。

目前來(lái)看,隨著行業(yè)大環(huán)境的變化,在線音樂(lè)領(lǐng)域的競(jìng)爭(zhēng)愈發(fā)激烈已經(jīng)是無(wú)可辯駁的事實(shí)。無(wú)論是穩(wěn)居頭部的騰訊音樂(lè),還是擅長(zhǎng)打情懷牌的網(wǎng)易云音樂(lè),亦或是跨界而來(lái)的快手,都是字節(jié)跳動(dòng)音樂(lè)流媒體產(chǎn)品的強(qiáng)勁對(duì)手。而字節(jié)跳動(dòng)能否在強(qiáng)手如云的音樂(lè)行業(yè)闖出一片天,仍待時(shí)間驗(yàn)證。

文章來(lái)源:人人都是產(chǎn)品經(jīng)理  作者:韭菜財(cái)經(jīng)

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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

行業(yè)研究:分析框架與思考維度

資深UI設(shè)計(jì)者

做好行業(yè)研究,有助于企業(yè)或個(gè)體從業(yè)人員更好地洞察市場(chǎng),進(jìn)一步發(fā)現(xiàn)機(jī)會(huì),或者找準(zhǔn)產(chǎn)品定位,推動(dòng)企業(yè)戰(zhàn)略決策和后續(xù)實(shí)施。本篇文章里,作者就行業(yè)研究的分析框架與思考維度做了總結(jié)和梳理,一起來(lái)看一下。


一、行業(yè)研究的目的

以始為終,構(gòu)建行業(yè)研究的方法論和分析框架,需要從目的出發(fā),下面列舉幾類(lèi)典型的行業(yè)研究報(bào)告目的。

券商的報(bào)告(二級(jí)市場(chǎng)),分析某個(gè)行業(yè)是否有投資價(jià)值,從行業(yè)賽道的選擇過(guò)渡到這個(gè)行業(yè)賽道中的值得被投資的公司,說(shuō)明這個(gè)行業(yè)中哪些公司更有投資價(jià)值。報(bào)告結(jié)果是要用于股票投資服務(wù)的。二級(jí)市場(chǎng)由于公司財(cái)務(wù)報(bào)告的披露性質(zhì),公司的財(cái)報(bào)分析在行業(yè)報(bào)告中也是重要的構(gòu)成部分。

互聯(lián)網(wǎng)戰(zhàn)略投資部門(mén)/VC的報(bào)告(一級(jí)市場(chǎng)),互聯(lián)網(wǎng)戰(zhàn)略投資部門(mén)通常以公司的戰(zhàn)略發(fā)展目標(biāo)為出發(fā)點(diǎn),布局上/下游產(chǎn)業(yè)鏈,或通過(guò)收購(gòu)競(jìng)品公司,鞏固和發(fā)展公司在行業(yè)的競(jìng)爭(zhēng)力,提升市場(chǎng)占有率,開(kāi)拓新的市場(chǎng);VC通過(guò)布局細(xì)分的賽道,選擇合適的投資標(biāo)的,參與風(fēng)險(xiǎn)投資。

值得注意的是在互聯(lián)網(wǎng)初創(chuàng)企業(yè)的財(cái)報(bào)分析通常不作為重要參考因素,多數(shù)互聯(lián)網(wǎng)公司在初創(chuàng)期將投入大量資金,長(zhǎng)期處于虧損狀態(tài),此時(shí),市場(chǎng)份額和估值與傳統(tǒng)二級(jí)市場(chǎng)的分析方式有較大差異。

咨詢公司的報(bào)告,目的是為行業(yè)內(nèi)的公司服務(wù)的,說(shuō)明該行業(yè)的行業(yè)規(guī)律、行業(yè)風(fēng)險(xiǎn)、行業(yè)機(jī)會(huì)、行業(yè)發(fā)展趨勢(shì)等。在行業(yè)研究的內(nèi)容方面,咨詢公司常見(jiàn)的模式還包括訪談?wù){(diào)研行業(yè)內(nèi)公司高管。

二、行業(yè)研究的常規(guī)分析框架

基于行業(yè)研究的目的,常規(guī)的行業(yè)研究框架,包括一下幾個(gè)核心部分:宏觀分析、行業(yè)分析、公司分析、消費(fèi)者分析、競(jìng)爭(zhēng)者分析,其中宏觀分析和行業(yè)分析的視角都是從賽道鏈路的角度,進(jìn)行整體分析,而公司、消費(fèi)者和競(jìng)爭(zhēng)者則是從市場(chǎng)參與者的角度進(jìn)行分析。

1. 宏觀分析

1)宏觀分析思考的維度

  1. 宏觀分析的因素大多非直接影響行業(yè)和公司,而是通過(guò)影響宏觀基本面,進(jìn)而對(duì)行業(yè)產(chǎn)生間接影響。
  2. 在宏觀分析中,多數(shù)分析不是僅僅是單因子影響,而是混合因子影響的結(jié)合。
  3. 除了行業(yè)分析的分析范圍,宏觀分析應(yīng)該考慮更廣闊的范圍要素,例如如果限定為某一國(guó)家的具體的某一行業(yè)研究,需要將宏觀分析的內(nèi)容范圍擴(kuò)展至全球范圍內(nèi)的影響要素分析,將中外的宏觀影響影響都考慮到。
  4. 最后,宏觀分析需要考慮時(shí)間維度,不能局限于靜態(tài)分析,既要考慮存量數(shù)據(jù),也要考慮趨勢(shì)變化,同時(shí)考慮增量數(shù)據(jù)。

2)宏觀分析考慮的內(nèi)容:

宏觀分析中考慮的因素點(diǎn)對(duì)行業(yè)環(huán)境的影響,因素點(diǎn)可采用PEST模型分類(lèi),但不必拘泥于PEST模型,因素點(diǎn)間可能是組成多因素,從而對(duì)行業(yè)環(huán)境產(chǎn)生間接或直接影響。基于PEST模型,因素點(diǎn)可以分為:

① 經(jīng)濟(jì)類(lèi)

包括經(jīng)濟(jì)發(fā)展水平、社會(huì)經(jīng)濟(jì)結(jié)構(gòu)和宏觀經(jīng)濟(jì)政策,其中經(jīng)濟(jì)發(fā)展水平可以通過(guò)較為典型的量化指標(biāo)進(jìn)行衡量,例如GDP\CPI\進(jìn)出口規(guī)模等;宏觀經(jīng)濟(jì)政策主要包括貨幣政策和財(cái)政政策;社會(huì)經(jīng)濟(jì)結(jié)構(gòu)主要體現(xiàn)在經(jīng)濟(jì)體制和產(chǎn)業(yè)結(jié)構(gòu)構(gòu)成。

② 政治類(lèi)

包括政治體制、政局穩(wěn)定性、和相關(guān)的政治政策。

其中政治體制包括資本主義、社會(huì)主義和中國(guó)特色社會(huì)主義等,政治體制對(duì)行業(yè)的影響為間接影響;政策包括投資政策、環(huán)保政策、進(jìn)出口政策、貨幣政策和財(cái)政政策等,也有針對(duì)具體行業(yè)的政策,例如近期發(fā)布的教育“雙減”政策就對(duì)在線教育行業(yè)產(chǎn)生了不小沖擊,網(wǎng)絡(luò)安全隱私數(shù)據(jù)保護(hù)政策對(duì)互聯(lián)網(wǎng)公司獲取用戶使用偏好數(shù)據(jù),產(chǎn)生了非常大的影響。

其次,除了政治政策,政局的穩(wěn)定性對(duì)行業(yè)發(fā)展穩(wěn)定產(chǎn)生重要影響。

③ 文化環(huán)境類(lèi)

包括人口因素、社會(huì)流動(dòng)性和消費(fèi)心理,此類(lèi)因素可與消費(fèi)者分析關(guān)聯(lián),對(duì)消費(fèi)者細(xì)分市場(chǎng)和市場(chǎng)定位產(chǎn)生了重要的影響,主要從聚類(lèi)的角度,對(duì)消費(fèi)群進(jìn)行分析。

人口因素主要考慮人口總數(shù)、年齡構(gòu)成、性別比例、教育水平、人口地理分布等,社會(huì)流動(dòng)性主要考慮社會(huì)階級(jí)流動(dòng)性和貧富差距;消費(fèi)心理主要包括生活方式、文化傳統(tǒng)和價(jià)值觀等,對(duì)消費(fèi)者偏好心理產(chǎn)生影響,從而影響消費(fèi)者的行為決策。

④ 科技類(lèi)

主要包括專利技術(shù)數(shù)量和質(zhì)量、相關(guān)產(chǎn)業(yè)技術(shù)等,科技對(duì)一個(gè)產(chǎn)業(yè)的生產(chǎn)效率與產(chǎn)品更新,甚至一個(gè)產(chǎn)業(yè)的萌芽和滅亡都將產(chǎn)生巨大的影響,例如智能芯片對(duì)手機(jī)行業(yè)產(chǎn)生了巨大的沖擊,原有的非智能手機(jī)迅速被智能手機(jī)取代,生產(chǎn)非智能手機(jī)的廠商迅速破產(chǎn)。

綜上,宏觀類(lèi)因素多數(shù)為混合因子對(duì)產(chǎn)業(yè)產(chǎn)生直接或者間接的影響。

2. 產(chǎn)業(yè)分析

1)產(chǎn)業(yè)分析思考的維度

① 整體市場(chǎng)分析

整體市場(chǎng)分析除了關(guān)注靜態(tài)的存量市場(chǎng),也需要關(guān)注動(dòng)態(tài)的增量市場(chǎng)。市場(chǎng)的現(xiàn)有市場(chǎng)規(guī)模和增速?zèng)Q定了市場(chǎng)的規(guī)模,體現(xiàn)為市場(chǎng)的“寬”度和市場(chǎng)的“長(zhǎng)”度,行業(yè)壁壘和驅(qū)動(dòng)因素影響參與市場(chǎng)的玩家數(shù)量,體現(xiàn)為市場(chǎng)的“陡”度。

② 市場(chǎng)參與者

市場(chǎng)參與者從各個(gè)角度,在產(chǎn)業(yè)分析上有不同的分析時(shí)間,例如從產(chǎn)業(yè)鏈角度,分析上下游供應(yīng)商和購(gòu)買(mǎi)者、從行業(yè)參與者的角度,分析競(jìng)爭(zhēng)者和行業(yè)集中程度。

③ 影響因素

產(chǎn)業(yè)影響因素和宏觀影響因素的區(qū)別在于,產(chǎn)業(yè)影響因素從供給需求、驅(qū)動(dòng)和壁壘的角度分析更為直接的影響因素對(duì)產(chǎn)業(yè)產(chǎn)生的影響。

2)宏觀分析考慮的內(nèi)容

① 產(chǎn)業(yè)規(guī)模

產(chǎn)業(yè)規(guī)??梢詮目臻g維度進(jìn)行解析,產(chǎn)業(yè)的寬度代表現(xiàn)有市場(chǎng)規(guī)模,產(chǎn)業(yè)的長(zhǎng)度以時(shí)間為維度,代表增長(zhǎng)率和增長(zhǎng)率增速,而產(chǎn)業(yè)規(guī)模=現(xiàn)有市場(chǎng)規(guī)模*增速。

由此可見(jiàn)產(chǎn)業(yè)規(guī)模的衡量有兩個(gè)重要的衡量標(biāo)準(zhǔn)和指標(biāo),即市場(chǎng)規(guī)模與復(fù)合年均增長(zhǎng)率(CAGR),市場(chǎng)有多寬指行業(yè)規(guī)模有多大、增長(zhǎng)的天花板有多高,是衡量一個(gè)行業(yè)現(xiàn)有市場(chǎng)容量和將來(lái)市場(chǎng)發(fā)展空間的最重要的標(biāo)準(zhǔn),現(xiàn)有市場(chǎng)容量決定了該市場(chǎng)有多少蛋糕可以分,而市場(chǎng)增速?zèng)Q定了行業(yè)發(fā)展?jié)摿?,行業(yè)增速可與行業(yè)的成熟度曲線緊密聯(lián)系。

② 產(chǎn)業(yè)生命周期

產(chǎn)業(yè)的生命周期以時(shí)間為維度,一般分為導(dǎo)入期、成長(zhǎng)期、成熟期和衰退期。產(chǎn)業(yè)生命周期在導(dǎo)入期、成長(zhǎng)期、成熟期和衰退期的不同階段,可以從經(jīng)營(yíng)風(fēng)險(xiǎn)、財(cái)務(wù)風(fēng)險(xiǎn)、產(chǎn)品差異、單位利潤(rùn)、產(chǎn)品特征等不同維度進(jìn)行分析,詳見(jiàn)下圖。

③ 產(chǎn)業(yè)鏈

產(chǎn)業(yè)鏈分為上游供應(yīng)商、下游購(gòu)買(mǎi)者、潛在進(jìn)入者和現(xiàn)在競(jìng)爭(zhēng)者,將企業(yè)放在產(chǎn)業(yè)鏈進(jìn)行分析,需要對(duì)供應(yīng)商和購(gòu)買(mǎi)者有較高的議價(jià)權(quán),能有效面對(duì)競(jìng)爭(zhēng)者。

其中,影響供應(yīng)商議價(jià)能力的影響因素包括市場(chǎng)占有率、轉(zhuǎn)換成本和供應(yīng)商戰(zhàn)略,影響購(gòu)買(mǎi)者議價(jià)能力的影響因素包括價(jià)格敏感度,相對(duì)議價(jià)能力等,影響潛在進(jìn)入者的障礙有結(jié)構(gòu)性障礙和行為障礙,影響替代品威脅的主要因素包括產(chǎn)品同質(zhì)化程度和勞動(dòng)生產(chǎn)效率等。

④ 產(chǎn)業(yè)驅(qū)動(dòng)因素與行業(yè)壁壘

產(chǎn)業(yè)的驅(qū)動(dòng)因素主要分為兩個(gè)部分,第一是生產(chǎn)要素驅(qū)動(dòng),第二是相關(guān)支持性產(chǎn)業(yè)驅(qū)動(dòng),其中,生產(chǎn)要素包括高級(jí)生產(chǎn)要素和初級(jí)生產(chǎn)要素,而相關(guān)支持性產(chǎn)業(yè),則表現(xiàn)為產(chǎn)業(yè)鏈上下游的聚集驅(qū)動(dòng)。

行業(yè)壁壘:行業(yè)壁壘分為限制性要素和市場(chǎng)壁壘,可以通俗理解為一只“看得見(jiàn)”的手和“看不見(jiàn)”的手,即政策限制和市場(chǎng)限制。

政策限制如進(jìn)出口限制、許可證、配額等,實(shí)現(xiàn)限制如規(guī)模效益使得成本降低,對(duì)新進(jìn)入的小規(guī)模玩家形成行業(yè)壁壘,又比如缺乏品牌技術(shù),而只能成為代加工企業(yè),獲取最低的生產(chǎn)制造利潤(rùn)等。

如果行業(yè)的門(mén)檻很高,競(jìng)爭(zhēng)者難以進(jìn)入市場(chǎng),行業(yè)的壟斷程度也相應(yīng)比較高,通常用行業(yè)集中度來(lái)分析衡量,即CR5(行業(yè)中前5名的企業(yè)占據(jù)的市場(chǎng)份額)。

但是,壟斷程度越高,企業(yè)越有機(jī)會(huì)獲得超額利潤(rùn),但行業(yè)的壟斷程度并非僅僅由行業(yè)壁壘所決定,消費(fèi)者的需求差異也會(huì)對(duì)壟斷程度產(chǎn)生重要影響,例如手機(jī)行業(yè)的壟斷程度較高,而餐飲行業(yè)卻很難出現(xiàn)寡頭壟斷,因?yàn)椴惋嫷南M(fèi)者偏好差異非常大。

⑤ 供求分析

供給側(cè)主要包括產(chǎn)能分析,同時(shí)也受行業(yè)集中程度的影響,即上文所述的行業(yè)壟斷程度,產(chǎn)能分析包括產(chǎn)能利用率水平、庫(kù)存周期、產(chǎn)品使用壽命、訂單周期,這里比較典型的行業(yè)是電子產(chǎn)品生產(chǎn)制造業(yè)。

需求側(cè)主要從消費(fèi)者市場(chǎng)出發(fā)進(jìn)行分析,同時(shí)考慮替代品,需求預(yù)測(cè)包括消費(fèi)者整體購(gòu)買(mǎi)力和細(xì)分需求市場(chǎng),這里的消費(fèi)者整體購(gòu)買(mǎi)力受到宏觀因素的影響,例如人均可支配收入、貧富差距等;替代品的細(xì)分影響因素包括國(guó)家進(jìn)出口和國(guó)內(nèi)市場(chǎng)替代品。

⑥ 產(chǎn)業(yè)結(jié)構(gòu)

產(chǎn)品結(jié)構(gòu):產(chǎn)品結(jié)構(gòu)可以從加工階段和主導(dǎo)構(gòu)成不同的視角進(jìn)行分析,加工階段主要以產(chǎn)業(yè)鏈維度為分析視角,從初級(jí)產(chǎn)品、中間產(chǎn)品和最終產(chǎn)品進(jìn)行分析,主導(dǎo)構(gòu)成主要從驅(qū)動(dòng)因素進(jìn)行分析,分為勞動(dòng)密集型產(chǎn)品、資金密集型產(chǎn)品和技術(shù)密集型產(chǎn)品等。

市場(chǎng)結(jié)構(gòu):市場(chǎng)結(jié)構(gòu)從分類(lèi)上可以分為市場(chǎng)主體結(jié)構(gòu)、市場(chǎng)客體結(jié)構(gòu)、市場(chǎng)空間結(jié)構(gòu)和市場(chǎng) 時(shí)間結(jié)構(gòu),從行業(yè)集中程度,可以分為完全競(jìng)爭(zhēng)市場(chǎng)、完全壟斷市場(chǎng)、壟斷競(jìng)爭(zhēng)市場(chǎng)和寡頭壟斷市場(chǎng)等,影響行業(yè)集中程度的因素在前文已經(jīng)提及。

3. 市場(chǎng)參與者——公司與競(jìng)爭(zhēng)者

1)公司思考的維度

① 戰(zhàn)略

戰(zhàn)略需要將企業(yè)放置在宏觀和產(chǎn)業(yè)的角度,通過(guò)對(duì)賽道、競(jìng)爭(zhēng)者和消費(fèi)者的分析,制定戰(zhàn)略,從整體分配資源,規(guī)劃產(chǎn)品和服務(wù)。

② 經(jīng)營(yíng)分析

經(jīng)營(yíng)分析從數(shù)據(jù)量化的指標(biāo),動(dòng)態(tài)指導(dǎo)經(jīng)營(yíng)過(guò)程中的業(yè)務(wù)發(fā)展。運(yùn)用定量分析、業(yè)務(wù)分析和行為分析相結(jié)合的方法,對(duì)企業(yè)進(jìn)行綜合分析的一種現(xiàn)代經(jīng)營(yíng)分析體系。包括:經(jīng)營(yíng)基礎(chǔ)分析、財(cái)務(wù)分析、市場(chǎng)分析、勞務(wù)分析、生產(chǎn)分析、物資分析等。從業(yè)務(wù)單元的視角優(yōu)化運(yùn)營(yíng)。

2)公司分析考慮的內(nèi)容

① 戰(zhàn)略分析

戰(zhàn)略分析包括企業(yè)能力與資源分析、價(jià)值鏈分析、產(chǎn)品組合分析、外部分析、內(nèi)部分析、財(cái)務(wù)指標(biāo)分析和商業(yè)模式分析等。

  • 外部分析:外部分析從企業(yè)所面臨的產(chǎn)業(yè)環(huán)境出發(fā),分析企業(yè)在產(chǎn)業(yè)環(huán)境中所面臨的機(jī)會(huì)和威脅
  • 內(nèi)部分析:內(nèi)部分析從企業(yè)內(nèi)部經(jīng)營(yíng)的角度出發(fā),分析企業(yè)所擁有的資源與能力的優(yōu)勢(shì)和劣勢(shì),即下文所展開(kāi)的企業(yè)能力與資源。企業(yè)的外部分析和內(nèi)部分析構(gòu)成了SWOT模型。
  • 企業(yè)能力與資源:從企業(yè)能力的視角可以分為研發(fā)能力、生產(chǎn)管理能力、營(yíng)銷(xiāo)能力、組織管理能力、財(cái)務(wù)能力等,這些能力構(gòu)成了企業(yè)的核心能力,成為企業(yè)在市場(chǎng)中競(jìng)爭(zhēng)的制勝因素,構(gòu)成了企業(yè)的護(hù)城河,其次,從企業(yè)資源的視角,可以分為有形資源和無(wú)形資源。
  • 價(jià)值鏈:可以分為基礎(chǔ)設(shè)施和基本活動(dòng)兩大類(lèi),其中基礎(chǔ)設(shè)施包括財(cái)務(wù)、戰(zhàn)略、法務(wù)、人力資源、技術(shù)開(kāi)發(fā)和采購(gòu)管理,基本活動(dòng)包括內(nèi)部后勤、生產(chǎn)經(jīng)營(yíng)、外部后勤、市場(chǎng)營(yíng)銷(xiāo)和運(yùn)營(yíng)。
  • 商業(yè)模式:從企業(yè)提供產(chǎn)品和盈利模式出發(fā),主要關(guān)注一類(lèi)企業(yè)在市場(chǎng)中與用戶、供應(yīng)商、其他合作伙伴(即營(yíng)銷(xiāo)的任務(wù)環(huán)境的各主體)的關(guān)系,尤其是彼此間的物流、信息流和資金流。
  • 產(chǎn)品組合:從提供的服務(wù)和產(chǎn)品出發(fā),例如零售行業(yè)中的品類(lèi)策略,包括產(chǎn)品線的和SKU的設(shè)置,即品類(lèi)的長(zhǎng)度和深度,也可以從經(jīng)典的波士頓矩陣出發(fā),分析銷(xiāo)售增長(zhǎng)率和市場(chǎng)占有率的矩陣,針對(duì)明星業(yè)務(wù)、問(wèn)題業(yè)務(wù)、瘦狗業(yè)務(wù)和金牛業(yè)務(wù)制定不同的策略。
  • 財(cái)務(wù)指標(biāo):從財(cái)務(wù)指標(biāo),以始為終,進(jìn)行測(cè)算和分析,包括毛利率、現(xiàn)金流、ROE等。

② 戰(zhàn)略選擇

戰(zhàn)略選擇可以從總體戰(zhàn)略和智能單元戰(zhàn)略出發(fā),如果業(yè)務(wù)涉及海外業(yè)務(wù),需要分析選擇國(guó)際化經(jīng)營(yíng)戰(zhàn)略。

  • 總體戰(zhàn)略:總體策略是公司的總策略,可分為發(fā)展戰(zhàn)略、穩(wěn)定戰(zhàn)略和收縮戰(zhàn)略,其中發(fā)展戰(zhàn)略可以分為一體化、密集型和多元化戰(zhàn)略。
  • 職能戰(zhàn)略:從業(yè)務(wù)單元視角,制定單元戰(zhàn)略,一般包括營(yíng)銷(xiāo)、生產(chǎn)研發(fā)、運(yùn)營(yíng)、人力和采購(gòu)戰(zhàn)略。例如營(yíng)銷(xiāo)戰(zhàn)略中需要制定細(xì)分市場(chǎng)STP,進(jìn)行營(yíng)銷(xiāo)戰(zhàn)略的選擇,包括產(chǎn)品、渠道、促銷(xiāo)和分銷(xiāo)(4P)等,其余業(yè)務(wù)單元策略,在此不做過(guò)多的贅述。
  • 國(guó)際經(jīng)營(yíng)戰(zhàn)略:根據(jù)全球化協(xié)作程度和本土獨(dú)立性和適應(yīng)能力的差別,本土企業(yè)的國(guó)際化經(jīng)營(yíng)戰(zhàn)略可以分為四種類(lèi)型,即國(guó)際化戰(zhàn)略、多國(guó)本土化戰(zhàn)略、全球戰(zhàn)略與跨國(guó)戰(zhàn)略。

3)競(jìng)爭(zhēng)者思考的維度

  • 優(yōu)勢(shì):競(jìng)爭(zhēng)者分析的思路可以簡(jiǎn)單分為,發(fā)現(xiàn)優(yōu)勢(shì)是什么,以及采取何種策略發(fā)大優(yōu)勢(shì),形成企業(yè)的護(hù)城河。
  • 劣勢(shì):其次,競(jìng)爭(zhēng)者分析需要思考與競(jìng)爭(zhēng)者相比,企業(yè)的劣勢(shì)是什么,如何縮小這種劣勢(shì)。

4)競(jìng)爭(zhēng)者分析考慮的內(nèi)容

  • 競(jìng)爭(zhēng)分析:競(jìng)爭(zhēng)分析主要從前文所述的企業(yè)資源和能力角度進(jìn)行分析,包括產(chǎn)品優(yōu)勢(shì),技術(shù)壁壘、分銷(xiāo)渠道優(yōu)勢(shì)、用戶增量和存量、財(cái)務(wù)狀況、組織架構(gòu)、核心管理層(人才資源)等視角分析,同一賽道的不同玩家在市場(chǎng)中的競(jìng)爭(zhēng)力。
  • 戰(zhàn)略選擇:基于競(jìng)爭(zhēng)分析,針對(duì)賽道中的競(jìng)爭(zhēng)者,可以采取不同的競(jìng)爭(zhēng)者戰(zhàn)略,主要包括三類(lèi),即藍(lán)海戰(zhàn)略、中小企業(yè)戰(zhàn)略和基本競(jìng)爭(zhēng)戰(zhàn)略,其中,基本競(jìng)爭(zhēng)戰(zhàn)略可以分為成本領(lǐng)先戰(zhàn)略,差異化戰(zhàn)略和集中化戰(zhàn)略。

4. 消費(fèi)者

1)消費(fèi)者思考的維度

細(xì)分市場(chǎng)與精準(zhǔn)營(yíng)銷(xiāo):在互聯(lián)網(wǎng)數(shù)字化的革新下,原有的消費(fèi)者聚類(lèi)分析越來(lái)越精細(xì)化,不僅有群體的聚類(lèi)標(biāo)簽,個(gè)體消費(fèi)者的標(biāo)簽也能層層穿透,為精準(zhǔn)營(yíng)銷(xiāo)運(yùn)營(yíng)提供了條件。

2)消費(fèi)者分析考慮的內(nèi)容

基本屬性:基本屬性包括年齡、收入、性別、受教育程度和地域分布等。

購(gòu)買(mǎi)動(dòng)機(jī)和購(gòu)買(mǎi)行為:根據(jù)MBA智庫(kù)的定義,營(yíng)銷(xiāo)學(xué)家把消費(fèi)者的購(gòu)買(mǎi)動(dòng)機(jī)和購(gòu)買(mǎi)行為概括為6W和6O,從而形成消費(fèi)者購(gòu)買(mǎi)行為研究的基本框架。

① 市場(chǎng)需要什么(What)——有關(guān)產(chǎn)品(Objects)是什么。通過(guò)分析消費(fèi)者希望購(gòu)買(mǎi)什么,為什么需要這種商品而不是需要那種商品,研究企業(yè)應(yīng)如何提供適銷(xiāo)對(duì)路的產(chǎn)品去滿足消費(fèi)者的需求。

② 為何購(gòu)買(mǎi)(Why)——購(gòu)買(mǎi)目的(Objectives)是什么。通過(guò)分析購(gòu)買(mǎi)動(dòng)機(jī)的形成(生理的、自然的、經(jīng)濟(jì)的、社會(huì)的、心理因素的共同作用),了解消費(fèi)者的購(gòu)買(mǎi)目的,采取相應(yīng)的市場(chǎng)策略。

③ 購(gòu)買(mǎi)者是誰(shuí)(Who)——購(gòu)買(mǎi)組織(Organizations)是什么。分析購(gòu)買(mǎi)者是個(gè)人、家庭還是集團(tuán),購(gòu)買(mǎi)的產(chǎn)品供誰(shuí)使用,誰(shuí)是購(gòu)買(mǎi)的決策者、執(zhí)行者、影響者。根據(jù)分析,組合相應(yīng)的產(chǎn)品、渠道、定價(jià)和促銷(xiāo)。

④ 如何購(gòu)買(mǎi)(How)——購(gòu)買(mǎi)組織的作業(yè)行為(Operations)是什么。分析購(gòu)買(mǎi)者對(duì)購(gòu)買(mǎi)方式的不同要求,有針對(duì)性地提供不同的營(yíng)銷(xiāo)服務(wù)。在消費(fèi)者市場(chǎng),分析不同的類(lèi)型消費(fèi)者的特點(diǎn),如經(jīng)濟(jì)型購(gòu)買(mǎi)者對(duì)性能和廉價(jià)的追求,沖動(dòng)性者對(duì)情趣和外觀的喜好,手頭拮據(jù)的購(gòu)買(mǎi)者要求分期付款,工作繁忙的購(gòu)買(mǎi)者重視購(gòu)買(mǎi)方便和送貨上門(mén)等。

⑤ 何時(shí)購(gòu)買(mǎi)(When)——購(gòu)買(mǎi)時(shí)機(jī)(Occasions)是什么。分析購(gòu)買(mǎi)者對(duì)特定產(chǎn)品的購(gòu)買(mǎi)時(shí)間的要求,把握時(shí)機(jī),適時(shí)推出產(chǎn)品,如分析自然季節(jié)和傳統(tǒng)節(jié)假日對(duì)市場(chǎng)購(gòu)買(mǎi)的影響程度等。

⑥ 何處購(gòu)買(mǎi)(Where)——購(gòu)買(mǎi)場(chǎng)合(Outlets)是什么。分析購(gòu)買(mǎi)者對(duì)不同產(chǎn)品的購(gòu)買(mǎi)地點(diǎn)的要求,如快速消費(fèi)品,顧客一般要求就近購(gòu)買(mǎi),而選購(gòu)品則要求在商業(yè)區(qū)購(gòu)買(mǎi),一邊挑選對(duì)比,特殊品往往會(huì)要求直接到企業(yè)或?qū)Yu(mài)店購(gòu)買(mǎi)等。

三、總結(jié)

綜上所述,行業(yè)研究的框架可從宏觀、賽道、市場(chǎng)參與者進(jìn)行分析。


文章來(lái)源:人人都是產(chǎn)品經(jīng)理  作者:Elaine.H

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


如何提升用戶登錄成功率

資深UI設(shè)計(jì)者

什么是登錄?

登錄是進(jìn)入一個(gè)應(yīng)用程序 、網(wǎng)站或服務(wù)的入口。幫助用戶建立他們的賬戶。

  • 一個(gè)登錄流程通常包括一個(gè)主要的登錄頁(yè)和一個(gè)相當(dāng)復(fù)雜的重置流程,其中包括 “忘記密碼”、重置密碼和其他登錄方法。
  • 登錄的首要目標(biāo)是確保用戶成功登錄到他們的賬戶。

什么是登錄目標(biāo)?

讓我們花點(diǎn)時(shí)間來(lái)定義一下“登錄目標(biāo)”這個(gè)術(shù)語(yǔ),這是在做設(shè)計(jì)決策時(shí)的關(guān)鍵。

登錄目標(biāo)是指用戶進(jìn)入登錄流程的意愿。以有聲思維來(lái)表達(dá),它可以是 “我想登錄”、“我想檢查我的電子郵件”、“帶我去那里”,等等。

當(dāng)用戶進(jìn)入到登錄頁(yè)時(shí),他們可能沒(méi)有登錄意愿??赡軙?huì)產(chǎn)生“嗯,我不在乎,以后再做”或“這太麻煩了”或“呀,我現(xiàn)在該怎么辦?”的想法。忘記密碼、半路遇到困難或切換到另一個(gè)頁(yè)面/設(shè)備,都可能是缺乏登陸意愿的跡象。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

我們得到了登陸目標(biāo)

保留或增強(qiáng)登錄流程中的登陸意愿是很好的目標(biāo),下面的準(zhǔn)則都是為這個(gè)目標(biāo)量身定做的。

設(shè)計(jì)熟悉的體驗(yàn)

設(shè)計(jì)熟悉的體驗(yàn),雖說(shuō)不是設(shè)計(jì)師最喜歡的設(shè)計(jì)準(zhǔn)則,但是與整個(gè)生態(tài)系統(tǒng)中最好的體驗(yàn)保持一致是非常重要的。例如使用簡(jiǎn)單、公認(rèn)的布局,使用眾所周知的術(shù)語(yǔ)和文案,都有助于用戶自信而輕松地進(jìn)行熟悉的操作。

保持通用的設(shè)計(jì)也有助于將頁(yè)面輕松擴(kuò)展到不同的形式和設(shè)備。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Pinterest 有一個(gè)傳統(tǒng)的、居中的覆蓋式登錄頁(yè)。它有一個(gè)亮紅色的主要登錄按鈕,并提供 Google 和 Facebook 作為額外的社交登錄選項(xiàng)。

滑到最后,有我對(duì)網(wǎng)絡(luò)上流行的成功登錄經(jīng)驗(yàn)的總結(jié)。這就把我們帶到了下一個(gè)問(wèn)題 —— 創(chuàng)新的界限在哪里?

登錄是一個(gè)品牌展示的絕佳機(jī)會(huì)點(diǎn)。在視覺(jué)上,它可能使用品牌色、品牌照片、品牌插圖,甚至是營(yíng)銷(xiāo)信息。和大多數(shù)設(shè)計(jì)問(wèn)題一樣,登錄頁(yè)品牌展示的關(guān)鍵在于平衡。登錄操作應(yīng)該一直占據(jù)中心位置。頁(yè)面上的其他元素必須謹(jǐn)慎規(guī)劃好,不應(yīng)該奪走登陸操作的注意力。

一條優(yōu)秀的經(jīng)驗(yàn)之談:用戶在登錄頁(yè)面上花費(fèi)的時(shí)間越少越好。幫助他們繼續(xù)前進(jìn),盡快發(fā)現(xiàn)產(chǎn)品中的優(yōu)點(diǎn)和價(jià)值。

聚焦設(shè)計(jì)

快速回顧一下:用戶在登錄頁(yè)面上花費(fèi)的時(shí)間越少越好。根據(jù)這一點(diǎn),登錄(或恢復(fù))操作應(yīng)當(dāng)占據(jù)用戶的全部注意力。

  • 最好是把登錄框放在頁(yè)面的中心。如果你打算把它放在一側(cè),最好是賦予它核心視覺(jué)效果。
  • 對(duì)于文案寫(xiě)作來(lái)說(shuō),指明用戶在某一步驟中到底需要做什么才是很重要的!比起冗長(zhǎng)的解釋,一句簡(jiǎn)單的 “輸入密碼”就能起效。幽默、復(fù)雜的行話、技術(shù)術(shù)語(yǔ)和花哨的文筆在登錄體驗(yàn)中是沒(méi)有用武之地的。

在恢復(fù)體驗(yàn)中,將一套復(fù)雜的操作分解成多個(gè)步驟是很有效的。安排用戶一次只做一件重要的事情!例如:輸入你的手機(jī)號(hào)碼和輸入發(fā)送到你手機(jī)上的驗(yàn)證碼是兩個(gè)獨(dú)立的步驟。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Facebook 在頁(yè)面中保持用戶信息在右側(cè),并將恢復(fù)流程分解為多個(gè)步驟。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

亞馬遜把它的恢復(fù)流程分解成多個(gè)步驟。它將次要的恢復(fù)選項(xiàng)設(shè)置為 “我需要更多幫助 ”的可擴(kuò)展部分,這有助于保持注意力集中在主要操作。

保持注意力集中在主要操作的技巧:

  • 登錄框可以布局在一個(gè)主頁(yè)、疊加頁(yè),或一個(gè)獨(dú)立頁(yè)面。
  • 使用卡片式布局
  • 將操作分為主要和次要操作
  • 使用一個(gè)大而醒目的登錄按鈕
  • 盡量減少次要操作的數(shù)量 —— 避免出現(xiàn)任何與核心登錄操作無(wú)關(guān)的內(nèi)容。

給予明確的反饋并在用戶失敗時(shí)提供幫助

在登錄過(guò)程的每個(gè)階段,用戶都可能失敗。電子郵件地址輸入錯(cuò)誤、密碼輸入錯(cuò)誤或忘記密碼、網(wǎng)絡(luò)問(wèn)題,所有這些都可能導(dǎo)致登錄意愿的急劇下降。因此,登錄界面以最恰當(dāng)?shù)姆绞交貞?yīng)用戶是非常重要的。清晰、及時(shí)、精心編輯的錯(cuò)誤提示信息能起到很大幫助。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

錯(cuò)誤信息包含有用的提示/暗示,指明你在失敗時(shí)可以做什么

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

當(dāng)你密碼登陸失敗,但你有一個(gè) Gmail ID 時(shí),F(xiàn)acebook 會(huì)增加一個(gè) “用 Google 賬號(hào)登錄 ”的功能

指導(dǎo)用戶恢復(fù)的技巧:

  • 鼓勵(lì)用戶嘗試合適的替代方案
  • 在用戶失敗后,安排替代的登錄方案,同時(shí)將用戶導(dǎo)航至一個(gè)獨(dú)立的頁(yè)面
  • 在文本中展示出最有用的登錄方案,并在出現(xiàn)錯(cuò)誤時(shí)對(duì)用戶做出積極響應(yīng)!

盡量保留登錄痕跡

重點(diǎn)是讓用戶知道平臺(tái)識(shí)別出了他們,并提供一個(gè)歡迎回歸的體驗(yàn)。這有助于提升用戶的登錄意愿。

保留登錄痕跡的方法:

  • 像 “記住我”這樣的功能
  • 預(yù)先填寫(xiě)上一步收集到的字段,例如:在跳轉(zhuǎn)到恢復(fù)流程時(shí),預(yù)先填寫(xiě)登錄步驟中收集到的電子郵件 ID
  • 如果使用的是兩步式登錄,為用戶提供個(gè)性化的登錄方式是個(gè)不錯(cuò)的主意 —— 用戶對(duì)電話OTP(一次性驗(yàn)證碼)登錄更滿意?還是電子郵件+密碼?記住用戶上次選擇的登陸方式可以提升用戶的登錄意愿,并讓他們感覺(jué)到登錄體驗(yàn)的自然和舒適。
  • 在企業(yè) SSO(單點(diǎn)登錄) 中,用戶可能會(huì)用多個(gè)賬戶登錄。在檢測(cè)到多個(gè)賬戶的情況下,最好是將這些賬戶選項(xiàng)呈現(xiàn)給用戶,讓他們選擇他們想使用的賬戶。

靈活提供多種登錄方式

對(duì)于你的平臺(tái)應(yīng)該提供哪些登錄方法,沒(méi)有一個(gè)放之四海而皆準(zhǔn)的方案。最好是提供一到兩種額外的方法(除了用戶名+密碼),這樣用戶就有了選擇,以防他們忘記密碼。這些方法可以是基于電話號(hào)碼的登錄、人臉識(shí)別,或最常見(jiàn)的社交登錄,如 Google、Twitter、LinkedIn 或 Facebook。如果你正在考慮社交登錄,思考為平臺(tái)添加最流行和最安全的方案。

需要注意的是 —— 增加很多的登陸方法會(huì)使頁(yè)面變得混亂,可能會(huì)導(dǎo)致登錄意愿降低!將額外的選項(xiàng)限制在 2 或 3 種。

針對(duì)最常用的登陸方式進(jìn)行優(yōu)化,并明確區(qū)分主要和次要方式。這些選項(xiàng)通常被證明是需要重置密碼(以防用戶忘記密碼)的很好的替代方法,但同時(shí)也被認(rèn)為是一個(gè)乏味的步驟。情況允許時(shí),應(yīng)智能地浮現(xiàn)其他登陸選項(xiàng)并進(jìn)行個(gè)性化處理。例如:如果用戶是通過(guò)電子郵件登錄,提供一個(gè)帶有一次性鏈接的登錄選項(xiàng)可能會(huì)有效。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

在此提供 Medium 登錄頁(yè)的案例。雖然清晰且設(shè)計(jì)良好,但它確實(shí)有太多的登錄方法。不得不回訪 Medium 的設(shè)計(jì)者,如果這個(gè)設(shè)計(jì)對(duì)他們來(lái)說(shuō)是好的!

無(wú)密碼登錄正火速流行起來(lái)。特別對(duì)于只有移動(dòng)端的應(yīng)用程序來(lái)說(shuō),基于電話號(hào)碼的認(rèn)證已常態(tài)化。指紋和 FaceID 在許多地方出現(xiàn),使認(rèn)證流程變得快速、安全。為平臺(tái)找到最適合(且可開(kāi)發(fā))的方法,并將其作為主要登錄選項(xiàng)。

登錄是信任敏感的時(shí)刻

登錄涉及到用戶輸入敏感的個(gè)人數(shù)據(jù),如電子郵件、密碼和電話號(hào)碼 —— 這是決定了他們與平臺(tái)關(guān)系的敏感時(shí)刻。

登錄框代表了品牌,任何視覺(jué)上的改變都必須緩慢進(jìn)行——因?yàn)檎w的視覺(jué)變化可能會(huì)失去用戶信任。

登錄也是(有用的)保障 —— 足以讓壞人無(wú)法進(jìn)入系統(tǒng)!

雖然減少普通用戶的操作是很重要的,但如果我們懷疑用戶可能是黑客,那么出現(xiàn)額外的認(rèn)證也變得很重要。這可能是一個(gè)很好的機(jī)會(huì)去提醒用戶能夠采取哪些措施來(lái)加強(qiáng)他們賬戶的安全性 —— 例如:強(qiáng)密碼、雙重認(rèn)證等。

通過(guò)調(diào)研確定用戶類(lèi)型

之前有提到過(guò),投入足夠的時(shí)間去調(diào)研用戶,有助于提高登錄意愿!這一點(diǎn)是很重要的。

登錄是一種體驗(yàn),你的用戶角色可以是各種各樣的 —— 每個(gè)人都可能擁有一個(gè)你平臺(tái)的服務(wù)賬戶!如果可能的話,縮小你的角色范圍。

情況允許時(shí),像我這樣(為社交媒體平臺(tái)設(shè)計(jì)),可以嘗試以下方案:

  1. 登錄漏斗 —— 與項(xiàng)目管理人員合作,找出用戶在登錄流程中互動(dòng)和放棄的關(guān)鍵點(diǎn)。
  2. 登錄入口 —— 用戶是通過(guò)電子郵件進(jìn)入登錄頁(yè)面?還是通過(guò)搜索引擎的結(jié)果?還是當(dāng)他們?cè)谑褂卯a(chǎn)品時(shí)?或是在應(yīng)用程序中?你可以利用這些入口點(diǎn)作為線索,為用戶展現(xiàn)出最相關(guān)的選項(xiàng)。
  3. 已知的設(shè)備 —— 手機(jī)、瀏覽器和已知的設(shè)備可以有助于為用戶提供受歡迎的、個(gè)性化的登陸體驗(yàn)。
  4. 用戶群組 —— 根據(jù)用戶特性進(jìn)行劃分,如網(wǎng)絡(luò)/移動(dòng)、年齡組和地域,也能有幫助。
  5. 在用戶沒(méi)有登錄時(shí),使用這些線索可以增加用戶的登錄意愿。采取微小的步驟進(jìn)行用戶識(shí)別,并且使用戶易于接受。這有助于你提高登錄成功率!反之這也會(huì)為你的平臺(tái)帶來(lái)更多的活躍用戶,每個(gè)人都能成為贏家。

案例介紹

以下是我對(duì)網(wǎng)絡(luò)上我最喜歡的登錄頁(yè)進(jìn)行的總結(jié),包含一些我經(jīng)常訪問(wèn)的平臺(tái)。歡迎推薦更多登錄頁(yè)!

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Google(谷歌)打破了標(biāo)識(shí)優(yōu)先的格式 —— 改成了分步式登錄模式,在不同的步驟中輸入電子郵件和密碼。這種模式對(duì)于 Google 有安全優(yōu)勢(shì),也可以使他們?cè)诮酉聛?lái)的步驟中為用戶提供個(gè)性化的選擇。頁(yè)面也是最小的、全白的、聚焦的。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Uber 的登錄頁(yè)是簡(jiǎn)單且聚焦的,允許用戶輸入他們的電話號(hào)碼并進(jìn)入下一步。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Facebook 有幾個(gè)登錄方案,他們用這些方案進(jìn)行實(shí)驗(yàn)和 A/B 測(cè)試 —— 這是一個(gè)右對(duì)齊的登錄框案例,它很好地突出了重點(diǎn)。左側(cè)的空間被用來(lái)打造積極的品牌形象 —— 總體來(lái)說(shuō)是成功的登錄體驗(yàn)。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Pinterest 做了 一個(gè)簡(jiǎn)單居中的疊加表單,有碩大的輸入框 —— 不斷吸引用戶!還有一個(gè)亮紅色的登錄主按鈕,以及一些額外的社交登錄選項(xiàng)。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

盡管 Airbnb(愛(ài)彼迎)在很多方面都做得很好,但它的登錄頁(yè)讓人感到操作繁多,這也許是因?yàn)榛谑謾C(jī)號(hào)碼登錄,也許是因?yàn)榇罅康拇我卿涍x項(xiàng),導(dǎo)致相當(dāng)多的認(rèn)知負(fù)荷!

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

LinkedIn(領(lǐng)英)很好地保持登錄框的簡(jiǎn)介、聚焦和居中,有一個(gè)醒目的主登錄按鈕。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

我對(duì) Dropbox 的登錄頁(yè)面持猶豫態(tài)度——插圖很好看,但它的顏色與界面按鈕的顏色相似。這是附加元素分散注意力的案例。就我個(gè)人而言,我喜歡在界面中大膽使用插圖,但評(píng)估插圖的使用環(huán)境也很重要。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

Amazon(亞馬遜)的登陸頁(yè)視覺(jué)設(shè)計(jì)上有些老舊,但對(duì)于管理用戶注意力是一個(gè)很好的案例,巨大的黃色“繼續(xù)”按鈕以及頁(yè)面上沒(méi)有任何干擾,使登錄任務(wù)看起來(lái)簡(jiǎn)單快速。

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

在登錄頁(yè)面上放置廣告可能不是一個(gè)好主意,但同時(shí) Yahoo(雅虎)有一個(gè)與眾不同的標(biāo)識(shí)在登錄框中,其中設(shè)計(jì)了一些巧妙的功能,幫助用戶減少輸入。(參考下圖)

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

掌握這 7 條準(zhǔn)則,提升用戶登錄成功率!

我想把 Figma 納入優(yōu)秀的登錄案例中,該頁(yè)居中于浮層,Google 登錄被突出展示(也許是 Figma 的首選和推廣的登錄形式?),它非常簡(jiǎn)潔,幾乎是線框式的。用戶體驗(yàn)非常好。

感謝我的產(chǎn)品合作伙伴 Apurva 和我一起學(xué)習(xí)。采取微小的步驟進(jìn)行用戶識(shí)別,并且使用戶易于接受。這會(huì)使你的用戶登錄成功率越來(lái)越高!同時(shí)這也會(huì)為平臺(tái)帶來(lái)更多的活躍用戶。:)希望你能從這篇文章中得到啟發(fā),并應(yīng)用于你自己的產(chǎn)品和設(shè)計(jì)工作中。

文章來(lái)源:優(yōu)設(shè)  作者:TCC翻譯情報(bào)局

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


部署智能合約到conflux公鏈

前端達(dá)人

一、準(zhǔn)備合約

本節(jié)課程教大家如何講智能合約部署到conflux公鏈上,首先大家可以看到下面的這個(gè)智能合約是不是很簡(jiǎn)單。我們將會(huì)以這個(gè)合約演示部署到conflux公鏈的過(guò)程。

pragma solidity ^0.5.0;

contract Counter {
    uint public count=0;
    event SelfEvent(address indexed sender, uint current);

    constructor() public {
    } function inc(uint num) public returns (uint){ return count += num;
    } function self() public {
        emit SelfEvent(msg.sender, count);
    }
} 復(fù)制代碼

二、conflux的sdk安裝

我們使用js-conflux-sdk作為本教程的web教程,交互首先我們需要進(jìn)行安裝nodejs作為我們的運(yùn)行環(huán)境。飛機(jī)票一張收下吧,我們安裝好nodejs后,就可以來(lái)玩我們的sdk了。廢話不多說(shuō),直接開(kāi)始擼。

我們使用WIN + R鍵打開(kāi)命令行,然后創(chuàng)建一個(gè)文件夾(溫馨提示切換到非系統(tǒng)盤(pán)玩切換方式“D:”就切換到D盤(pán)了)使用“mkdir my-project && cd my-project” 創(chuàng)建好項(xiàng)目后自動(dòng)進(jìn)入文件夾,然后我們運(yùn)行“npm init” 進(jìn)行初始化node項(xiàng)目,這一步會(huì)讓你確認(rèn)一些東西,如果你是小白一路回車(chē)(Enter鍵)就好。如果你是前端大神,我也沒(méi)啥好教的我也不太懂。為了穩(wěn)定我們使用固定版本號(hào)方式安裝依賴,我們運(yùn)行 “npm install js-conflux-sdk@0.9.2” 命令進(jìn)行安裝js-conflux-sdk的0.9.2版本依賴(可以使用“npm uninstall package-name” 命令刪除對(duì)應(yīng)依賴)。前置準(zhǔn)備到這里基本已經(jīng)完成。

三、編寫(xiě)調(diào)用合約js代碼

下面請(qǐng)看我的目錄結(jié)構(gòu)跟隨我一起來(lái)學(xué)習(xí),下面的目錄結(jié)構(gòu)請(qǐng)不要直接看到了就創(chuàng)建,因?yàn)槟悴恢蓝际鞘裁匆馑迹赐嫖业慕忉屧诨仡^創(chuàng)建。

 

image

 

小伙伴應(yīng)該已經(jīng)發(fā)現(xiàn)了 node_modules、package-lock.json、package.json 這些文件是我們?cè)谶M(jìn)行安裝 sdk依賴時(shí)自動(dòng)生成的。其他文件目前都沒(méi)有,我們來(lái)按順序生成他們。

先創(chuàng)建sol這個(gè)文件夾,然后創(chuàng)建這三個(gè)文件。test.sol就是上面我們的合約代碼直接拷入文件中。abi.json和code.json兩個(gè)文件是通過(guò)這個(gè)工具 remix 在線生成的。我來(lái)說(shuō)下生成過(guò)程。 首先我們將里面的文件全部刪除,然后點(diǎn)擊這里找到我們的項(xiàng)目目錄下的test.sol 文件

 

 

 

 

我們應(yīng)該看到下方我框出來(lái)的兩個(gè)按鈕了吧,那兩個(gè)按鈕就是abi.json和code.json文件的來(lái)源。abi.json我們可以直接復(fù)制過(guò)去,code.json文件我們要改點(diǎn)東西。

首先我們看到的code文件應(yīng)該是這樣的

{ "linkReferences": {}, "object": "608060405260...c63430005110032", "opcodes": "PUSH1 0x80 PUSH1 ... 1100 ORIGIN ", "sourceMap": "27:337:0 ... 37;;;;;;" } 復(fù)制代碼

代碼有省略,太長(zhǎng)不好看,我們看到object這個(gè)key值了吧,我們把它的值考出來(lái)然后在頭部加0x 就好了放在code.json文件中。code.js文件中只存放object的內(nèi)容前面加0x,也就是下面的代碼,其他信息都不要,千萬(wàn)記住了。這點(diǎn)很重要?。。?!

"0x608060405260...c63430005110032" 復(fù)制代碼

就是這樣的。然后我們?cè)趯?xiě)另外兩個(gè)call和deploy兩個(gè)文件

先寫(xiě)deploy文件

 // 私鑰地址
const PRIVATE_KEY = '0x20f9169d40801955faada641cdb029f8e42c581c0c991a62753c736a0a168e5e';
// 合約地址
const CONTRACT = '';
const { Conflux } = require('js-conflux-sdk');

async function main() {
  const cfx = new Conflux({
    url: 'http://mainnet-jsonrpc.conflux-chain.org:12537',
    defaultGasPrice: 100,
    defaultGas: 1000000,
  });
  const account = cfx.Account(PRIVATE_KEY); // create account instance
  console.log(account.address); 

  // create contract instance
  const contract = cfx.Contract({
    abi: require('./sol/RC20.abi.json'),
    bytecode: require('./sol/RC20.code.json'),
  });

  const receipt = await contract.constructor()
    .sendTransaction({ from: account })
    .confirmed();
  console.log(receipt.contractCreated); 
}
main().catch(e => console.error(e)); 復(fù)制代碼

打開(kāi)項(xiàng)目cmd窗口在上面的目錄下 運(yùn)行命令 “node deploy.js”就將合約部署上去了

receipt.contractCreated 這個(gè)會(huì)打印出合約地址。






作者:悠悠_15832013094

鏈接:https://juejin.im/post/5ef563f75188252e99702335

來(lái)源:掘金

藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼藍(lán)小助,報(bào)下信息,藍(lán)小助會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

轉(zhuǎn)自:csdn
免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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

Conflux 開(kāi)發(fā)教程 | 使用 IDE 在 Conflux 開(kāi)發(fā) DApp 的實(shí)戰(zhàn)操作指南

前端達(dá)人

Conflux DApp 開(kāi)發(fā)教程

對(duì)本教程有任何疑問(wèn)或建議可以在 GitHub 給我們留言。

簡(jiǎn)介

Conflux DApp 開(kāi)發(fā)教程將使用 Conflux Studio 在 Oceanus 網(wǎng)絡(luò)下開(kāi)發(fā)一個(gè)簡(jiǎn)單的代幣應(yīng)用 Coin。
在這里插入圖片描述

通過(guò)這個(gè)開(kāi)發(fā)教程,你將會(huì)學(xué)習(xí)到如何進(jìn)行 Conflux 智能合約的編寫(xiě)、調(diào)用,配置智能合約的代付以及如何使用 Web 前端項(xiàng)目與智能合約進(jìn)行交互,從而實(shí)現(xiàn)一個(gè)包含前端和智能合約的完整的 DApp。

在閱讀教程中遇到任何問(wèn)題,歡迎在 Issues 中向我們反饋。

準(zhǔn)備工作

安裝 IDE

請(qǐng)?jiān)?GitHub 下載頁(yè)面下載 Conflux Studio。目前 Conflux Studio 支持 macOS 和 Linux 系統(tǒng),請(qǐng)根據(jù)系統(tǒng)下載對(duì)應(yīng)的版本。

正確安裝 Conflux Studio 并初次啟動(dòng)后,Conflux Studio 將顯示歡迎頁(yè)面,根據(jù)提示完成 Docker, Conflux Node 以及 Conflux Truffle 的下載、安裝及啟動(dòng)。
在這里插入圖片描述

創(chuàng)建錢(qián)包

完成所有的安裝步驟后,首先需要?jiǎng)?chuàng)建鑰匙對(duì)來(lái)完成后續(xù)的合約部署以及調(diào)用。

在 Conflux Studio 的任意界面,點(diǎn)擊應(yīng)用左下?的鑰匙圖標(biāo),打開(kāi)密鑰管理器。點(diǎn)擊 Create 按鈕打開(kāi)新鑰匙對(duì)彈窗,輸入鑰匙對(duì)的名字并點(diǎn)擊 Save 按鈕。完成后將在密鑰管理器中看到剛剛生成的鑰匙對(duì)的地址。鑰匙對(duì)由私鑰和公鑰組成,公鑰在智能合約中也常被稱作地址。

導(dǎo)出私鑰可以通過(guò)點(diǎn)擊每個(gè)地址后面的眼睛按鈕打開(kāi)查看私鑰彈窗,彈窗顯示地址以及私鑰。后續(xù)教程中會(huì)需要通過(guò)管理器導(dǎo)出私鑰。
在這里插入圖片描述

為了順利完成教程,首先需要?jiǎng)?chuàng)建三個(gè)鑰匙對(duì):

  • minter_key 用于 Coin 合約部署時(shí)的簽名,是這個(gè)教程中最常使用的鑰匙對(duì)
  • receiver_key 用于 Coin 合約接收轉(zhuǎn)賬,將在后文中介紹轉(zhuǎn)賬時(shí)用到
  • sponsor_key 用于 Coin 合約代付功能,將在后文中介紹代付功能時(shí)用到

連接 Conflux 網(wǎng)絡(luò)

教程將在 Oceanus 網(wǎng)絡(luò)進(jìn)行合約的部署以及合約的調(diào)用。點(diǎn)擊頂部 Network 標(biāo)簽的倒三角打開(kāi)下拉菜單,點(diǎn)擊選擇 Oceanus 網(wǎng)絡(luò)進(jìn)行切換。

切換完成后,可以在主頁(yè)面中看到當(dāng)前網(wǎng)絡(luò)為 oceanus。頁(yè)面左邊包括了當(dāng)前網(wǎng)絡(luò)的節(jié)點(diǎn) URLChain ID,TPS 信息,頁(yè)面右邊包含了當(dāng)前網(wǎng)絡(luò)區(qū)塊的信息。
在這里插入圖片描述

申請(qǐng)測(cè)試 CFX

點(diǎn)擊頂部 Explorer 標(biāo)簽打開(kāi)區(qū)塊瀏覽器,并在地址欄粘貼鑰匙對(duì)地址,可以在左邊看到當(dāng)前地址的 CFX 余額信息。
在這里插入圖片描述

在區(qū)塊鏈的世界中,大家通常將申請(qǐng)測(cè)試 Token 的方式稱為 faucet,目前在 Oceanus 網(wǎng)絡(luò)下每次 faucet 申請(qǐng)到的 Token 為 100 CFX。

獲取 CFX 的方式有兩種方式:

  • 輸入地址后點(diǎn)擊地址欄右邊的水龍頭按鈕,Conflux Studio 將為地址自動(dòng)申請(qǐng) CFX
  • 你也可以直接在瀏覽器中輸入 https://wallet.confluxscan.io/faucet/dev/ask?address={address} 來(lái)申請(qǐng) CFX
    在這里插入圖片描述

使用上述方法在 Conflux Studio 中為 minter_key 和 sponsor_key 申請(qǐng) CFX Token。完成申請(qǐng)后,這兩個(gè)賬戶上的余額將會(huì)從 0 CFX 更新為 100 CFX。

目前余額信息為:

  • minter_key 余額 100 CFX
  • receiver_key 余額 0 CFX
  • sponsor_key 余額 100 CFX

智能合約

創(chuàng)建項(xiàng)目

點(diǎn)擊頂部左邊的 Project 標(biāo)簽切換至項(xiàng)目列表頁(yè)面,點(diǎn)擊頁(yè)面中的 New 按鈕打開(kāi)項(xiàng)目創(chuàng)建窗口,輸入項(xiàng)目的名稱并選擇 coin 模版,點(diǎn)擊 Create Project 完成項(xiàng)目的創(chuàng)建。
在這里插入圖片描述

合約代碼

Coin 合約是一個(gè)簡(jiǎn)單的代幣合約,其中:

  • 通過(guò) mint 方法可以增發(fā)代幣數(shù)量
  • 通過(guò) send 方法可以將一定數(shù)量的代幣轉(zhuǎn)賬給別的用戶,同時(shí)會(huì)在事件中記錄下這筆轉(zhuǎn)賬的信息
  • 通過(guò) balanceOf 方法可以查詢到指定賬戶地址的代幣余額
  • 通過(guò) add_privilege 方法可以為合約添加代付白名單
  • 通過(guò) remove_privilege 方法可以為合約移除代付白名單
    在這里插入圖片描述

Conflux 智能合約使用 Solidity 語(yǔ)言進(jìn)行開(kāi)發(fā),打開(kāi)目錄下的 contracts/Coin.sol 文件,這個(gè)是本項(xiàng)目的核心代碼:

// 指定了 Solidity 的版本,通過(guò) Pragmas(https://solidity.readthedocs.io/en/latest/layout-of-source-files.html#pragmas) 告訴編譯器本代碼可以兼容的版本為 0.5.0 到 0.7.0
pragma solidity >=0.5.0 <0.7.0;

// 導(dǎo)入 SponsorWhitelistControl 合約
import "./SponsorWhitelistControl.sol";

// 定義 Coin 的合約
contract Coin {
    // 定義了兩個(gè) State Variables(https://solidity.readthedocs.io/en/latest/structure-of-a-contract.html#state-variables)
    address public minter;
    mapping (address => uint) private balances;

    // 使用 SponsorWhitelistControl 合約連接系統(tǒng)合約
    SponsorWhitelistControl constant private SPONSOR = SponsorWhitelistControl(address(0x0888000000000000000000000000000000000001));

    // 定義了 `Sent` 的事件,定義了 from / to / amount 列
    event Sent(address from, address to, uint amount);

    // Coin 合約的 constructor ,在 constructor 中指定了 minter 的地址
    constructor() public {
        // msg.sender 為部署合約時(shí)簽名的賬戶地址,將這個(gè)地址賦值給 minter
        minter = msg.sender;
    }

    // 定義 mint 方法,通過(guò)此方法來(lái)增發(fā)代幣
    function mint(address receiver, uint amount) public {
        require(msg.sender == minter);
        require(amount < 1e60);
        balances[receiver] += amount;
    }

    // 定義 send 方法,通過(guò)此方法可以給別的賬戶轉(zhuǎn)賬代幣
    function send(address receiver, uint amount) public {
        require(amount <= balances[msg.sender], "Insufficient balance.");
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        // 通過(guò) emit 觸發(fā) Sent 事件,記錄這筆轉(zhuǎn)賬的信息
        emit Sent(msg.sender, receiver, amount);
    }

    // 定義 balanceOf 方法,這是個(gè) view 類(lèi)型的方法,用于查詢賬戶余額
    function balanceOf(address tokenOwner) public view returns(uint balance){
      return balances[tokenOwner];
    }

    // 定義了 add_privilege 方法,調(diào)用系統(tǒng)合約 add_privilege 方法添加地址到代付白名單
    function add_privilege(address account) public payable {
        address[] memory a = new address[](1);
        a[0] = account;
        SPONSOR.add_privilege(a);
    }

    // 定義了 remove_privilege 方法,調(diào)用系統(tǒng)合約 remove_privilege 從合約代付白名單中移除地址
    function remove_privilege(address account) public payable {
        address[] memory a = new address[](1);
        a[0] = account;
        SPONSOR.remove_privilege(a);
    }
} 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59

編譯及部署合約

點(diǎn)擊工具欄的 Build 按鈕進(jìn)行合約的編譯,編譯的結(jié)果將會(huì)保存在 build/Coin.json 文件中。
在這里插入圖片描述
在部署合約前,首先需要確認(rèn)在 Explorer 中選擇合約部署所使用的地址,Conflux Studio 會(huì)使用這個(gè)地址將部署合約這筆交易進(jìn)行簽名(選擇的方法為在 Explorer 的地址欄中輸入地址)。在合約代碼的 constructor 中,minter 被賦值為 msg.sender,這個(gè) msg.sender 就是 Explorer 所選擇的地址。

在此我們選擇 minter_key 作為部署合約的簽名者。
在這里插入圖片描述
點(diǎn)擊工具欄的部署按鈕進(jìn)行部署,部署完成后,部署結(jié)果會(huì)在 deploys 的 JSON 文件中,在這個(gè)文件中可以在 contractCreated 中找到當(dāng)前合約部署的地址,后文中使用 contract_addr 來(lái)代表這個(gè)合約地址。
在這里插入圖片描述

調(diào)用合約

點(diǎn)擊頂部的 Contract 標(biāo)簽切換至合約頁(yè)面,在地址欄輸入 contract_addr 地址并加載合約。
在這里插入圖片描述

合約頁(yè)面由三個(gè)部分組成:

  • 左邊為合約調(diào)用區(qū)域
  • 中間為合約數(shù)據(jù)查詢區(qū)域
  • 右邊為事件查詢區(qū)域

合約調(diào)用及查詢

增發(fā)代幣

點(diǎn)擊合約調(diào)用的下拉菜單中選擇 mint 方法,在下方的參數(shù)區(qū)域分別填入以下信息:

  • receiver 接收代幣的地址。填入 minter_key 地址
  • amount 發(fā)行的代幣總數(shù)。填入整數(shù) 1000
  • Value 選填項(xiàng),具體可查看 Value 詳解。填 0 或者不填
  • Signer 這筆交易的簽名地址,如果沒(méi)有開(kāi)通代付功能,交易手續(xù)費(fèi)將在這個(gè)賬戶地址中扣除,在合約代碼中通過(guò) msg.sender 獲取到這個(gè)地址。填入 minter_key 地址

填寫(xiě)完成后點(diǎn)擊執(zhí)行按鈕,Conflux Studio 將自動(dòng)構(gòu)造交易并推送到網(wǎng)絡(luò)中。成功執(zhí)行后可以在下方 Result 中看到這筆成功的交易。
在這里插入圖片描述

查詢代幣余額

點(diǎn)擊查詢區(qū)域的下拉菜單并且選擇 balanceOf 方法,這是在代碼中定義的查詢方法。在下方的 tokenOwner 填入 minter_key 地址并點(diǎn)擊執(zhí)行,就可以在下方的 Result 中看到 minter_key 賬戶的 Coin 代幣的余額信息為 1000。使用同樣方法可以查詢到 receiver_key 賬戶的代幣余額為 0。
在這里插入圖片描述

轉(zhuǎn)賬代幣

在合約調(diào)用區(qū)域選擇 send 方法,在 Parameters 中分別填入:

  • receiver 收款人地址。填入 receiver_key 地址
  • amount 轉(zhuǎn)賬的代幣數(shù)量。填入整數(shù) 200
  • Signer 這筆交易的簽名地址,代幣轉(zhuǎn)出的數(shù)量將會(huì)在這個(gè)賬戶中扣除。填入 minter_key 地址,

點(diǎn)擊執(zhí)行完成轉(zhuǎn)賬,再次查詢代幣余額可以看到 minter_key 賬戶只剩下 800 代幣,而 receiver_key 賬戶則從 0 變成了 200 代幣。在這里插入圖片描述

Value 參數(shù)

Conflux 智能合約的每個(gè)調(diào)用的方法都可以帶上 Value 參數(shù),這是一個(gè)可選的參數(shù)。如果帶上了這個(gè)值,智能合約出了在執(zhí)行這個(gè)方法的邏輯外,還會(huì)額外轉(zhuǎn) Value 中指定數(shù)量的 CFX token 到 receiver 賬戶,轉(zhuǎn)賬金額為 Value 中所填的值。有些智能合約的方法需要這個(gè)參數(shù)才可以完成調(diào)用,但是在 Coin 合約不需要這個(gè)參數(shù)。

后文中的代付功能將會(huì)使用到 Value 參數(shù)。

查詢事件

在事件區(qū)域選擇 Sent 并點(diǎn)擊執(zhí)行,下方的 Event Logs 可以看到轉(zhuǎn)賬的記錄。Sent 事件的列都是由代碼中的 Sent 事件的參數(shù)來(lái)定義的(其中 epoch 為事件發(fā)生的時(shí)間,這個(gè)為系統(tǒng)默認(rèn)列)。在代碼中定義了 Sent 方法的參數(shù)為 from, to 和 amount,分別對(duì)應(yīng)了這筆轉(zhuǎn)賬的發(fā)起者地址,接受者地址以及轉(zhuǎn)賬的數(shù)量。
在這里插入圖片描述

代付功能

Conflux Studio 支持 Conflux 系統(tǒng)合約提供的代付功能。

通過(guò)系統(tǒng)合約可以為別的合約設(shè)置代付功能,系統(tǒng)合約提供給了四個(gè)方法:

  • add_privilege 添加合約代付白名單,在代付白名單中的地址調(diào)用該合約的方法時(shí)不需要付手續(xù)費(fèi),費(fèi)用由代付賬戶支付。其中添加特殊地址 0x0000000000000000000000000000000000000000 代表為所有調(diào)用該合約的地址代付費(fèi)用
  • remove_privilege 移除合約代付白名單
  • set_sponsor_for_collateral 設(shè)置合約儲(chǔ)存費(fèi) (collateral for storage) 的代付賬戶及代付金額
  • set_sponsor_for_gas 設(shè)置合約手續(xù)費(fèi) (gas fee) 的代付賬戶、代付金額及每筆交易代付金額上限

啟用一個(gè)合約的代付需要設(shè)置代付的賬戶、代付金額的及代付白名單。教程將會(huì)使用 Conflux Studio 通過(guò)系統(tǒng)合約設(shè)置代付賬戶及代付金額,通過(guò) Coin 合約添加代付白名單。設(shè)置完成后,minter_key 賬戶調(diào)用 Coin 合約的方法時(shí)將不會(huì)被扣除手續(xù)費(fèi),手續(xù)費(fèi)由 sponsor_key 賬戶代付。

設(shè)置代付賬戶及代付金額

在 Conflux Studio 中訪問(wèn)系統(tǒng)合約地址 0x0888000000000000000000000000000000000001,在合約調(diào)用區(qū)域能看到前文中提及的四個(gè)設(shè)置代付的方法。
在這里插入圖片描述

選擇 set_sponsor_for_collateral 方法,該方法有三個(gè)參數(shù):

  • contract_addr 設(shè)置代付的合約地址。填入 contract_addr
  • Value 設(shè)置代付金額。填入整數(shù) 40
  • Signer 代付賬戶地址。填入 sponsor_key 地址
    在這里插入圖片描述
    填好以上參數(shù)并執(zhí)行運(yùn)行,系統(tǒng)合約將為 Coin 合約設(shè)置好儲(chǔ)存費(fèi)代付賬戶,此時(shí) sponsor_key 賬戶將會(huì)被扣除 40 CFX。

選擇 set_sponsor_for_gas 方法,該方法有四個(gè)參數(shù):

  • contract_addr 設(shè)置代付的合約地址。填入 contract_addr
  • upper_bound 設(shè)置每筆交易代付的上限。填入 1000000000000
  • Value 設(shè)置代付金額。填入整數(shù) 40
  • Signer 代付賬戶地址。填入 sponsor_key 地址
    在這里插入圖片描述
    填好以上參數(shù)并再次執(zhí)行運(yùn)行,系統(tǒng)合約將為 Coin 合約設(shè)置好手續(xù)費(fèi)代付賬戶,此時(shí) sponsor_key 賬戶將會(huì)再次被扣除 40 CFX。

完成這兩個(gè)方法的調(diào)用后 Coin 合約代付賬戶便設(shè)置好了,sponsor_key 賬戶將為 Coin 合約的手續(xù)費(fèi)和儲(chǔ)存費(fèi)各提供為 40 CFX Token 的代付服務(wù)。由于目前代付白名單中并沒(méi)有賬戶地址,因此還需要添加白名單地址才能完成代付設(shè)置。

添加代付白名單

在 Coin 合約中集成了設(shè)置代付白名單的方法,通過(guò)調(diào)用此方法可以添加或刪除代付白名單。

在 Conflux Studio 中訪問(wèn) contract_addr 合約,選擇 add_privilege 方法:

  • account 添加白名單的地址。填入 minter_key 地址
  • Value 不填
  • Signer 這筆交易的簽名地址。填入 minter_key 地址

運(yùn)行后就成功設(shè)置了代付白名單了,至此 Coin 合約的代付功能設(shè)置好了。

代付測(cè)試

在進(jìn)行代付測(cè)試前,先查詢并記錄下 minter_key 賬戶的 CFX 余額。例如本教程中,minter_key 的初始余額為 97.6210937497093952 CFX。

回到 Coin 合約調(diào)用頁(yè)面,再次調(diào)用 mint 方法并使用 minter_key 地址增發(fā)代幣 1000,完成代幣增發(fā)后再次查詢 minter_key 的余額,仍然為 97.6210937497093952 CFX。

可以看到增發(fā)代幣的這筆交易,原本應(yīng)該由 minter_key 賬戶支付的手續(xù)費(fèi),變成了由 sponsor_key 賬戶支付。

前端項(xiàng)目

前端項(xiàng)目源碼可以前往 Conflux 前端

預(yù)備

下載項(xiàng)目并安裝依賴

  • 下載前端項(xiàng)目:git clone https://github.com/ObsidianLabs/conflux-frontend-react
  • 使用 npm install 或者 yarn 進(jìn)行項(xiàng)目依賴安裝

Conflux Portal 的安裝及配置

Conflux Portal 是由 Conflux 提供的瀏覽器插件,目前提供了 Chrome 及 Firefox 的支持,用戶可以使用 Conflux Portal 進(jìn)行私鑰的管理以及交易簽名。

前往 Conflux Portal GitHub 下載安裝。項(xiàng)目的源代碼在 GitHub 中可以找到。

在這里需要將 Conflux Studio 中生成的地址導(dǎo)入到 Conflux Portal 中。完成插件安裝后,在 Conflux Portal 的頁(yè)面中選擇 Import,將 Conflux Studio 中的 minter_key 的私鑰(在創(chuàng)建錢(qián)包章節(jié)中介紹了如何將私鑰導(dǎo)出)粘貼到輸入框中,點(diǎn)擊 Import 按鈕完成私鑰導(dǎo)入。
在這里插入圖片描述

運(yùn)行前端項(xiàng)目

在運(yùn)行項(xiàng)目之前,需要修改一些默認(rèn)的環(huán)境變量。

前面的教程中部署合約后會(huì)生成一個(gè) contractCreated,這個(gè)值便是部署在網(wǎng)絡(luò)中智能合約的地址。打開(kāi)項(xiàng)目根目錄并找到 .env 文件,這個(gè)文件提供了項(xiàng)目的環(huán)境變量,將 REACT_APP_CONFLUX_COIN_ADDRESS 的值修改為 contract_addr。

使用 yarn start 啟動(dòng)前端項(xiàng)目,開(kāi)發(fā)服務(wù)器運(yùn)行起來(lái)后會(huì)在瀏覽器中打開(kāi)前端頁(yè)面(如果沒(méi)有打開(kāi),請(qǐng)?jiān)跒g覽器中訪問(wèn) http://localhost:3000)。

項(xiàng)目運(yùn)行起來(lái)后,頁(yè)面將顯示四個(gè)卡片信息,分別為

  • 左上角 Conflux 網(wǎng)絡(luò)信息模塊
  • 右上角 Conflux Portal 模塊
  • 左下角 Coin 合約模塊
  • 右下角 SponsorWhitelistControl 合約模塊
    在這里插入圖片描述

連接 Conflux Portal

點(diǎn)擊右上角組件中的 Connect to Conflux Portal 按鈕,Conflux Portal 頁(yè)面將被打開(kāi),輸入密碼和選擇賬戶后完成連接。連接成功后,將會(huì)在按鈕下看到當(dāng)前連接的賬戶地址以及賬戶中的 CFX 余額。
在這里插入圖片描述

運(yùn)行 Coin 合約代幣增發(fā)和代幣轉(zhuǎn)賬操作

左下角的組件為 Coin 合約組件,可以通過(guò)這個(gè)組件調(diào)用代幣增發(fā)和代幣轉(zhuǎn)賬功能。

  • 代幣增發(fā):選擇 mint 方法并在 receiver 中填入增發(fā)地址 minter_key 地址和在 amount 中填入增發(fā)代幣的數(shù)量 100,點(diǎn)擊 Push Transaction,在彈出的 ConfluxPortal Notification 窗口中點(diǎn)擊 Confirm 按鈕來(lái)確認(rèn)交易。

  • 代幣轉(zhuǎn)賬:選擇 send 方法并在 receiver 中填入收款人地址 receiver_key 地址和在 amount 中轉(zhuǎn)賬代幣的數(shù)量 20,點(diǎn)擊 Push Transaction,在彈出的 ConfluxPortal Notification 窗口中點(diǎn)擊 Confirm 按鈕來(lái)確認(rèn)交易。
    在這里插入圖片描述

查看 Coin 合約中的余額

選擇 balanceOf 方法并在 tokenOwner 輸入框中填入查詢的地址,點(diǎn)擊 Query Data 按鈕可以查詢到賬戶的余額。
在這里插入圖片描述

查看 Sent 事件

選擇 Sent 事件并點(diǎn)擊 Query Data 可以查詢到轉(zhuǎn)賬操作所觸發(fā)的轉(zhuǎn)賬事件的記錄。
在這里插入圖片描述

前端項(xiàng)目解析

項(xiàng)目使用 React 進(jìn)行開(kāi)發(fā)。主要由三大部分組成:視圖組件、js-conflux-sdk 以及 Conflux Portal。

項(xiàng)目根目錄下的 .env 環(huán)境變量,在這里定義了兩個(gè)環(huán)境變量,分別為

  • REACT_APP_CONFLUX_NODE_RPC:Conflux 的網(wǎng)絡(luò)節(jié)點(diǎn)地址,目前默認(rèn)為 Oceanus 網(wǎng)絡(luò)的地址
  • REACT_APP_CONFLUX_COIN_ADDRESS:已部署的 Coin 智能合約地址

視圖組件

視圖組件在項(xiàng)目的 src/components 中,其中 App.js 為頁(yè)面的主入口,負(fù)責(zé)頁(yè)面的排列及合約信息的讀取。
在這里插入圖片描述

ConfluxNetwork.js

負(fù)責(zé)渲染 Conflux 網(wǎng)絡(luò)信息,Node URL 的值為 .env 環(huán)境變量文件下的 REACT_APP_CONFLUX_NODE_RPC 設(shè)置的值(默認(rèn)為 Oceanus 網(wǎng)絡(luò))。

ConfluxPortal.js

負(fù)責(zé)渲染 Conflux Portal 的連接信息,并提供了連接 Conflux Portal 的交互按鈕。

  • connectConfluxPortal 調(diào)用 Conflux Portal 的 enable 方法啟用 conflux (conflux portal 實(shí)例由瀏覽器插件注入到 windows.portal 中),完成 enable 后調(diào)用 getAccount 方法獲取到 Portal 中的賬戶。
  • refreshBalance 調(diào)用 Conflux SDK 的 getBalance 方法來(lái)更新賬戶余額信息
  • renderPortalButton 根據(jù)當(dāng)前不同的狀態(tài),渲染連接 Portal 的按鈕
ConfluxContract.js

負(fù)責(zé)渲染 Conflux 合約信息,本項(xiàng)目中提供了 Coin 和 SponsorWhitelistControl 兩個(gè)合約。

ConfluxContract.js 由三個(gè)組件組成,分別為:

  • ConfluxContract 負(fù)責(zé)根據(jù)傳入的合約 abi 來(lái)渲染合約的信息,包括合約地址、合約方法和事件,合約提交的交互邏輯及顯示執(zhí)行后的結(jié)果
  • ContractMethods 負(fù)責(zé)渲染合約 abi 中的方法和事件的表單及相對(duì)應(yīng)的按鈕
  • ConfluxForm 負(fù)責(zé)根據(jù)方法或事件的 abi 來(lái)渲染輸入表單

lib

lib 在項(xiàng)目的 src/lib 中,這里的文件主要是為視圖提供包括連接網(wǎng)絡(luò)、構(gòu)造交易、獲取賬戶、讀取合約等服務(wù)。
在這里插入圖片描述

conflux.js

conflux.js 是 js-conflux-sdk 的封裝。js-conflux-sdk 是由 Conflux 提供的 JavaScript SDK,本前端項(xiàng)目使用 SDK 來(lái)連接 Conflux 網(wǎng)絡(luò),和合約進(jìn)行交互以及構(gòu)造合約中的實(shí)例。

conflux-portal.js

conflux-portal.js 是 Conflux Portal 的封裝,本前端項(xiàng)目通過(guò)調(diào)用瀏覽器插件來(lái)完成交易的簽名。調(diào)用 Conflux Portal 提供的 enable 方法可以啟動(dòng)項(xiàng)目和 Conflux Portal 的連接(需要提前檢查瀏覽器是否正確安裝插件,在 constructor 中通過(guò)檢查 window.conflux 是否為空來(lái)判斷)。conflux-portal.js 提供了獲取賬戶 getAccount 和發(fā)送交易 sendTransaction 兩個(gè)主要的方法。

abi

lib/abi 文件夾下提供了兩個(gè) json 文件,分別為 Coin.json 和 SponsorWhitelistControl.json,這兩個(gè)文件是構(gòu)造合約所需要使用的 abi 文件。

總結(jié)

在本開(kāi)發(fā)教程中,我們學(xué)習(xí)了如何使用 Conflux Studio 來(lái)完成一個(gè)完整的 Coin DApp 開(kāi)發(fā),其中包括了:

  • 使用鑰匙對(duì)管理器創(chuàng)建賬戶及導(dǎo)出賬戶私鑰
  • 切換 Oceanus 網(wǎng)絡(luò),查看網(wǎng)絡(luò)信息
  • 賬戶申請(qǐng) CFX Token
  • 創(chuàng)建、編譯并部署項(xiàng)目
  • 解析 Coin 合約代碼,學(xué)習(xí)如何編寫(xiě)合約的讀寫(xiě)方法及事件
  • 使用合約瀏覽器調(diào)用 Coin 合約的代幣增發(fā)、轉(zhuǎn)賬、查詢余額及查詢事件
  • 設(shè)置并使用智能合約的代付功能
  • 將私鑰導(dǎo)入 Conflux Portal 并連接前端項(xiàng)目
  • 在前端項(xiàng)目中調(diào)用 Coin 合約的代幣增發(fā)、轉(zhuǎn)賬、查詢余額及查詢事件
  • 解析前端項(xiàng)目代碼,學(xué)習(xí)如何通過(guò) Conflux Portal 和 Conflux JavaScript SDK 連接網(wǎng)絡(luò)并實(shí)現(xiàn)交易

關(guān)于 Conflux Bounty

Conflux 基金會(huì)為了鼓勵(lì)用戶參與生態(tài)建設(shè),提供了 Conflux Bounty 賞金平臺(tái)。通過(guò)完成 Bounty 賞金平臺(tái)發(fā)布的各項(xiàng)任務(wù),參與者可以獲得 FC (Fans Token) 作為獎(jiǎng)勵(lì)。

FC 的價(jià)值

FC,全稱 Fans Coin,是由 Conflux 基金會(huì)與社區(qū)成員共同研發(fā)的生態(tài)代幣,用于記錄和感謝對(duì) Conflux 生態(tài)建設(shè)做出貢獻(xiàn)的社區(qū)成員。FC 目前在 Oceanus 上運(yùn)行,Conflux 基金會(huì)承諾,在主網(wǎng)上線后,鎖定和未鎖定的 FC 都可以與主網(wǎng) CFX 進(jìn)行 1:1 承兌,以此保障所有社區(qū)成員的勞動(dòng)成果都可以獲得獎(jiǎng)勵(lì)。
在這里插入圖片描述

FC 賞金分配方案會(huì)展示在賞金任務(wù)詳情頁(yè)中,包括最高獎(jiǎng)金數(shù)量、獎(jiǎng)金分配人數(shù)、獎(jiǎng)金數(shù)量分布、排行名次確定方式等信息。賬號(hào)余額中的賞金獎(jiǎng)勵(lì)可以隨時(shí)申請(qǐng)?zhí)岈F(xiàn)至 Conflux 錢(qián)包。Conflux 團(tuán)隊(duì)會(huì)對(duì)所有的提現(xiàn)申請(qǐng)進(jìn)行審核。

對(duì)于已經(jīng)通過(guò)的提現(xiàn)申請(qǐng),Conflux 團(tuán)隊(duì)會(huì)在每周二中午 12 點(diǎn)(如遇節(jié)假日,往后順延至下一個(gè)工作日)進(jìn)行提幣操作。完成提幣操作后,您的 Conflux 錢(qián)包將會(huì)收到您提現(xiàn)的賞金獎(jiǎng)勵(lì)。

Bounty 的價(jià)值

Conflux Bounty (https://bounty.conflux-chain.org) 的宗旨是為每一個(gè)通證找到價(jià)值。Bounty 分為幾個(gè)板塊:技術(shù)、品牌、社群、資源、其他等。

  • 技術(shù)板塊:分為產(chǎn)品、SDK、教程、開(kāi)發(fā)、測(cè)試等;主要是獎(jiǎng)勵(lì)社區(qū)的一些技術(shù)資源貢獻(xiàn)者。
  • 品牌板塊:分為文案、設(shè)計(jì)、視頻、媒體、推廣等;主要是獎(jiǎng)勵(lì)在各大網(wǎng)絡(luò)平臺(tái)分享 Conflux 的各種最新動(dòng)態(tài),擴(kuò)大 Conflux 的生態(tài)影響力的活躍貢獻(xiàn)者;
  • 社群板塊:分為活動(dòng)、推廣等;主要是獎(jiǎng)勵(lì)舉辦各種 Conflux 相關(guān)線上線下活動(dòng),幫助解答社群?jiǎn)栴},活躍日常氣氛等。
  • 資源板塊:分為政務(wù)、商務(wù)、人力等;主要是獎(jiǎng)勵(lì)為生態(tài)中引進(jìn)企業(yè)資源,擴(kuò)建Conflux 生態(tài)等。
  • 其他板塊:分為周邊、采購(gòu)等;主要是獎(jiǎng)勵(lì)一些其他的零散任務(wù)。

關(guān)于 Obsidian Labs

黑曜石實(shí)驗(yàn)室(Obsidian Labs) 是全球最大的區(qū)塊鏈開(kāi)發(fā)工具(IDE)提供商,也是 Conflux Studio 的開(kāi)發(fā)團(tuán)隊(duì),致力于為區(qū)塊鏈開(kāi)發(fā)者提供必備的工具及服務(wù),幫助鏈上應(yīng)用生態(tài)快速發(fā)展。目前,除了 Conflux Studio 外,Obsidian Labs 還為 EOS、Nervos、Substrate、Alogorand 等明星項(xiàng)目提供了專屬的 IDE 和框架工具。






藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼藍(lán)小助,報(bào)下信息,藍(lán)小助會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

轉(zhuǎn)自:csdn
原文鏈接:https://blog.csdn.net/weixin_45029854/article/details/107638406
作者:Sam @黑曜石實(shí)驗(yàn)室
免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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

智能合約 web3.js ABI Address三者的關(guān)系

前端達(dá)人

web3.js是以太坊提供的一個(gè)Javascript庫(kù),它封裝了以太坊的JSON RPC API,提供了一系列與區(qū)塊鏈交互的Javascript對(duì)象和函數(shù),包括查看網(wǎng)絡(luò)狀態(tài),查看本地賬戶、查看交易和區(qū)塊、發(fā)送交易、編譯/部署智能合約、調(diào)用智能合約等,其中最重要的就是與智能合約交互的API。

下面就介紹如何使用web3.js提供的接口調(diào)用智能合約。

系統(tǒng)和軟件


  1. Ubuntu 16.04 64
  2. nodejs 6.10.0
  3. npm 3.10.10

示例合約

本文以下面的MetaCoin合約為例,說(shuō)明在應(yīng)用中使用web3.js操作智能合約的方法。


  1. // 本文中用到的MetaCoin合約
  2. pragma solidity ^0.4.2;
  3. contract MetaCoin {
  4. mapping (address => uint) balances;
  5. event Transfer(address indexed _from, address indexed _to, uint256 _value);
  6. function MetaCoin() {
  7. balances[tx.origin] = 10000;
  8. }
  9. function sendCoin(address receiver, uint amount) returns(bool sufficient) {
  10. if (balances[msg.sender] < amount) return false;
  11. balances[msg.sender] -= amount;
  12. balances[receiver] += amount;
  13. Transfer(msg.sender, receiver, amount);
  14. return true;
  15. }
  16. function getBalance(address addr) returns(uint) {
  17. return balances[addr];
  18. }
  19. }

這個(gè)合約有三個(gè)函數(shù):

MetaCoin:構(gòu)造函數(shù),在合約被部署到區(qū)塊鏈時(shí)執(zhí)行 
getBalance:返回某賬戶的余額,它只讀數(shù)據(jù),不會(huì)修改數(shù)據(jù) 
sendCoin:向另一個(gè)賬戶發(fā)送指定數(shù)量的MetaCoin,它會(huì)改變狀態(tài)變量balances 
啟動(dòng)一個(gè)以太坊節(jié)點(diǎn),將上面的合約部署到區(qū)塊鏈中,并記錄下合約的地址,可以通過(guò)truffle部署,具體參考這篇文章。 接下來(lái)就可以按照下面的步驟在項(xiàng)目中通過(guò)web3.js來(lái)使用這個(gè)合約。

添加web3到項(xiàng)目中

首先新建一個(gè)Nodejs項(xiàng)目并初始化:


  1. $ mkdir web3test && cd web3test
  2. $ npm init

會(huì)提示輸入項(xiàng)目信息,全部默認(rèn)即可。 
接下來(lái)下載web3.js到項(xiàng)目中:

$ npm install web3 --save 
  • 1
  • 2

以上命令會(huì)將web3.js下載到web3test/node_modules目錄下,其中–save參數(shù)會(huì)web3.js添加到package.json配置文件中。

創(chuàng)建web3對(duì)象

要使用web3.js與區(qū)塊鏈交互,需要先創(chuàng)建web3對(duì)象,然后連接到以太坊節(jié)點(diǎn)。 在web3test目錄下新建index.js文件,在其中輸入以下代碼:


  1. var Web3 = require("web3");
  2. // 創(chuàng)建web3對(duì)象
  3. var web3 = new Web3();
  4. // 連接到以太坊節(jié)點(diǎn)
  5. web3.setProvider(new Web3.providers.HttpProvider("http://localhost:8545"));

獲取已部署的合約實(shí)例

要使用智能合約,必須先從區(qū)塊鏈中獲取到合約實(shí)例,獲取合約實(shí)例需要合約的ABI和合約的地址:


  1. // 合約ABI
  2. var abi = [{"constant":false,"inputs":[{"name":"receiver","type":"address"},{"name":"amount","type":"uint256"}],"name":"sendCoin","outputs":[{"name":"sufficient","type":"bool"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"addr","type":"address"}],"name":"getBalance","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[],"payable":false,"type":"constructor"},{"anonymous":false,"inputs":[{"indexed":true,"name":"_from","type":"address"},{"indexed":true,"name":"_to","type":"address"},{"indexed":false,"name":"_value","type":"uint256"}],"name":"Transfer","type":"event"}];
  3. // 合約地址
  4. var address = "0xb2cdd356e58280906ce53e1665697b50f88aac56";
  5. // 通過(guò)ABI和地址獲取已部署的合約對(duì)象
  6. var metacoin = web3.eth.contract(abi).at(address);

metacoin就是獲取到的合約對(duì)象實(shí)例,此時(shí)metacoin對(duì)象中就包含了與合約函數(shù)同名的Javascript函數(shù),之后就可以通過(guò)metacoin對(duì)象來(lái)調(diào)用合約中的函數(shù)了。

調(diào)用合約函數(shù)

MetaCoin合約中有兩個(gè)函數(shù):getBalance和sendCoin,可以通過(guò)metacoin對(duì)象直接調(diào)用這兩個(gè)函數(shù)。

首先來(lái)看getBalance,由于getBalance函數(shù)只是從區(qū)塊鏈中讀數(shù)據(jù),而不修改數(shù)據(jù),因此我們通過(guò)在getBalance后面加上.call()的方式調(diào)用:


  1. var account_one = web3.eth.accounts[0];
  2. var account_one_balance = metacoin.getBalance.call(account_one);
  3. console.log("account one balance: ", account_one_balance.toNumber());

這里:

在getBalance后加上.call()來(lái)顯式指明用call的方式調(diào)用 
通過(guò)call的方式調(diào)用可以得到getBalance函數(shù)的返回值 
通過(guò)call的方式調(diào)用的函數(shù)只在節(jié)點(diǎn)本地虛擬機(jī)中執(zhí)行,不會(huì)產(chǎn)生交易,不會(huì)花費(fèi)費(fèi)用,不會(huì)修改數(shù)據(jù) 
下面來(lái)看sendCoin函數(shù),由于sendCoin要修改合約內(nèi)部的數(shù)據(jù),所以要使sendCoin生效,必須要向區(qū)塊鏈發(fā)送交易,可以在sendCoin后面加上.sendTransaction()來(lái)指明這是一筆交易:


  1. var account_one = web3.eth.accounts[0];
  2. var account_two = web3.eth.accounts[1];
  3. // 提交交易到區(qū)塊鏈,會(huì)立即返回交易hash,但是交易要等到被礦工收錄到區(qū)塊中后才生效
  4. var txhash = metacoin.sendCoin.sendTransaction(account_two, 100, {from:account_one});
  5. console.log(txhash);

這里:

在sendCoin函數(shù)后加上.sendTransaction()指明要向區(qū)塊鏈發(fā)送交易 
合約代碼中sendCoin函數(shù)只有兩個(gè)參數(shù),而在web3中通過(guò).sendTransaction()調(diào)用合約函數(shù)的時(shí)候需要增加最后一個(gè)參數(shù),它是一個(gè)javascript對(duì)象,里面可以指定from/value/gas等屬性,上面的例子用from來(lái)指定交易的發(fā)送者 
上面的調(diào)用語(yǔ)句執(zhí)行后,會(huì)向區(qū)塊鏈提交一筆交易,這筆交易的發(fā)送者是account_one,接收者是metacoin的地址,交易的作用是以account_two和100作為參數(shù)執(zhí)行合約的sendCoin函數(shù) 
函數(shù)會(huì)立即返回交易的hash,表明交易已經(jīng)提交到區(qū)塊鏈,但是并不知道交易何時(shí)處理完成,交易要等到被曠工收錄到區(qū)塊中后才會(huì)生效 
監(jiān)聽(tīng)合約事件

當(dāng)通過(guò).sendTransaction()調(diào)用合約的時(shí)候,交易會(huì)被提交到區(qū)塊鏈進(jìn)行處理,這個(gè)處理需要一定的時(shí)間,如果需要等交易完成之后再執(zhí)行其他操作,就必須要知道交易何時(shí)完成,那么如何知道交易何時(shí)完成呢?可以通過(guò)監(jiān)聽(tīng)合約事件來(lái)實(shí)現(xiàn)。

在合約中可以定義事件,事件可以帶有參數(shù),在合約函數(shù)內(nèi)部完成某些操作時(shí),可以觸發(fā)事件,向外界傳達(dá)一些信息。例如,在MetaCoin合約中定義了一個(gè)事件叫做Transfer,表示一個(gè)轉(zhuǎn)賬的事件,它帶有三個(gè)參數(shù):交易的發(fā)送者、接受者、轉(zhuǎn)賬數(shù)量。在sendCoin函數(shù)中,轉(zhuǎn)賬成功后就會(huì)觸發(fā)Transfer事件,將對(duì)應(yīng)的參數(shù)傳給該事件,這樣外部監(jiān)聽(tīng)到事件后,可以取出事件的參數(shù)來(lái)獲得交易發(fā)送者、接收者、數(shù)量。同時(shí)事件中還帶有其他信息,比如交易hash等。

在web3中使用事件,要首先獲取事件對(duì)象,然后監(jiān)聽(tīng)事件,如果事件發(fā)生,就會(huì)在回調(diào)函數(shù)中獲取到事件信息:


  1. // 獲取事件對(duì)象
  2. var myEvent = metacoin.Transfer();
  3. // 監(jiān)聽(tīng)事件,監(jiān)聽(tīng)到事件后會(huì)執(zhí)行回調(diào)函數(shù)
  4. myEvent.watch(function(err, result) {
  5. if (!err) {
  6. console.log(result);
  7. } else {
  8. console.log(err);
  9. }
  10. myEvent.stopWatching();
  11. });
  12. // 輸出:
  13. { address: '0xb2cdd356e58280906ce53e1665697b50f88aac56',
  14. blockNumber: 651,
  15. transactionIndex: 0,
  16. transactionHash: '0xcc71bc2824cc84d1ee831c46189e3a80cf0af05697ba0370693aa97390c8067b',
  17. blockHash: '0x1d53f04206f3926d0f311b1230a9dd0b0c5aadac35b169a6a609e384ab130c6f',
  18. logIndex: 0,
  19. removed: false,
  20. event: 'Transfer',
  21. args:
  22. { _from: '0x68b73956d704007514e9257813bdc58cdf3c969a',
  23. _to: '0x9c3c1a2f5ef913fac44f0348a78f68d835f3f26e',
  24. _value: { [String: '100'] s: 1, e: 2, c: [Object] } } }


從輸出可以看出,獲取到的事件信息包括事件的參數(shù)、事件名、區(qū)塊號(hào)、交易hash等。

通過(guò)檢測(cè)事件中的transactionHash與調(diào)用合約函數(shù)返回的交易hash是否一致,可以判定某一筆交易是否已完成:


  1. var account_one = web3.eth.accounts[0];
  2. var account_two = web3.eth.accounts[1];
  3. var account_one_balance = metacoin.getBalance.call(account_one);
  4. console.log("account one balance:", account_one_balance.toNumber());
  5. var txhash = metacoin.sendCoin.sendTransaction(account_two, 100, { from: account_one });
  6. var myEvent = metacoin.Transfer();
  7. myEvent.watch(function (err, result) {
  8. if (!err) {
  9. if (result.transactionHash == txhash) {
  10. var account_one_balance = metacoin.getBalance.call(account_one);
  11. console.log("account one balance after sendCoin:", account_one_balance.toNumber());
  12. }
  13. } else {
  14. console.log(err);
  15. }
  16. myEvent.stopWatching();
  17. });
  18. // 輸出:
  19. account one balance: 7000
  20. account one balance after sendCoin: 6900


watch中的回調(diào)函數(shù)如果被執(zhí)行,說(shuō)明事件已被觸發(fā),也就是說(shuō)某筆交易已經(jīng)處理完,檢查交易hash是否一致,可以判定產(chǎn)生這個(gè)事件的交易是否是自己發(fā)送的交易,如果是,就可以進(jìn)行其他操作,比如查詢最新的余額


藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼藍(lán)小助,報(bào)下信息,藍(lán)小助會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

轉(zhuǎn)自:csdn
免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


async function

前端達(dá)人

這篇文章多看幾遍加深理解

async function 聲明定義了一個(gè)異步函數(shù),它返回一個(gè)AsyncFunction對(duì)象。異步函數(shù) 是指通過(guò) 事件循環(huán)(event loop) 異步執(zhí)行的函數(shù),通過(guò)返回一個(gè)隱式的 Promise 作為其結(jié)果。使用異步函數(shù)的代碼的語(yǔ)法和結(jié)構(gòu)更像使用標(biāo)準(zhǔn)同步功能。(The async function declaration defines an asynchronous function, which returns an AsyncFunction object. An asynchronous function is a function which operates asynchronously via the event loop, using an implicit Promise to return its result. But the syntax and structure of your code using async functions is much more like using standard synchronous functions.

語(yǔ)法

async function name([param[, param[, ... param]]]) { statements } 
  • 1

參數(shù)

  • name:函數(shù)名稱
  • param:要傳遞給函數(shù)的參數(shù)。
  • statements:函數(shù)體語(yǔ)句。

返回值:返回一個(gè)promise對(duì)象,將返回異步函數(shù)返回的值(如果異步函數(shù)是resolved則返回resolved的值;如果拋出異常,則rejected從異步函數(shù)中拋出的異常)。(A Promise which will be resolved with the value returned by the async function, or rejected with an uncaught exception thrown from within the async function.)

異步函數(shù)可以包含await表達(dá)式,該表達(dá)式暫停異步函數(shù)的執(zhí)行 并等待 Promise的執(zhí)行結(jié)果返回,結(jié)果返回后就恢復(fù)異步函數(shù)的執(zhí)行。

await 關(guān)鍵字只在異步函數(shù)(async functions)內(nèi)有效。如果在異步函數(shù)外使用它,會(huì)拋出語(yǔ)法錯(cuò)誤。
當(dāng)異步函數(shù)暫停時(shí),它調(diào)用的函數(shù)仍會(huì)繼續(xù)執(zhí)行。

舉例一:

function resolveAfter5Seconds() { return new Promise(resolve => { setTimeout(() => { resolve('resolved'); }, 5000); }); } async function asyncCall() { console.log('calling'); let result = await resolveAfter5Seconds(); console.log(result); // 5s之后輸出結(jié)果 } asyncCall(); //返回的是一個(gè)promise對(duì)象 // console.log(asyncCall()); // Promise { <pending> } 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

運(yùn)行效果:
在這里插入圖片描述
舉例二:

let resolveAfter6Second = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Second = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let sequentialStart = async function () { console.log('sequential start'); const slow = await resolveAfter6Second(); console.log(slow); const fast = await resolveAfter4Second(); console.log(fast); } sequentialStart() //立即輸出 // sequential start // start slow promise //再過(guò)6秒后輸出 // slow promise is done // slow // start fast promise //再過(guò)4秒后輸出 // fast promise is done // fast 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41

運(yùn)行效果:
在這里插入圖片描述
換一種await的寫(xiě)法,結(jié)果完全不同:兩個(gè)計(jì)時(shí)器被同時(shí)創(chuàng)建

let resolveAfter6Seconds = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Seconds = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let concurrentStart = async function () { console.log('concurrent start'); let slow = resolveAfter6Seconds(); let fast = resolveAfter4Seconds(); console.log(await slow); console.log(await fast); } setTimeout(() => { concurrentStart(); }, 2000); //2秒后執(zhí)行 // concurrent start // start slow promise // start fast promise //再過(guò)4秒后執(zhí)行 // fast promise is done //再過(guò)2秒后執(zhí)行 // slow promise is done // slow // fast 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42

運(yùn)行效果:
在這里插入圖片描述
在 concurrentStart 中,兩個(gè)計(jì)時(shí)器被同時(shí)創(chuàng)建,接著執(zhí)行await。等待的是 promise的resolve回調(diào),resolve后面的代碼( console.log(‘fast promise is done’);)會(huì)繼續(xù)執(zhí)行。
這兩個(gè)計(jì)時(shí)器同時(shí)運(yùn)行。但是 await 仍舊是順序執(zhí)行的,第二個(gè) await 還是得等待第一個(gè)執(zhí)行完。在這個(gè)例子中,這使得先運(yùn)行結(jié)束的輸出出現(xiàn)在最慢的輸出之后。
也可以把 concurrentStart 改寫(xiě)成如下,運(yùn)行效果一樣:

let resolveAfter6Seconds = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Seconds = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let concurrentPromise = async function () { console.log('concurrent start'); return Promise.all([resolveAfter6Seconds(), resolveAfter4Seconds()]).then((messages) => { console.log(messages[0]); // slow console.log(messages[1]); // fast }); } setTimeout(() => { concurrentPromise(); }, 2000); //2秒后輸出 // concurrent start // start slow promise // start fast promise //再過(guò)6秒后輸出 // fast promise is done //再過(guò)2秒后輸出 // slow promise is done // slow // fast 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41

并行執(zhí)行兩個(gè)或更多的任務(wù),如下例所示:

let resolveAfter6Seconds = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Seconds = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let parallel = async function () { console.log('start paralel'); await Promise.all([ (async () => console.log(await resolveAfter6Seconds()))(), (async () => console.log(await resolveAfter4Seconds()))() ]); } setTimeout(parallel, 2000); //2秒后輸出 // start paralel // start slow promise // start fast promise //再過(guò)4秒后輸出 // fast promise is done // fast //再過(guò)2秒后輸出 // slow promise is done // slow 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41

運(yùn)行效果:
在這里插入圖片描述
如果希望并行執(zhí)行兩個(gè)或更多的任務(wù),你必須像在parallel中一樣使用await Promise.all([job1(), job2()])

也可以把parallel改寫(xiě)成如下,運(yùn)行效果一樣:

let resolveAfter6Seconds = function(){ console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }); } let resolveAfter4Seconds = function(){ console.log('start fast promise'); return new Promise(resolve =>{ setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let parallelPromise = function(){ console.log('parallelPromise start'); resolveAfter6Seconds().then(msg => console.log(msg)); resolveAfter4Seconds().then(msg => console.log(msg)); } setTimeout(() => { parallelPromise(); }, 2000); //2秒后輸出 // parallelPromise start // start slow promise // start fast promise //再過(guò)4秒后輸出 // fast promise is done // fast //再過(guò)2秒后輸出 // slow promise is done // slow 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39

async/await和Promise#then對(duì)比以及錯(cuò)誤處理:
大多數(shù)異步函數(shù)(async functions )也可以使用 Promises函數(shù) 編寫(xiě)。然而,當(dāng)涉及到錯(cuò)誤處理時(shí),異步函數(shù)不太容易出錯(cuò)。
上面例子中的concurrentStart函數(shù)和concurrentPromise函數(shù)在功能上都是等效的。在concurrentStart函數(shù)中,如果任一awaited調(diào)用失敗,它將自動(dòng)捕獲異常,異步函數(shù)執(zhí)行中斷,并通過(guò)隱式返回Promise將錯(cuò)誤傳遞給調(diào)用者。
在Promise例子中這種情況同樣會(huì)發(fā)生,函數(shù)必須負(fù)責(zé)返回一個(gè)捕獲函數(shù)完成的Promise。在concurrentPromise函數(shù)中,這意味著它從Promise.all([]).then()中返回一個(gè)Promise。事實(shí)上,在此示例的先前版本忘記了這樣做!
但是,async函數(shù)仍有可能然可能錯(cuò)誤地忽略錯(cuò)誤。
以parallel異步函數(shù)為例。 如果它沒(méi)有等待await(或 return)Promise.all([])調(diào)用的結(jié)果,則不會(huì)傳播任何錯(cuò)誤。
雖然parallelPromise函數(shù)示例看起來(lái)很簡(jiǎn)單,但它根本不會(huì)處理錯(cuò)誤! 這樣做需要一個(gè)類(lèi)似于return Promise.all([])處理方式。(詳見(jiàn)

使用async函數(shù)重寫(xiě) promise 鏈

返回 Promise的 API 將會(huì)產(chǎn)生一個(gè) promise 鏈,它將函數(shù)分解成許多部分。例如下面的代碼:

function getProcessedData(url) { return downloadData(url)// returns a promise .catch(e => { return downloadFallbackData(url);// returns a promise }) .then(v => { return processDataInWorker(v);// returns a promise }) } 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

可以重寫(xiě)為單個(gè)async函數(shù):

async function getProcessedData(url) { let v; try { v = await downloadData(url); } catch (e) { v = await downloadFallbackData(); } return processDataInWorker(v); } 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

在上述示例中,return 語(yǔ)句中沒(méi)有 await 操作符,因?yàn)?async function 的返回值將被隱式地傳遞給 Promise.resolve。

return await promiseValue; 與 return promiseValue;的比較

返回值隱式的傳遞給Promise.resolve,并不意味著return await promiseValue;,只是在功能上等同于返回return promiseValue;。
重寫(xiě)的上面代碼,在processDataInWorker拋出異常時(shí)返回null:

async function getProcessedData(url) { let v; try { v = await downloadData(url); } catch(e) { v = await downloadFallbackData(url); } try { return await processDataInWorker(v); // 注意 `return await` 和單獨(dú) `return` 的比較 } catch (e) { return null; } } 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

簡(jiǎn)單地寫(xiě)上return processDataInworker(v);將導(dǎo)致在processDataInWorker(v)出錯(cuò)時(shí)function返回值為Promise而不是返回null。

return foo;return await foo;有一些細(xì)微的差異:
return foo;不管foo是promise還是rejects都將會(huì)直接返回foo。相反地,如果foo是一個(gè)Promise,return await foo;將等待foo執(zhí)行(resolve)或拒絕(reject),如果是拒絕,將會(huì)在返回前拋出異常。


















藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼藍(lán)小助,報(bào)下信息,藍(lán)小助會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

轉(zhuǎn)自:csdn
免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


提高操作效率的B端設(shè)計(jì)

資深UI設(shè)計(jì)者

我從自身實(shí)踐的B端項(xiàng)目經(jīng)驗(yàn)中總結(jié)了幾個(gè)最典型實(shí)用的b端的交互設(shè)計(jì),來(lái)提高用戶的操作效率。

目錄:

一、簡(jiǎn)約至上

二、提高用戶的操作效率

三、智能化操作設(shè)計(jì)



       在設(shè)計(jì)領(lǐng)域已經(jīng)有很多經(jīng)過(guò)時(shí)間和實(shí)踐檢驗(yàn)的定律法則來(lái)作為設(shè)計(jì)的指導(dǎo)原理,它能夠幫助設(shè)計(jì)師更快更有效的將需求轉(zhuǎn)化成合理的界面,并且可以有預(yù)見(jiàn)性的去提高產(chǎn)品的用戶體驗(yàn)。被推崇的有尼爾森十大原則、用戶界面設(shè)計(jì)的八項(xiàng)黃金法則等。但是實(shí)踐出真知,一切的方法論都是源自不斷實(shí)踐中提煉和優(yōu)化的。從原則的輸入理解,到實(shí)踐內(nèi)化,就是自身不斷進(jìn)步的過(guò)程。站在巨人的肩膀上,我們應(yīng)該總結(jié)更多屬于自己的設(shè)計(jì)方法去解決問(wèn)題優(yōu)化設(shè)計(jì)。我從自身實(shí)踐的B端項(xiàng)目經(jīng)驗(yàn)中總結(jié)了幾個(gè)最典型實(shí)用的b端的交互設(shè)計(jì),來(lái)提高用戶的操作效率。


一、簡(jiǎn)約至上

      

       1951年威廉.埃德蒙.??耸紫忍岢?,認(rèn)為人們從數(shù)組中選擇目標(biāo)的時(shí)間取決于可用選項(xiàng)數(shù)量。這表明提出的選項(xiàng)數(shù)量與隨后的選擇反應(yīng)時(shí)間之間存在線性關(guān)系。從廣義上說(shuō),界面越復(fù)雜,用戶就越難找到自己的核心操作點(diǎn),功能越多,就越難發(fā)現(xiàn)真正對(duì)用戶有價(jià)值的東西。

        2011年Giles Colborne在《簡(jiǎn)約至上》,提出“交互設(shè)計(jì)四策略”,即:合理刪除、分層組織、適時(shí)隱藏和巧妙轉(zhuǎn)移這四個(gè)令交互設(shè)計(jì)最大程度簡(jiǎn)單易用的策略。其本質(zhì)上就是消除多余的信息干擾,保留了用戶主操作流程的心流。

       作為設(shè)計(jì)師我們利用“刪除、組合、隱藏、轉(zhuǎn)移”,不單單是為了簡(jiǎn)化而簡(jiǎn)化,我們首要明白的就是要在對(duì)用戶真正重要的事情上節(jié)省他們的腦力。需要把組織成功的標(biāo)準(zhǔn)清晰地構(gòu)建在產(chǎn)品的簡(jiǎn)單上。一次交互就是用戶與設(shè)備之間的一次對(duì)話,提高效率就是要節(jié)約他們的認(rèn)知成本,學(xué)習(xí)成本,操作成本,衡量的指標(biāo)就是完成某個(gè)目標(biāo)的時(shí)間。

      B端管理項(xiàng)目有大量的表格處理,一個(gè)表格對(duì)應(yīng)的數(shù)據(jù)項(xiàng)有很多,遵循簡(jiǎn)約至上的原則我們不會(huì)把所有字段都展示給用戶看,只會(huì)優(yōu)選跟業(yè)務(wù)最核心、用戶關(guān)心的數(shù)據(jù)來(lái)展示給用戶,讓他們看到的盡量簡(jiǎn)約的表格信息。即使是最常用的查詢工具,我們也會(huì)根據(jù)優(yōu)先級(jí)排序,把常用的展示出來(lái),其他的折疊收納,用戶想用到的時(shí)候可以展開(kāi)更多查詢條件。我們無(wú)時(shí)無(wú)刻不遵循著這個(gè)設(shè)計(jì)原則。

 


二、提高用戶的操作效率


1、快速定位目標(biāo)信息


       在信息量大的B端系統(tǒng)里,快速找到目標(biāo)信息是最常用的功能。除了導(dǎo)航上的搜索,我所負(fù)責(zé)的項(xiàng)目幾乎在每個(gè)信息頁(yè)面中都使用了查詢,篩選、排序功能,這也是常規(guī)表格對(duì)信息處理的一種快捷方式。常規(guī)的信息定位有搜索、查詢、篩選、排序,不同的方式數(shù)據(jù)的檢索模式也不同。根據(jù)不同業(yè)務(wù)場(chǎng)景,合理的使用才能幫助用戶縮小信息范圍,找到目標(biāo)信息,提高用戶完成一個(gè)任務(wù)的效率。


搜索:是用戶指定任意條件(文本、語(yǔ)音等),平臺(tái)對(duì)此條件進(jìn)行檢索后,展示對(duì)應(yīng)內(nèi)容。搜索由用戶自定義條件,主動(dòng)表達(dá)意圖 ,目的性明確。由于搜索行為是用戶主動(dòng)表達(dá)意圖,往往一個(gè)簡(jiǎn)短的關(guān)鍵詞并不能完整表述用戶想法,因此,搜索結(jié)果的內(nèi)容通常包含多種類(lèi)型從精確到模糊的展現(xiàn)規(guī)則。


查詢:是利用關(guān)鍵字、詞組對(duì)系統(tǒng)內(nèi)的相關(guān)信息進(jìn)行多條件組合檢索。同時(shí)用戶也可以輸入指定條件的信息作為搜索項(xiàng),但由于查詢功能無(wú)法對(duì)非結(jié)構(gòu)化的文件內(nèi)容進(jìn)行查找,所以輸入條件不夠精準(zhǔn)將無(wú)法查詢到最終信息。


篩選:是平臺(tái)為用戶提供指定條件,用戶可以選擇查看符合一類(lèi)或多類(lèi)條件下的內(nèi)容。投顧項(xiàng)目一般都是先大范圍查詢,再?gòu)牟樵兘Y(jié)果列表中,進(jìn)行表頭(快捷、對(duì)應(yīng)、條件更明確細(xì)化)的信息篩選。


排序:是根據(jù)已設(shè)定的內(nèi)在邏輯,將一組“無(wú)序”的記錄序列調(diào)整為“有序”的記錄序列。




2、縮短操作路徑


        縮短操作路徑簡(jiǎn)單的說(shuō)就是減少操作的步驟來(lái)提升操作效率,是基于對(duì)用戶、任務(wù)及環(huán)境的清晰理解的前提條件下,對(duì)用戶操作的路徑進(jìn)行優(yōu)化。我們可以從以下兩方面入手:


2.1、通過(guò)預(yù)測(cè)用戶下一步的行為

        通過(guò)預(yù)測(cè)用戶下一步的行為,對(duì)用戶進(jìn)行直接引導(dǎo),縮短用戶的行為路徑,減少操作步驟。比如在一系列連貫的操作流中某個(gè)鏈路執(zhí)行出現(xiàn)問(wèn)題時(shí),用戶下一步的行為是需要及時(shí)查看錯(cuò)誤內(nèi)容并處理相關(guān)信息,在執(zhí)行結(jié)果中增加一個(gè)快速查看的按鈕,引導(dǎo)他去查看和處理問(wèn)題。這比他去菜單中重新查找對(duì)賬信息效率要高很多。



2.2、通過(guò)用戶操作路徑分析減少操作步驟

      涉及到大量的信息管理時(shí),那對(duì)于信息的快速處理就涉及到批量操作。通過(guò)用戶操作路徑分析,用戶勾選批量執(zhí)行的操作頻繁,單項(xiàng)處理在較少情況才會(huì)用到。針對(duì)此分析,我們找到了一些具有共同批量操作特點(diǎn)的管理頁(yè)面,對(duì)其進(jìn)行操作路徑的優(yōu)化。批量操作可完全合并成一個(gè)執(zhí)行觸發(fā)點(diǎn)。將這個(gè)執(zhí)行點(diǎn),單獨(dú)成一個(gè)tab切換頁(yè),細(xì)化操作為另一個(gè)切換頁(yè)。tab頁(yè)面的設(shè)計(jì),也為錯(cuò)誤信息的顯示騰出了空間,整個(gè)頁(yè)面清晰可對(duì)比。經(jīng)過(guò)操作路徑的驗(yàn)證,這個(gè)按鈕使用率極高,明細(xì)操作幾乎沒(méi)有使用到,也縮短了管理頁(yè)面的操作時(shí)間。




3、減少記憶負(fù)擔(dān)


       減少記憶負(fù)擔(dān),是減少用戶在操作時(shí),需要記憶的信息量。一方面我們需要,簡(jiǎn)化多余的信息,減少用戶對(duì)頁(yè)面的認(rèn)知負(fù)荷,另一方面我們可以設(shè)計(jì)記憶性功能可以幫助用戶記憶。


       為什么要去減少用戶的記憶負(fù)擔(dān),一方面,縮短整個(gè)操作的時(shí)間快速達(dá)成操作目標(biāo),另一方面,降低記憶數(shù)據(jù)量,有助于提升用戶使用的愉悅感。從心里學(xué)來(lái)講, 人們往往更容易記住那些自己喜歡的事物,而對(duì)不喜歡的東西記起來(lái)比較吃力,在信息大爆炸時(shí)代,我們要記憶的很多信息如登錄號(hào)、證件號(hào)、密碼、賬戶號(hào)等,這些信息有的不但復(fù)雜,而且對(duì)用戶來(lái)說(shuō)枯燥無(wú)味不想記憶,有一種天然的排斥感。那我們通過(guò)幫助用戶去記憶留存,再在合適的機(jī)會(huì)調(diào)用顯示,會(huì)提高他們?cè)谑褂眠^(guò)程中的輕松和愉快感。比如對(duì)歷史登錄賬戶號(hào)的保留,秘鑰儲(chǔ)存功能,再到短信驗(yàn)證的直接不用密碼即可登錄,驗(yàn)證碼還可以直接復(fù)制到剪貼板,這都是為了降低他們的記憶成本。



      隨著業(yè)務(wù)的發(fā)展,平臺(tái)菜單數(shù)越來(lái)越多,對(duì)用戶來(lái)說(shuō)非目標(biāo)菜單的數(shù)量增加,用戶需要更長(zhǎng)時(shí)間來(lái)記憶所選項(xiàng)目的位置,到最后完全只能選擇上方的搜索框進(jìn)行菜單搜索。Google對(duì)用戶的測(cè)試表明,沒(méi)有一個(gè)人始終會(huì)把搜索作為第一選擇。相反,他發(fā)現(xiàn)只有在網(wǎng)站沒(méi)有提供有效導(dǎo)航的情況下,用戶才會(huì)使用搜索。搜索需要輸入關(guān)鍵詞,即使有模糊匹配,還要進(jìn)行選擇,而且這個(gè)過(guò)程不一定順利,可能需要反復(fù)操作才能順利找到才能找到自己心中的目標(biāo)。我們小組設(shè)計(jì)師通過(guò)競(jìng)品分析和用戶訪談得到的一個(gè)驗(yàn)證性的問(wèn)題,就是平臺(tái)存在菜單設(shè)計(jì)命名不合理的情況,急需優(yōu)化。優(yōu)化思路一個(gè)是合理菜單命名與菜單結(jié)構(gòu),但這個(gè)不是一蹴而就的事情,需要從產(chǎn)品整個(gè)角度去整理和長(zhǎng)遠(yuǎn)排期,持續(xù)迭代。為此我們先選擇了幫助用戶記憶的思路,即做一個(gè)菜單收藏的功能。用戶可以手動(dòng)把常用菜單直接收藏在首頁(yè),如果在沒(méi)有收藏或者收藏未滿限制數(shù)量時(shí),會(huì)根據(jù)記錄的用戶訪問(wèn)次數(shù)提供最常用的菜單(以用戶為導(dǎo)向,自定義功能;以首頁(yè)為核心提供業(yè)務(wù)線支持),無(wú)需去記憶菜單位置,不斷尋找菜單。




4、信息可對(duì)照 


      在處理信息的時(shí)候,提供信息的對(duì)照,減少了跳轉(zhuǎn),增強(qiáng)關(guān)聯(lián)信息的對(duì)比,可以很大程度提升用戶處理信息的效率。從系統(tǒng)上講就是分屏,處理多任務(wù)事件(蘋(píng)果和Windows系統(tǒng)均很好的使用了分屏功能)。從頁(yè)面角度來(lái)講,其實(shí)就是合理化信息模塊展示,一個(gè)頁(yè)面不止展示一個(gè)信息層級(jí)的內(nèi)容。信息內(nèi)容有從屬關(guān)系(避免跳轉(zhuǎn))、因果關(guān)系(顯示結(jié)果)、并列關(guān)系(同級(jí)對(duì)比)。



      同樣具有審批功能的B端項(xiàng)目可能審批流程的設(shè)計(jì)會(huì)完全不同。我負(fù)責(zé)的另一個(gè)項(xiàng)目主要任務(wù)是對(duì)重大任務(wù)的監(jiān)控,保障日間重點(diǎn)工作按時(shí)完成,審批必然嚴(yán)格,且需要單條仔細(xì)處理。所以我們?cè)O(shè)計(jì)的是樹(shù)菜單的形式,讓用戶可以將待處理信息的條目和內(nèi)容可以直接對(duì)照來(lái)處理,提高效率。



三、智能化操作設(shè)計(jì)


      隨著B(niǎo)端行業(yè)日益成熟,越來(lái)越多的C端設(shè)計(jì)師轉(zhuǎn)型成B端設(shè)計(jì)師,B端行業(yè)的設(shè)計(jì)思維也不斷的融合和革新,如今B端產(chǎn)品也越來(lái)越重視產(chǎn)品的情感化建設(shè)、整體的用戶體驗(yàn)、簡(jiǎn)約高效的智能化提升。

      首先讓大家了解一個(gè)概念,那就是泰斯勒定律,也就是我們常說(shuō)的復(fù)雜性守恒定律。泰斯勒定律認(rèn)為每一個(gè)過(guò)程都有其固有的復(fù)雜性,這個(gè)復(fù)雜性存在一個(gè)臨界點(diǎn),超過(guò)了這個(gè)點(diǎn)就不能再簡(jiǎn)化了,你只能將固有的復(fù)雜性從一個(gè)地方移動(dòng)到另外一個(gè)地方。



      對(duì)于我所負(fù)責(zé)的項(xiàng)目來(lái)說(shuō),最能體現(xiàn)產(chǎn)品日趨智能化的交互設(shè)計(jì)就是清算流程的設(shè)計(jì)。以往的清算流程是分大流程,點(diǎn)擊流程步驟跳轉(zhuǎn)至相關(guān)操作頁(yè),再進(jìn)行子模塊的操作與檢驗(yàn)。完成后,切換回住流程去執(zhí)行下一個(gè)模塊的操作。操作員的操作連續(xù)性差且操作步驟多,完全由操作員手動(dòng)操作觸發(fā),體驗(yàn)繁瑣及不流暢。為此我們重新梳理了所有清算流程步驟,精間可合并的操作步驟,然后將所有步驟按照時(shí)間節(jié)點(diǎn)順序排列,完成先前步驟才能進(jìn)行下一個(gè)步驟。流程下方就是對(duì)應(yīng)的執(zhí)行模塊,只需一鍵執(zhí)行便可完成當(dāng)前清算步驟。極大的提高了用戶清算的操作成本。



      后續(xù)我們UE小組也會(huì)針對(duì)平臺(tái)進(jìn)行用戶調(diào)研,建立了用戶畫(huà)像。對(duì)于運(yùn)維人員痛點(diǎn)分析后,提出清算流程自動(dòng)化設(shè)計(jì),用定時(shí)任務(wù)直接去執(zhí)行相關(guān)的流程操作,用戶不用進(jìn)行操作,即可完成結(jié)算,只需要關(guān)注狀態(tài)和處理錯(cuò)誤信息。



       自動(dòng)化智能設(shè)計(jì)的最大缺陷就是無(wú)法遇到極致的準(zhǔn)確率。實(shí)際處理過(guò)程中,還是會(huì)有清算錯(cuò)誤信息存在。為了解決這個(gè)問(wèn)題,我們保留了執(zhí)行按鈕(不手動(dòng)操作時(shí),自動(dòng)跑完),運(yùn)維人員也可以手動(dòng)執(zhí)行,處理問(wèn)題。除了將操作日志信息模塊,作為組件,分屏來(lái)顯示錯(cuò)誤信息,我們還按照商戶維度來(lái)計(jì)算狀態(tài),以便于運(yùn)維人員發(fā)現(xiàn)具體的錯(cuò)誤位置。幫助操作員去查看和解決錯(cuò)誤信息。智能化的設(shè)計(jì)解放了很大一部分的重復(fù)勞動(dòng),讓用戶更聚焦有意義的工作。

        智能化已然成為了設(shè)計(jì)趨勢(shì),這將會(huì)對(duì)系統(tǒng)的性能提升和信息處理精準(zhǔn)化提出更高的要求。


藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼ben_lanlan,報(bào)下信息,會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

文章來(lái)源:站酷  作者:上仙修行

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


關(guān)于后臺(tái)系統(tǒng)設(shè)計(jì)規(guī)范總結(jié)

資深UI設(shè)計(jì)者

一套完善的產(chǎn)品化設(shè)計(jì)系統(tǒng),可以解決內(nèi)部協(xié)作的一致性問(wèn)題,解決設(shè)計(jì)系統(tǒng)更新的周期性問(wèn)題,解決一群設(shè)計(jì)師與工程師如何規(guī)?;纳a(chǎn)各種業(yè)務(wù)、UI的問(wèn)題,從而最終解決用戶體驗(yàn)一致性的問(wèn)題。說(shuō)到自己,公司的產(chǎn)品從接手開(kāi)始便是以antdesign作為前端框架,所以很多人會(huì)說(shuō)后臺(tái)用antdesign、Element或者Taro的框架就足夠了呀,當(dāng)然不~在已有的成熟框架下,也并不能完全滿足產(chǎn)品日(sang)益(xin)旺(bing)盛(kuang)的需求,所以設(shè)設(shè)計(jì)規(guī)范還是很有必要的。

作為B端設(shè)計(jì)師,視覺(jué)表現(xiàn)層面權(quán)重逐漸減少,更多的是需要梳理邏輯流程,將線下業(yè)務(wù)更好的梳理到線上流程,所以熟知設(shè)計(jì)規(guī)范可以更效率的完成工作。



設(shè)計(jì)規(guī)范的目的:


1、解決內(nèi)部協(xié)作的一致性問(wèn)題

為設(shè)計(jì)師內(nèi)部溝通協(xié)作起到?jīng)Q定作用,當(dāng)同一個(gè)項(xiàng)目存在多個(gè)設(shè)計(jì)師橫向設(shè)計(jì)的時(shí)候,設(shè)計(jì)規(guī)范會(huì)避免顏色錯(cuò)誤、間距失調(diào)、控件混亂等問(wèn)題。

2、解決設(shè)計(jì)系統(tǒng)更新的周期性問(wèn)題

隨著產(chǎn)品的不斷推進(jìn)和發(fā)展,為了新增的需求和不斷優(yōu)化的用戶體驗(yàn),這時(shí)候會(huì)需要對(duì)某些規(guī)范控件進(jìn)行調(diào)整,在有設(shè)計(jì)規(guī)范的情況下,可以迅速對(duì)接開(kāi)發(fā)快速全局調(diào)整控件,極大的提升了設(shè)計(jì)和開(kāi)發(fā)的工作效率。


3、解決設(shè)計(jì)師與工程師如何規(guī)模化的生產(chǎn)各種業(yè)務(wù)

關(guān)于和開(kāi)發(fā)對(duì)接,圖標(biāo)在如今有了iconfont的項(xiàng)目管理下,項(xiàng)目可以建立自己的圖標(biāo)庫(kù)。再加上設(shè)計(jì)建立的可復(fù)用的公共控件庫(kù),開(kāi)發(fā)可以更加快捷的復(fù)用控件,減少返工率,也為后期的修改降低開(kāi)發(fā)成本。


關(guān)于建立后臺(tái)設(shè)計(jì)規(guī)范:


首先要了解項(xiàng)目適用的主要場(chǎng)景,也就是用戶爸爸一般是在什么情況下用什么樣的設(shè)備來(lái)進(jìn)行操作的,然鵝你永遠(yuǎn)不知道會(huì)有什么的場(chǎng)景和什么樣奇葩的設(shè)備在等待你。在后臺(tái)的設(shè)計(jì)群一直有一個(gè)經(jīng)久不衰的話題,那就是后臺(tái)設(shè)計(jì)的設(shè)計(jì)分辨率是向下適配還是向上適配更合適(是1980*1080 還是 1440*900 ),這兩者都是可以的,本案由于用戶使用筆記本的情況居多,且設(shè)備并不是很新所以采用1440*900的分辨率向上適配1980向下適配1200。
在清楚的了解到項(xiàng)目背景之后,開(kāi)始著手于設(shè)計(jì)規(guī)范的建立,這里關(guān)于設(shè)計(jì)規(guī)范的建立是隨著設(shè)計(jì)的不斷深入從而不斷完善的,不必刻意深入,但是要隨時(shí)更新規(guī)范文檔。



關(guān)于頁(yè)面構(gòu)成


開(kāi)發(fā)與設(shè)計(jì)所理解的頁(yè)面是不一樣的,所以會(huì)造成開(kāi)發(fā)出來(lái)的頁(yè)面有時(shí)候會(huì)因?yàn)楦鞣N原因與高保真相差較大,在設(shè)計(jì)看來(lái)(比如sketch),一個(gè)頁(yè)面是由多個(gè)組結(jié)合而來(lái),每個(gè)組里包含一個(gè)或多個(gè)字段、圖片和圖標(biāo)等,在調(diào)整大小、間距、顏色之后慢慢成為高保真。而在開(kāi)發(fā)的角度來(lái)看,整個(gè)頁(yè)面就是由多個(gè)box構(gòu)成,盒子與盒子之間存在空白間隔,且盒子存在一定的屬性,例如盒子默認(rèn)對(duì)齊于左上,盒子之間相互嵌套或覆蓋需要基于所屬盒子來(lái)定位。


顏色

根據(jù)品牌背景和產(chǎn)品定位來(lái)確定你的品牌色,用于字體、icon、按鈕、插畫(huà)等業(yè)務(wù)流程。功能色則是為特殊場(chǎng)景,例如失敗、成功、提醒等情況。


字體

通過(guò)購(gòu)買(mǎi)商用字體或使用免費(fèi)字體來(lái)使用,如果選用免費(fèi)字體同時(shí)也要注意區(qū)分系統(tǒng),通常情況下mac系統(tǒng)使用默認(rèn)字體蘋(píng)方字體,windows系統(tǒng)使用微軟雅黑。如今免費(fèi)等字庫(kù)已經(jīng)越來(lái)越多了,所以這對(duì)設(shè)計(jì)師來(lái)說(shuō)是一個(gè)好消息,今年阿里也在UCAN上公布了普惠體,年尾oppo也推出了自己的免費(fèi)字體,文章末尾附上群友整理的免費(fèi)字體導(dǎo)圖。


邊角

倒角的使用可以起到樣式的區(qū)分,從而讓用戶感知到功能區(qū)域的分別。


圖標(biāo)

快速幫助用戶理解產(chǎn)品并順利完成操作,好的圖標(biāo)具有高度濃縮并快捷傳達(dá)、便于記憶的特性,能夠更好的傳達(dá)品牌特性。


陰影

陰影的添加可以更好的提高界面品質(zhì),讓用戶易于區(qū)分功能區(qū)域


按鈕

按鈕是傳達(dá)它將要發(fā)起動(dòng)作的載體。 用戶可以點(diǎn)擊一個(gè)按鈕來(lái)開(kāi)始一個(gè)過(guò)程或工作流程,或觸發(fā)一個(gè)動(dòng)作。

用法:

1、要傳達(dá)重要的行動(dòng)。如:提交表單;

2、要導(dǎo)航到另一個(gè)屏幕,觸發(fā)一個(gè)模式或啟動(dòng)一個(gè)動(dòng)作。如:在進(jìn)程中指定新的動(dòng)作或模式;

3、按鈕上的文本應(yīng)保持簡(jiǎn)潔,帶著明確、可操作的動(dòng)詞,例如:注冊(cè)、下一步、下載 ;

4、優(yōu)先考慮最重要的行動(dòng)。行動(dòng)號(hào)召太多會(huì)引起混亂,并使用戶不知道下一步該做什么。

選擇輸入框

如無(wú)特殊需求,則默認(rèn)采用框架內(nèi)輸入框,特殊情況可同研發(fā)一起討論修改。這邊因?yàn)橐恍┨厥庠?,在修改了代碼的情況下實(shí)現(xiàn)了標(biāo)題、選擇、輸入同時(shí)在框架內(nèi),這樣為寸土寸金的后臺(tái)界面留出了更多的空間。


表格

表格在后臺(tái)系統(tǒng)中無(wú)處不在,對(duì)數(shù)據(jù)管理和分析起到了重要的作用,方便用戶閱讀,分析和比較數(shù)據(jù)。表格一般由表頭、表尾、數(shù)據(jù)單元格組成。


模態(tài)/非模態(tài)彈窗

用戶交互的兩種方式,模態(tài)彈窗強(qiáng)制交互完成當(dāng)前操作流程,非模態(tài)則是弱提示。

缺省狀態(tài)

缺省頁(yè)是指操作異常狀態(tài)下給予用戶反饋的提示頁(yè)面,它的作用不僅是提醒用戶,安撫情緒;更重要的是用“空白”觸發(fā)用戶的操作行為,營(yíng)造良好用戶體驗(yàn)。


結(jié)語(yǔ)


以上是我對(duì)于設(shè)計(jì)規(guī)范的部分總結(jié),還有很多沒(méi)有涉及到,包括非常重要的可視化部分,可以多了解一下ECharts(https://www.echartsjs.com/zh/index.html),然后希望可以和大家互相學(xué)習(xí)。設(shè)計(jì)規(guī)范的建立是長(zhǎng)征的第一步,貫徹執(zhí)行才是根本,在B端龐大的設(shè)計(jì)系統(tǒng)中,我們需要維護(hù)好產(chǎn)品的組件庫(kù),不斷的完善用戶體驗(yàn)和清晰的梳理線上業(yè)務(wù),保證產(chǎn)品的功能需求才是重中之重。


藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)掃碼ben_lanlan,報(bào)下信息,會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系。

文章來(lái)源:站酷  作者:請(qǐng)叫我紅領(lǐng)今

分享此文一切功德,皆悉回向給文章原作者及眾讀者.

免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

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


日歷

鏈接

個(gè)人資料

存檔