谈及帐号及权限的问题,更多人一开始会直接想起的是登入注册的交互感受及安全性,但对于B2B电商平台来说,会遇见更多的场景,对于功能的要求也比较注重。本文主要从B2B电商的视角,讲述帐号及权限设计的问题,以及我所踩过的这些坑。

  一、账号机制

  B2B电商平台的交易角色由采购商,供应商跟平台三方构成。

  在项目早期,由于产品未参与数据库设计的过程,所以数据库设计者更多的是借助已知的需求及经验进行数据库的设计,采购商的帐号方面主要是由两个表组成:账号表跟采购商信息表;账号与采购商信息之间的关系为1:n的关系。

  但是随着项目的上线及推广,该套帐户机制被证明不能满足业务部委的需求。在我们其实的认知中,一个采购商(即一个企业)作为一个订购单位,如果有多个人负责采购的状况下,多个帐号共享一个采购商的信息即可。但是之后我们的采购商出现的连锁店,而且连锁店处于采购费用跟管理的诱因,更多的是由专门的采购人员或老总进行统一的采购,因此帐户与采购商的关系弄成了n:n的关系

  因此衍生出如下几个问题:

  1. 数据库的设计

  根据需求一个采购商可能会存在多个采购人员,同一个采购或许还要同时负责多家店的采购,因而帐户跟采购商的关系变为多对多的关系;

  实际上因为前期设计错误,导致再次进行数据库的设计不再或许,只能基于之前的数据结构进行更改,这里我们将原先的一对多关系的两个表整体看做一个采购商表,新增一个帐户表跟一个关系表即可完成设计

  另外,其他业务模块对于账户/采购商的引用还要进行再次的检测,在业务逻辑上,一个采购实体的性质是采购商而不是账户。所以跟采购业务相关的业务模块如:订单、优惠券、文章消息、购物车商品等均与采购商id关联,而与账户相关的业务还要与账户Id关联(与新的帐户表中的id关联),如:昵称、登录帐号、密码等。

  2. 业务步骤设计

  由于多个帐号共用一个采购商,在有职员辞职或其他状况下,必须对于采购商的某个帐号进行关系的解绑,所以应当有一个账户才能管理该企业的其他帐号。所以对于直接争创新企业的账户,将这个账户赋于一定的权限,将其定义为管理员账户。

  对于非管理员账户,可以由管理员账户直接添加,这样可以省去注册的麻烦也可适于批量注册帐号。同时业务设计中也须要考虑登陆同一个账户后,在多个采购商之间进行切换使用的问题。

  (1)新增帐户并绑定企业

  注册新帐号以后,可以直接继续争创新的企业,创建新企业后,该账户将手动成为企业的管理员。同时也可直接步入页面浏览以后,再争创新的企业。另外,也可直接由企业管理员添加踏入该企业(有点类似于社交中群成员跟群主的概念)。

  (2)老帐户绑定企业

  已注册的帐号,可以选择争创新企业或由管理员添加步入已存在的企业。

  经验教训小结:在需求的早期,一定得做好需求的逻辑模型的设计,梳理其中的角色(实体),属性及实体之间的关系typecho注册用户权限,以供数据库设计人员进行化学模型的设计,否则在后期会耗费更多的费用进行更改。

  二、权限设计

  现在市面上大多数电商网站对于权限的设计已日趋建立,尤其是在商品浏览方面,登录与不登陆没有哪些差别,甚至在下单支付环节大多数电商网站早已可以做到不用登陆即可下单,这方面不做过多说明

  但是在to B端的电商网站中,由于对于不同地区,不同用户等级的采购商来说,看到的售价是不一样的。甚至有些电商网站为了保证自家商品的隐私性(是否有该商品,商品的售价是否有优势),在不登陆的状况下都不可以浏览商品。另外对于不同的行业,to B端的电商上的采购商应当递交相应的资质给平台进行初审能够进行采购。

  因此,to B端的电商网站还要在用户的感受跟业务需求上进行一些考量,什么状况下能浏览?什么状况下能看到售价?什么状况下能进行下单支付?

  在我们前期的系统设计中,索性直接一刀切,用户打开APP直接步入登陆页面,在未登入且关联采购商资质初审通过前不能进行踏入商城主页面。但随着业务的发展,在APP的推广过程中,如果用户看不到商城的商品,采购商不太乐意注册一个不了解的产品。

  因为这后边牵涉资质的初审,需要填写企业资料、上传护照,会比较麻烦,所以这些矛盾显得越来越激烈。因此,在后期我们对于用户的权限进行的再次的调整。

  权限设计逻辑如下:

  根据登陆状态跟采购商状态,将权限分为以下几层:

  未登入帐号的权限;已登陆帐号,但未绑定采购商的权限;已登陆帐号且已绑定采购商,但是采购商未初审通过;已登陆帐号且已绑定采购商,采购商资质初审已通过。

  对于不同的权限等级,将页面内容根据不同权限等级进行归类:

  不需登陆即可见到的内容,主要是商品列表中的商品,注册相关页面等;需登陆并且不需要采购商信息的内容,如:账号名,昵称等;需要登入且还要采购商信息,但采购商为未初审通过的状态所见到的内容;需要登入且还要帐户信息能够看见的内容,如:商品售价,购物车等。

  按照以上逻辑对于权限进行界定以后,就可对各个页面进行整体的设计了。在我们的实际开发过程中,由于之前是只有已登陆且关联采购商初审通过才可步入商城主页面。所以若还要对权限逻辑进行重新设计,那么各个页面调阅插口的逻辑应当更改(这部份地方值得深入探讨)。

  所以最后我们对于未登陆,采购商资质未初审通过权限牵涉的相关页面重新设计了一套(页面的复制粘贴,调取独立的插口),但那样的好处是后续有一部分页面的更改迭代都应当同时改两处地方,而且页面的感受也会损失巨大一部分。

  经验教训小结:由于上面直接在登陆页面进行一刀切,在后期对权限逻辑进行调整的时侯,导致牵涉的东西很多而不敢直接在已有的基础上进行更改。所以我们在做权限构架设计的时侯,就算当时的需求是这么要求的,也须要考虑后续需求更改的拓展性。

  三、前端展示页面相关设计登陆注册步骤:与C端的电商的登入注册模块不同,除了帐号的申请此外需要考虑采购商企业资料的递交(也提供跳出路程的出口)。账号的管理:上文说到的每位采购商的管理员还要管理子账户,所以提供添加子账户的页面(不存在的子账户则直接先生成一条帐户信息),并可将该帐户从采购商中删掉。创建新采购商:提供两条路径:一个是在注册时,一并完成新采购商的争创typecho注册用户权限,一个是登陆后,专门提供一个入口争创新采购商。切换所属的企业:采购商可以切换当前所属的企业,以方面单独为每位企业进行采购。

  本文由 @不桡 原创公布于人人都是产品总监。未经许可,禁止转载

  题图来自Unsplash,基于CC0合同

  给作者打赏,鼓励TA抓紧创作!

  赞赏

  5人打赏

Last modification:December 26th, 2020 at 06:02 am
如果觉得我的文章对你有用,请随意赞赏