如何定义牛逼工程师

有软件工程方面的研究说，对于开发者个体而言，最优秀的开发者的生产效率约为平均值的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，看他是如何思考解决方案的