我们将努力把 Taro IDE 打造为企业级的移动端建站平台，无论用户是开发，产品，设计还是运营，身怀何种技艺，都可以通过 Taro IDE 搭建出美观实用的多端应用。
1.项目背景
Taro诞生于凹凸实验室开发哥哥数不清的日日夜夜里，它来到这个世界上的原因，是因为开发哥哥们遇到的在不同终端上的开发任务，例如小程序、快应用、H5等。Taro作为一个技术框架，可以无需编码或者通过小量代码就快速生成应用程序，将原本的数月甚至数年的开发时间成倍的缩短，为企业大大节省了人力和时间成本。某年某月的某一天，Taro作为免费开源代码框架在GitHub上的面世，迅速突破2万星（据说只有3个团队能做到），成为同类框架的第一，大大的解放了前端哥哥们的生产力。
一句话总结来说是，将一份代码编译成多端代码，一次性满足八个终端的要求。
我们还针对JDC内部研发的一些能力进行整合，做出一个生产设计和代码的机器，让不懂代码的非开发人员也可以自行开发，为他们提供一站式的解决方案。在长时间的积累下，JDC已经沉淀了许多能力，这些能力像积木，我们可以将这些零碎的积木构筑成一个完整的生态。把这些无形的技术资产，结合合理的使用场景，实现变现的能力。
将商城中台建设的夸克组件库、玲珑智能平台灵活地镶嵌在Taro中，用户可以通过图形化的拖拽以及组件背后的数据接口连接起来，由于背后是标准化、稳定的组件连接，所以有效的规避了代码本身的BUG问题。能将原本是产品、设计、开发、测试的工作量，聚集成产品一人的工作，节省了成倍的人力成本、时间成本和沟通成本。
项目亮点
一、将技术转化为产品，增大应用面
然而，这终究是一份代码，对专业性要求太高了，为了将我们沉淀的服务能力开放出去，让更多专业和非专业用户也赶上这波红利，我们将Taro开源框架和组件、模板等能力重塑成一个完整、成熟的企业级多端建站工具应用，它已经会自己写代码了！
二、释放中台的技术沉淀，赋能业务
京东一直在建筑技术中台，目的是有更加灵活的应变能力，将数据、技术、设计等接口都梳理好，输送出一套整洁、标准化的接口，高效、低成本地完成业务应用开发和迭代。Taro IDE能有效地利用这些能力，释放出巨大的中台能量，打出一套组合拳，推动业务前进。
三、解放生产力，提高业务产能
Taro IDE将通过编写一套代码编译成多套代码，成倍缩减开发时间；同时，对于运营人员而言通过图形化的拖拽方式，后台生成代码，更好地进行业务扩张。
2.设计分析
2.1 制定设计目标
在完全吃透本次需求后，我们针对内部资源进行整合，为建成一个成熟的B端研发类产品，设定了以下3个设计目标：
2.2 竞品探索与设备调研—-制定项目的尺寸大小，框架
由于Taro IDE是“第一个多端编译研发工具”没有相关竞品参考，我们选取了上面上一些工具类的产品参考，再结合开发的使用场景，分析这些工具设计的依据，获得一些启发。
首先，我们是规定窗体的尺寸大小，寻找最适合的大小。根据调研公司的电脑尺寸和市面上市场占有量最多的电脑尺寸，和调研了工具型应用的尺寸，最后我们选定了两种尺寸大小：1000618和1174650。比对两个尺寸在不同分辨率的大小和操作空间的比率，综合开发哥哥在使用Taro IDE的具体使用场景，IDE会调取编辑器等工具进行一个来回切换，敲定了1000*618的大小尺寸。
原因如下：1.更加符合开发的使用场景；2.窗体占屏幕比率太大容易撑太满造成压抑感；3.1000*618正是黄金比例最舒服的大小。
2.3 信息架构重构
将IDE基本功能罗列，以及后续的规划安排，我们以最完美的整体目标出发，尽可能构造出最稳定的整体架构，并规范了后续增加功能的位置定义，保持TaroIDE在以后迭代都过程中能够灵活应变日益增长的需求。
2.4 将架构转化为布局
在制定整体框架方向的阶段，我们一开始很保守的使用了侧边导航栏的框架，然而在设计进一步验证的过程中，隐隐地觉得有点不对劲，于是，我们停下来，对开发的使用场景进行深入的研究，自己推翻了自己之前的设想。
通过调研研发哥哥的工作流程和使用习惯，梳理了当用户使用Taro IDE时的场景。发现整个研发流程是不可逆的，它是一条链条，每一个环节环环相扣。所以我们制定了一个策略，围绕项目为中心，每一个环节进行场景化的引导。针对侧边导航和顶部导航的方案，我们做了两个方向尝试，并分析他们的底层逻辑。
最后我们从侧边导航的方案优化成顶部导航的方案，从使用场景分析，有以下几点原因：
- 不可逆的链条式开发流程，更适合场景化引导；
- 顶部导航比侧边导航的方案更有效、空间更大、轻负担；
侧边导航栏的入口分散，用户可以在项目中创建、也可以在物料中进入创建，它给了项目开启了两扇门，没有给用户一个更加聚焦的解决方案；
而顶部导航的方案只给项目一个入口，把项目列表页作为整个产品的逻辑基点，当开始了项目后，其他功能就会收起来，让所有操作都会集中在一个逻辑链中，只在场景中提供用户需要的功能，而不是分流。
从产品属性和用户群体分析：
- 高效的B端产品。B端的产品有下面的一些特征：效率、权限、数据传递。也B端应用，目标是高效、为用户提供解决方案，提高企业运作效率，实现自己的业务价值。而“逛”的场景更多一点的侧边导航方案相比以“做”为核心的头部导航方案，明显更不高效。
- 目标导向型用户群体。研发人员为主要用户群体的Taro,他们的述求也更聚焦，就是要来编译，然后跑通整个研发流程。因为是目标导向型用户，聚焦和“链对链”的顶部导航明显是最优解。
2.5 流程拆分—模式转换的尝试
Taro 有两种模式，开发者和运营者，更加抽象的归纳是专业用户和非专业用户。为了抽象出最高效、最整合的方案，我们建立了两个交互模型，从全局分析整个流程的岔点。模式变化是前置还是后置？
模式后置的模型看起来很顺畅没啥大毛病，而且功能整合，不用重复造轮子，大大节省了开发的时间。这个方案的特点是两种用 户用的是同一种模式，只是在项目编辑是给专业用户更多的权限，有更多高级功能。这个方案的好处是不用重复开发，但是更加明显的劣势是，1.物料中心完全”非开发者“化，物料中心完全服务于非专业用户了，我们开发者也需要物料中心；2.共用项目详情，然而因为要妥协专业用户和非专业用户，界面的变化会在模式切换后变得不伦不类，都不讨好。
同时因为是垂直用户群体，不同用户角色，关注点不一样。B端开发协助工具，流程更加固化，所以功能和流程的设计需要更加接近心理模型。想要更加好用，整合未必是最好的方式。分角色模块来思考用户所接受的信息量和业务逻辑量，不同用户对功能模块的理解是有不同的壁垒的。
模式选择前置的模型从一开始就分不同的角色模式，是更加贴近用户本身心理模型的。从根本上来看，我们要追求整合的目标，模式前置的方式明显是更加“整”的。在中间的分叉点上，不同的用户角色的述求和关注点是不一致的。这样就需要我们在相似的框架上求同存异，满足各自的需求。
3.设计输出
3.1 项目详情页设计
- 以任务为导向，步骤式引导
我们将现有内测版本进行了分析，发现现有版本是入口平铺型的，用核心功能编译的功能为例，开发者和非开发者都会使用这一功能，直接将功能展出，站在非开发者的视角去看，是很令人费解的，用户的理解成本也很高。于是我们分析了这一功能使用的场景，对场景进行拆分，然后逐步引导，不至于“一口吃成胖子”。
在视觉设计方面，我们对taro进行了重新的品牌升级，重新定义了logo设计和品牌色。
- 视觉重心突出
根据内容优先级重新将项目详情页做了设计。在内容的优先级上，我们突出了亮点功能—多端平台编译，由突出的各端平台品牌色在整洁、轻盈的界面上突出，让视觉重心一下子就能被用户捕抓。
（优化前）
（优化后）
- 图形化表达，情感感知
将原有的入口平铺，状态不可见的编译卡片，重新区分了状态。在常态、未下载状态、编译完成显示二维码用三种视觉形式区分开来。并减少原有编译卡片的纯文字、入口式的形式向以品牌色、图形化的识别方式转变。
3.2 项目列表页设计
- 工具型应用，突出数据图表与动态变化
B端产品特征之一，就是关于数据的处理。首先，我们需要给这些数据定性，这是属于哪一种类型的数据，谁比较关注？这些数据能传达出什么？能给用户、企业带来更多产能的提升？以及我们应该如何传达。下面就以项目列表页为例。
内测版IDE项目列表页单个列表主要包含信息是：项目名称、路径、删除、置顶和在编辑器打开。我们将信息进行了重组，概括为管理型（名称、路径）、操作型（制定、删除、在编辑器打开），这些信息没有系统地进行分类，显得列表的内容杂乱无章。除此之外，我们还增加了关键流程的节点数据，能给用户在列表页就得到深层数据信息和项目节点然后点击直接进入改节点，重新设计后信息归类为：管理型、操作型、入口型。将列表型信息展现，使用卡片式展现，将操作性（置顶、排序、删除）用交互拖拽的方式实现。
（优化前）
- 信息分层，视觉整合
视觉设计中，将这三类信息很好地归类，将卡片分成两部分，上层为管理型信息、下层为入口型信息。将节点数据的变化用不同颜色突出，令用户在繁杂的信息中迅速捕捉。将导航的视觉元素减轻，让视觉焦点转移到项目卡片中。
（优化后）
4.B端研发类产品经验小结
- 全面了解，勤思多问
一开始接手这个项目的时候，由于本着“不打扰”的原则，我是有点闭门造车的，有很多功能点例如什么依赖管理、腾讯云OSS、如何编译、配置有什么用…诸如这些专业性太高的功能没弄懂什么意思，就自己私下上网查。做一个研发类的产品，就必须对整个开发流程都了解，假想自己就是一个开发人员。对于在知识盲区的功能更是要认真了解，细致询问，考虑多种情况并将所有结果做细致的记录，确保自己的理解和功能是没有偏差的。
- 多重身份切换，整合视角提供一致体验
对于B端研发类产品，主要用户群体为研发，但是作为企业协作效率工具，还会有产品经理、运营的角色介入。专业群体、非专业群体和设计师的视角会在理解上会有不同的见解。这就需要设计师在设计的时候，先分角色考虑，在整合的时候做权衡设计，为求以一致的视角使用产品。
5.阶段成果与未来展望
作为设计师的我们在这次合作中，真的感谢开发哥哥们给了很大的发挥空间给我们，很尊重我们的意见，让我们可以最大程度发挥自己岗位的专业性。这本来就是研发跟设计之间最和谐的相处方式嘛，大家都本着把产品做好的初心，互相帮助，互相成就。
最后是我们对Taro IDE的期望，B端产品最极致的价值，不仅仅能简单地提高企业的效率，我们还期望在不久的将来，可以为企业提供更加精确的预测和服务，最终指引业务的发展，甚至能改变整个行业的格局。希望Taro越来越好。
- 开发者感言
终于！耗时将近半年，Taro IDE项目的第一阶段的工作已经接近尾声。
在这一阶段，我们的任务是让开发者的开发体验更加敏捷高效。顺畅自然的本地开发体验、丰富的物料资源、便利直观的测试功能、快速便捷的发布能力，再到全自动的监控体系，详尽的数据查看界面，通过 Taro IDE，我们将不同的的平台、工具、服务进行了整合。从项目创建到上线，再到获取数据反馈，开发者都可以在 Taro IDE 中一站式完成。
- 开发成果
- 未来展望
未来，Taro IDE 不仅仅是开发者的工具。我们将努力把 Taro IDE 打造为企业级的移动端建站平台，无论用户是开发，产品，设计还是运营，身怀何种技艺，都可以通过 Taro IDE 搭建出美观实用的多端应用。为此，Taro IDE 需要进一步完善功能，包括完整的页面搭建能力、项目运营数据查看能力，还需要有更多的物料补充。
Taro IDE即将上线，敬请期待！
若有收获，就点个赞吧
0 人点赞
