我們一開始為什么去安裝應(yīng)用程序？是為了使我們的生活更方便。但當(dāng)一個應(yīng)用無法滿足這一要求時，用戶肯定就會離它而去。一個應(yīng)用的成功是受多種因素影響的，其中整體移動用戶體驗(yàn)是最重要的影響因素。絕佳的用戶體驗(yàn)是一個應(yīng)用程序成功的關(guān)鍵。

演講題目

Ubiquitous Fun-交互設(shè)計(jì)的享樂主義未來

在可預(yù)見的未來，隨著用戶數(shù)據(jù)的積累和人工智能的發(fā)展，產(chǎn)品“可用性”問題會逐漸淡出我們的討論主題，同時，人們對物質(zhì)的需求總是非常有限的，因此“實(shí)用性”價值空間也會越來越小。交互設(shè)計(jì)會越來越關(guān)注人們對精神享樂的無止境的追求，設(shè)計(jì)師可以利用這一點(diǎn)引導(dǎo)人類向更健康的行為方式進(jìn)化。

用戶真的有通過電臺App來跑步的需求嗎？

這是我們在規(guī)劃這個產(chǎn)品功能時的第一個問題。即使在音樂類軟件都已經(jīng)上線了跑步相關(guān)功能的當(dāng)下，我們依然發(fā)問——真的有人，通過電臺App來跑步嗎？

如果僅僅是針對現(xiàn)在電臺類App，那需求一定是微乎其微，不同于音樂統(tǒng)一的內(nèi)容屬性，電臺類內(nèi)容屬性太豐富——音樂時間短，小說時間長；相聲很搞笑，新聞很嚴(yán)肅······這些內(nèi)容決定了他們天然就不能像音樂一樣隨機(jī)重組。

有時候我們需要退一步來思考需求。

很多有資歷的設(shè)計(jì)師會厭煩那些具體且瑣碎的需求。因?yàn)樵O(shè)計(jì)已被當(dāng)作一種明確的任務(wù)去執(zhí)行。現(xiàn)實(shí)就是這樣，當(dāng)你把自己局限并等待別人過來派發(fā)“任務(wù)”時，其實(shí)已被降格成乙方。怎樣才能擺脫這樣的窘境？除了讓自己努力當(dāng)上喬納森·埃維外，唯一的辦法就是系統(tǒng)地洞察產(chǎn)品的真正問題，將自己的想法勇敢講出來。

企鵝FM 3.0設(shè)計(jì)中，設(shè)計(jì)團(tuán)隊(duì)也在努力實(shí)現(xiàn)自我價值，洞察產(chǎn)品的核心體驗(yàn)并針對問題思考策略。

2016年末，各路APP也紛紛展開一輪輪的數(shù)據(jù)廝殺，從不同的視角闡述過去一年的精彩故事。而坐擁龐大用戶數(shù)據(jù)的QQ空間，在這個既難忘又不舍的2016年，用戶的故事將會被如何演繹，在寒冬帶給用戶怎樣的溫暖回憶呢？

幾個星期前，CSS Variables ——CSS 變量草案發(fā)布在了W3C官方 ,更準(zhǔn)確的應(yīng)該叫CSS 自定義屬性，目前在Chrome Canary 版里面已經(jīng)支持，開啟該功能見附[1]

當(dāng)Chrome瀏覽器工程師Addy Osmani第一時間把這消息發(fā)布在twitter后，遭到了數(shù)萬人的否定、敵視和懷疑。于我而言，更多的感到是一個驚喜，因?yàn)檫@個功能實(shí)在讓人太興奮了。

快速的掃了一遍之后，發(fā)現(xiàn)99%人抱怨的無外乎這兩點(diǎn)：

• 語法太丑和不夠簡潔
• Sass 、Less早就有這些玩意了，不太care

雖然我承認(rèn)我也對這語法很反感，更重要的是理解語法不只是反復(fù)無常的在選擇。CSS工作組討論很久語法的長度，他們提取了一些點(diǎn)，考慮到CSS的語法兼容不會與未來增加的其他語言沖突。

“想看到真正的世界，就要用天的眼睛去看天，用云的眼睛去看云，用風(fēng)的眼睛去看風(fēng)，用花草樹木的眼睛去看花草樹木，用石頭的眼睛去看石頭，用大海的眼睛去看大海，用動物的眼睛去看動物，用人的眼睛去看人?！?

——引自《天才在左 瘋子在右》

作為一名用戶研究者，我在日常工作中會接觸到各種各樣的用戶。面對這些用戶時，我也會不自覺地有著各種各樣的感受。這里先分享幾個粉絲的故事，看看大家有什么感覺：

滑屏的交互形式自從在 H5 中流行起來，便廣泛應(yīng)用在產(chǎn)品宣傳、廣告、招聘和活動運(yùn)營等場景中，作為微信朋友圈廣告慣用的形式，其影響力更是得到了強(qiáng)化與放大。如今滑屏H5可謂玲瑯滿目，數(shù)不盡數(shù)。

作為一個 UI工程師，接過很多類似的項(xiàng)目，也曾寫過滑屏的插件，在經(jīng)歷了不同的需求的“洗禮”并踩過若干個坑之后，不禁反問自己：應(yīng)該如何面對每一次類似的需求，在已有的經(jīng)驗(yàn)下如何做到體驗(yàn)更好？如何節(jié)省工作量提率？面對性能優(yōu)秀的 iOS 與性能良莠不齊的 Android 平臺，又如何做到體驗(yàn)統(tǒng)一與性能最優(yōu)？

下劃線 一般在文檔中常被用作增強(qiáng)注意，在過去打字機(jī)時代，下劃線成為了唯一的一種文字強(qiáng)調(diào)方式，具體的操作方法是在已經(jīng)打出來的文字上面退格，再在同樣的地方打出下劃線。

而在網(wǎng)頁中，可以鏈接的文字（超鏈接）下面一般都有下劃線。在制作頁面的時候，當(dāng)鏈接需要下劃線的時候，UI開發(fā)很自然的會想到使用text-decoration屬性來顯示，例如這樣：

以上顯示的是設(shè)計(jì)稿和瀏覽器渲染的實(shí)際效果，我們會發(fā)現(xiàn)瀏覽器渲染的效果和設(shè)計(jì)稿有出入，主要表現(xiàn)在下劃線的位置，這時候細(xì)心的設(shè)計(jì)師會要求你想辦法實(shí)現(xiàn)他們本來想要實(shí)現(xiàn)的效果?？上У氖?，在這幾年的網(wǎng)頁排版技術(shù)發(fā)展中，并沒有更好的css屬性出現(xiàn)來支持下劃線的個性化設(shè)置，所以這個問題常常會被忽略。

這個一般在UI開發(fā)看來，可能覺得并沒有什么問題，難道說不應(yīng)該使用text-decoration這個屬性嗎？

以往拿到一份視覺稿要做頁面適配，通常都是針對不同分辨率尺寸做斷點(diǎn)寫 media
query，然后看效果再微調(diào)。開發(fā)過程中視覺稿要是做了修改，修改的地方就得再走一遍分辨率測試和微調(diào)，這時想屎的心都有了。而且這些適配都是建立在已
知的分辨率尺寸庫上，如果市面新出來一款分辨率尺寸機(jī)型，呵呵，又要奔跑在測試微調(diào)路上。是不是能有用一套代碼就適應(yīng)各種分辨率窗口，那么就不會再有上面
這些煩惱，且開發(fā)效率快和維護(hù)成本會降低很多。