如何定義牛逼工程師

有軟件工程方面的研究說，對于開發者個體而言，最優秀的開發者的生產效率約為平均值的2倍，而優秀的開發者會吸引其它優秀的人，或者激勵與幫助團隊中的其它成員，最終使團隊之間的生產效率差異達到10倍之多。

所謂牛逼的工程師，就是那些個體效率是其它人2倍，形成團隊之后達到10倍差異的一群人。

前端領域這幾年發展速度非常快，人才分布呈兩級分化趨勢，大家都在說缺前端，其實缺的是牛逼前端，對于低端的前端，培訓機構一直在量產，但是無法滿足要求。很多情況下，一個牛逼前端對于團隊的價值是再多低端前端都無法提供的。

牛逼的前端工程師有一些共通的特質，這些特質也許不屬于前端的核心范疇，但是可以通過它們將牛逼的人識別出來。

對用戶體驗的追求

文字排版不只是從下拉選單選擇字型和點數而已，文字排版是一項流傳數世紀的技藝，自木制和金屬的活版印刷便開始，而且它不只歷史悠久，還很實用，大部分的人只要掌握一些實用的訣竅，就可以將之活用在諸如履歷表、電子報或名片等日常設計項目上。下邊就教你幾個排版技巧，幫你輕松搞定UI設計。

（1）將要表達的訊息配上適當的感覺。每種字型都散發獨特的情感或個性，也許是友善、新潮、嚴肅或傻里傻氣，但大部分的字型并不是萬用的，所以你要判斷一個字型對你來說是怎么樣的感覺，還有它適不適合放在這個設計里面。方法之一就是列出你希望設計呈現哪些特質，如果能先確定內容更好，這樣就能直接挑選字型來配合建立好的內文調性。

交互設計是UI設計中的必不可少的一個過程，交互設計也要遵循一定的步驟，總體來說要經歷三個階段，那么具體是哪三個階段呢？下邊是以為資深老鳥為我們帶來的他的交互經驗，希望對設計師們起到一定的幫助。

（1）讀文檔，明需求，多溝通，擅闡述。需求文檔類型多種多樣，無論哪種，首要任務是讀懂需求的內容，透徹理解范圍層的含義，及相關的業務形態。把自己當用戶代入思考，如何讓使用者快速上手，減少學習成本。一般情況下，拿到PM的需求文檔，我會先讀一遍，整理出整個文檔的架構、要點、功能點等。記錄過程中不理解的內容，羅列問題清單，找PM溝通。溝通的效率也很重要，我會先聽PM講完，然后用自己的話闡述一遍，助于理解。

人人都喜歡有成就感，這種感覺是對自己的肯定和支持，也是對自己最大的鼓勵。設計師也是如此。設計出來的作品不斷地得到客戶的肯定，這就是設計師最想要的成就感，但是，成就感不是說來就來的，成就感是需要付出努力和一定的代價的，這種代價可能是時間，可能是金錢，也有可能是精力。那么今天我們就來分享一下如何讓設計師能更好的獲得成就感。

（1）、作為一個設計師要多去總結。每一個項目完成的背后肯定付出的很多汗水，把問題收集并且記錄下來，成為你后續分享的重要途徑，千萬不要覺得這是多余的，默默無聞的做只會埋沒你自己，設計師不能只是關注設計，有時間多去吸收相關領域的知識，不單單只是為設計而設計。

#交互學堂#深度訪談是用戶研究中經常用到的研究方法，它是一種無結構的、直接的、一對一的訪問形式，用以揭示被試對某一問題的潛在動機、態度和情感。它的關鍵在于『深度』。怎樣才能做到有『深度』呢？那就不得不提到心理學上的投射效應。

寫在前面：

我以前是學空間設計的，所以對引導性的感知比其他學設計的要更早。其實，設計總就還是一個“萬法歸宗”的東西。“吸引”——“引導”——“持續”——“欲罷不能”用用戶的這種思維去檢驗自己的作品（交互/UI）是比較客觀的。那個步奏出了問題，喪失了用戶，那個點就是你的失敗點。

很多設計師的很多新想法和新的操作邏輯很有意思，或者說新推出的商業企劃很有吸引力，但問題是如何讓用戶最樂意的去接受，而且不過分增加界面和程序壓力這才是我們需要考慮的。否則——套用有些老板的話：要你干嘛？

早在 2004 年，我才剛開始工作的時候，sIFR 非常火。sIFR 是由 Shaun Inman 開發、可以電影短片中嵌入定制字體的一種技術，它能被 JavaScript 和 CSS 調用。當時，sIFR 基本上是唯一一種能在 Firefox 或 Safari 瀏覽器中使用定制字體的技術。隨著 2007 年 iPhone（不需要 flash）的推出，基于 Flash 格式的這種技術很快就過時了。

在Spotify 7500 的月活躍用戶中，有 2000 萬左右是付費用戶。如果說 1% 是普遍的水準，然后 DropBox 4% 的轉化率是非常不錯的話，那Spotify 的26.6% 付費率絕對可以稱得上是令人匪夷所思了。今天這篇好文從設計的角度，揭秘這26.6% 高轉化率的秘密。

26.6% 的轉化率對于免費增值產品來說是令人難以置信的。正如 Jason Chen 所說“如果說免費用戶到收費用戶的轉化率可以達到 4%，那就已經可以說是很不錯了，比如 DropBox。但是通常來說，轉化率一般都處于 1% 上下浮動，這還是用戶十分活躍的情況下才會達到。”

舉例

我們先從示例應用程序的一些摘錄開始。下面是暴露Person對象的響應信息庫。很類似于傳統的，非響應信息庫，只不過它返回Flux<Person>而傳統的返回List<Person>，以及返回Mono<Person>的地方返回Person。Mono<Void>用作完成標識：指出何時保存被完成。關于Reactor類型的更多信息，請參閱

public interface PersonRepository { Mono<Person> getPerson(int id); Flux<Person> allPeople(); Mono<Void> savePerson(Mono<Person> person);
}

下面是我們如何暴露帶有新的函數式web框架的資源庫：

RouterFunction<?> route = route(GET("/person/{id}"),
    request -> {
        Mono<Person> person = Mono.justOrEmpty(request.pathVariable("id"))
            .map(Integer::valueOf)
            .then(repository::getPerson); return Response.ok().body(fromPublisher(person, Person.class));
    })
    .and(route(GET("/person"),
        request -> {
            Flux<Person> people = repository.allPeople(); return Response.ok().body(fromPublisher(people, Person.class));
    }))
    .and(route(POST("/person"),
    request -> {
        Mono<Person> person = request.body(toMono(Person.class)); return Response.ok().build(repository.savePerson(person));
}));

下面我們要介紹如何運行，比如在Reactor Netty中：

1，首先看他是如何對待問題的

如果只是產品經理或運營提需求他就直接做，那我們認為這是對待問題不夠認真。我們內部有一個處理產品需求的原則，在開始一項設計之前設計師需要評估的是：

1）拋開這個問題的表面，它背后的本質是什么？

2）我做的這個能為用戶和產品帶來什么價值？

3）這個問題的解決方案應該以什么指標來衡量（數據或調研反饋）？

4）做這個問題牽扯到的設計資源和工作量有哪些？

只有當經過這樣一輪Review，我們才能相信設計師能夠合理的對待他遇到的問題和思考如何去開展設計。當然除了對問題的對待方式外，我們還會看設計師主動挖掘問題的能力。比如設計師是否會經常走查產品流程，主動將用戶體驗上的問題或設計細節整理出來，在內部和外部討論并爭取資源改進等。

2，看他是如何思考解決方案的