系统设计平台

广州系统界面设计别样设计认为：女性朋友作为消费市场的主力军，一直在带动电商平台的发展。女人到底有多败家，你永远不会知道，正是因为女人恐怖的消费能力，有聪明的商家瞄准了这一市场，做起了女性购物电商平台的生意。

目前市场上的女性垂直电商平台比较火爆的APP都有一个共同点，那就是图标及界面主色调均为粉红色，从这一点不难看出，做一款女性购物电商平台还是需要技巧的。其次，女性购物电商平台业务内容比较繁杂，以往使用手工管理效率低下，信息堆积给公司带来很大不便，设计一套专业的后台管理系统，能够有效解决用户网站建设与信息发布中常见的的问题和需求，对网站内容管理是该系统的最大优势。

在下面的这款电商平台后台管理系统中，设计师采用了富有女性化的玫红为主题色，辅助色选用同类色，体现女性柔美、时尚的界面风格。导航栏加入少量灰色和亮色搭配，让单调的界面增添活力。功能模块区、列表区均以数据为主，弱化多余视觉，强调数据。年季销售额报表分析是采用的K线图，直观地了解整体的销售额具体变化情况。

BS构架数据网站数据种类繁多，采用卡片式设计可以很好地对每一类信息进行优化呈现，让用户能更容易接收不同的信息，而不会产生混乱感，目的都是化繁为简，让信息清晰直接。将数据类型进行分类再按重要程度进行相应排版，最终的目的是为了给用户带来便利，让他们在处理数据的时候一目了然。

商品列表页也是以卡片式展示的，目的也是为了使界面数据清晰，让用户快速了解商品搜索、库存等信息。除此之外，还有点击头像修改管理员信息的功能。整体的设计给人一种舒服的感觉，使用起来会很方便。

从上面的案例中，我们可以知道，在设计过程中，需要不断思考什么交互方式才是适合用户操作的，连界面颜色也要考虑用户心理。无论是做什么设计，只要从用户角度出发，就能找到方向。

由广州UI设计别样设计原创，原文地址：uibieyang，转摘请保留版权，谢谢。

目前市场主流的电商管理ERP软件，如管易、网店管家，大部分采用的是C/S(客户机和服务器)结构，凡是订购软件服务的网店客户，只要通过客户端就能完成对主流电商平台进行统一管理。对于没有软件研发实力的店铺卖家来说，使用现成的电商管理软件，可以大大节约成本，提高工作效率。但是，从数据安全角度来说，使用第三方软件，客户隐私信息被更多的暴露出来。这也是近期天猫要求所有第三方服务商完成数据存储加密升级的原因。

改造前电商ERP软件情况

在开发自己的电商管理综合平台前，我们使用的是离职员工开发的一套电商业务管理软件，软件是采用delphi语言开发，系统结构也是采用C/S模式，

系统分为后台订单下载服务和前台店铺订单管理两个部分。后台订单下载服务是部署在聚石塔内，负责处理天猫、C店、京东等平台订单。

我们部署了瑞友天翼，实现在聚石塔内部署客户端程序，本地可远程访问客户程序，完成订单审核、订单查询等操作。老系统采用通过TCP端口读取远程服务器数据，完成订单打印、称重、扫描等操作。

因为我们并没有这套软件的开发源码，即使有源码，也没有了解delphi语言，更谈不上在其上进行开发了。我们在后期又增加了部分外围的电商平台，如唯品会、当当网、拍拍网、工行融易购、建行等等。我们还是使用之前的这套软件，重新在公司局域网部署了一套系统，专门维护这几个外网平台的订单。

这样，在系统改造前，我们是在维护两套一样的系统，客服同样也是同时使用两套系统，非常麻烦，影响工作效率。这也是我们要改造现有电商管理软件的主要原因。

重新设计电商管理综合平台

1. 系统采用新的开发语言—— C#；

2. 电商管理综合平台系统通讯架构采用.NET Remoting通过TCP端口从本地激活远程对象，访问远程数据；

3. 系统分为独立的订单下载服务和电商业务管理客户端组成；

电商业务管理客户端系统功能图

系统架构图

系统架构说明

1. 系统平台：Windows Server+IIS+SQLSERVER

2. 开发语言：；

3. 服务器：VM+RDS；

4. 系统架构：采用C/S三层架构；

5. 客户端为自开发Windows应用程序，用于用户交互；

6. VM内订单抓单服务将访问淘宝API或者RDS订单推送库，完成淘宝订单抓取至RDS商家业务库；

7. 应用层采用采用.NET Remoting通过TCP端口来与客户端交互，并进行业务逻辑处理。

数十万互联网从业者的共同关注！作者： 王悠悠悠。作者授权早读课发表，转载请联系作者。简书地址：http://jianshu/p/088de40cb100编辑：Dva用户系统是很多产品最基础的构成之一，但是越是基础越是开源设计想要完善也更难。在设计用户系统的时候，首先想到的关键词是注册和登录。但并不是有这两者就足够了，更加完善用户系统本身还需要考虑：多平台账号打通，同平台账号之间绑定与解绑，账号安全等及需要怎样的前端设计才是满足这个产品本身定位和用户操作的设计。用户系统的实现简单来说有两种方式：1、自己构建用户系统；2、用第三方授权。第三方授权获得的用户信息有限且受制于人，而自己构建用户系统研发及用户使用成本均不如第三方授权。所以更多的是两者并存，相互补充。由于工作需要从0到1设计一个用户系统，本人不是强技术型产品，所以在定义服务端字段或需求有不完善和不专业的地方，希望大家多提意见，共同完善。一、总结需求1. 用户系统基本注册／登录功能及前端页面设计2.多平台账号打通，即在单一app注册的用户，能够使用此账号登陆系统内所有app3.用户相对独立，对于单一app来说用户身份唯一二、前端设计登陆注册主流设计有三种（原型如下）

1.  账号密码优先账号密码优先是最常见的一种登录注册设计，适用于普遍场景，鼓励用户用注册方式登录，有利于产品引导用户完善更多的资料，留存自己的用户信息。例如知乎是以账号密码登录为最优先，且会隐藏第三方授权登录。现在的账号密码登录都会以用户注册方式代替系统生成的userid作为账号。纯账号密码登录是较为早期的设计，例如早期qq和飞信。2. 手机号快捷登陆优先手机号快捷登陆，也叫免密登录／短信验证码登录，适用于用户不登录能够完成大部分行为，只有在某种场景下必须获得用户身份时才需要用户登录，且此时用户的想要完成的行为是被要求登录操作打断的。常见的如团购类产品，用户在应用内进行了商品的浏览、筛选、添加到购物车，当要进行最后一步付款操作时，发现未登录。这时繁琐的注册或者登录都有可能导致这笔订单甚至这个用户的流失。所以这时获取用户身份的方式一定要尽可能便捷。3. 第三方授权登陆优先第三方授权登陆，适用于对用户资料和权限要求不高快速解约开发成本的产品。建议在应用构建用户系统的前期可以首先接入第三方，快速的实现登录功能。但是若想建设自身关系链还是需要完善自己的用户系统。用户资料实际也属于用户系统等设计的内容。是否要增加此项的判断原则是根据这个产品对用户资料的需求程度决定用户注册时是否要增加资料填写页，资料填写页是强制阻断性的还是可跳过的，必填的资料项有哪些，希望填的有哪些。例如是需要关系链的那么注册的时候就应该强制用户去填写资料设置必要的昵称和头像，这样的用户对于此类应用来说才属于有效用户，不然在app内用户点进资料页，全是系统自动生成的垃圾信息，对于建设关系链和留存伤害较大。交互细节上又可以延伸用户进行注册或登录需要几个步骤？这些步骤是在一个页面上承载还是一步一个页面以多页面去承载？单一页面承载的优势是用户能够有很清楚的预期，他完成注册需要进行哪些操作，但是劣势是一个页面承载过多信息显得杂乱，操作的次序也会不明确；多页面承载的劣势是用户对完成注册的具体行为没有完整预期，更容易跳出，优势是页面整洁并且路径单一，能引导用户完全按照通畅的预设路径进行。我个人更推荐后者，因为用户预期可以用页码／步骤管理用户预期。下面是我根据我们产品的定位和需求设计的用户登录／注册系统原型：如上所说，我设计的用户系统是需要承载多产品的，所以我设计融合账号密码登录和手机号快捷登录两种方式，以用户出发需要登录的场景去切换展现在用户面前的是哪一种。

补充一些贴心的小点：申请读取本机号码权限，并帮用户填写申请读写短信权限，获取到验证码后自动填写并点击下一步应该前置到提醒：上次登录方式，合法的手机号，正确的图形验证码等等三、服务端设计很多产品，特别是没有技术背景的产品不会去接触和设计服务端需求。实际上我自己日常工作中接触服务端需求也并不多，并不是说产品要负责设计一个完善的用户系统服务端，而是要学会以服务端同事能懂的方式表达清楚自己的诉求，两边对功能的实现不会有太多的偏差，这是产品设计服务端端目的所在。简单的用户系统服务端的基本功能需求为：判断账号身份（注册/未注册），账号身份生成（新用户分配id），账号密码验证；这里要设计的并不满足于注册登录，需要考虑多平台账号打通的用户系统并且要和在打通情况下单一平台或多个平台之间，用户的多个账号之间绑定于解绑。现在先说一下多平台账号打通需要考虑哪些问题：用户系统身份的创建，因为我们是多平台的系统，所以用户身份只能纳入手机号注册的用户，若第三方授权注册的也算用户系统用户，在账号绑定的那一关则会出现混乱；实现多平台账号打通，要实现多平台账号打通，即所有接入多平台都能够查询到此用户身份；平台间用户身份独立，要实现平台间用户身份独立，则需要在用户系统用户身份的基础上创建一个平台的用户身份；

(一) 用户系统多平台打通名词解释1)Appid：接入用户系统时首先分配，用于区别接入的各个app；2)Unionid：用户手机注册时，由用户系统根据手机号创建，在用户系统作为用户唯一身份标识；3)Appuserid：用户注册时，由app服务端根据union或者第三方授权的openid创建，在app内作为用户唯一的身份标识；基本原则1)手机号作为用户系统账号的注册的唯一途径，根据手机号在用户系统服务端创建并保存unionid；app服务端根据unionid创建并保存appuserid，且将unionid对应保存；2)用户系统同一unionid可对应不同的appuserid3)使用第三方openid授权的注册用户不计入用户系统仅存在app服务端作为单app用户，即unioid为空只生成appuserid；第三方授权包括微博微信，QQ，Facebook，Twitter1. 主线流程图

手机号注册主流程为：用户注册时，用户系统服务端需要验证手机号＋验证码是否为真，此手机号是否已有对应unionid；若有提示已注册，请登录；若无创建对应unionid，app服务端根据unionid创建appuserid。至此成功生成了用户系统身份及当前app用户身份。手机号登陆主流程为：用户登录时，用户系统服务的验证手机号＋密码是否为真，此手机号是否有对应unionid，若有，则说明此用户有用户系统身份。还需要app服务端需要查询是否有对应的appuserid，若有说明此用户有此app身份，直接用其appuserid登录；若无则说明是用户系统内其他联合app注册用户根据unionid创建此app的用户身份，至此登录成功。用户系统是大多数app都会有多构成，单一的用户系统也并不那么复杂，但是若要构建产品矩阵进行多平台间的用户打通，加上帐号绑定与解绑，并不是一时半会能够想清楚的需求，若大家感兴趣为会继续补充帐号绑定和账号安全产品应该关心和设计的事情。谢谢：）