Li Yishan [ write words ]

今天被自己项目的一句提示文案给绊倒

今早代理商群里突然对活动允许单个用户抢购次数提出疑问,印象中已有大半年没遇到类似反馈了,特别是此次疑问还直接@了我,希望我能对某个关键页面上的一个文本输入框旁边的提示文案做出详细说明。

先说下代理商和项目之间的关系,早前代理商是原部分销售伙伴单独成立公司承包项目销售权的,在上半年参与的几次代理商沟通会中,能了解到代理商希望运营及产品能够帮助其完成与公司约定的销售成绩,但因为种种原因部分反馈未能得到解决。年中周年庆后,代理商制度有逐渐被收拢至公司统一管理的趋势,这若干月下来收到的反馈也没有以往这么频繁。

今早被抛给我的这个问题,是关于商家希望限制买家抢购活动次数的一个设置项目,理想状态下,控制好买家抢购次数能够为商家带来最大化的收益(更多人购买),其次也能够规避第三方平台的监控风险(避免惩罚)。

今年因为三月份的一次市场整体变动,项目现行的商业模式,及同行业的其它大玩家,实际收到的限制是在不断增长中的,由此也多少影响商家在第三方平台的利益。

此次代理商应该是认为某张关键页面上的提示文案,与产品实际运行的规则不一致,而导致商家被第三方平台处理,以至于商家为了规避风险,降低了发布抢购活动的意愿。

对于代理商在群内的请求,我查看了需求管理系统上14年至今的相关调整,并结合线上的提示文案本身作出了解释。未料因此激起一波接一波的抱怨声 —— 我给出的产品解释,在实践中,与之前提到的理想状态恰好是相反的。

由于解释产品设置时的态度较坚定,导致区内疑惑、抱怨、责备和嘲讽的声音没有停息的意思。期间我反复确认了需求文档的描述,以及多次产品需求变更的日志,均无法做出令代理商满意的结果。

直到终于忙出手来,实际也是负责进行答疑的运营同事出来,确认了线上规则,同时我也从开发同事那确认了线上代码的实际运作逻辑,才算是终于解决了问题。

实际线上运作的规则与机制,与理想状态无异。但与代理商和商家一样,我对页面上一句提示文案的理解实际上是有偏差的。当时也同样有代理商反馈认为该提示并不能很好地说明实际规则,同时文末链接跳转至帮助中心的超链接,还居然是错的……

最后以自己为解释错误而道歉,然后确认调整方案来结束了这次沟通。给当天的工作增加了优先更改出错的超链接,同时让运营参考着修订帮助中心文案的工作,以尽可能地避免再次出现同样的情况。

事后重新翻看了需求文档,对自己做了些反省:

  1. 不完全熟悉运营规则,被质疑时临时查阅文档以至于出现理解错误。
  2. 在不了解真实情况下强势答疑,形成了自己不够专业的形象。
  3. 阅读文档有疏漏,实际规则在14年底即确认并执行至今。

在之后的工作会尽力杜绝类似事件发生。特别是在整体外部环境遇冷的情况下,各合作方的神经紧绷,也经不起这样的折腾。

国庆前让开发同事在内网搭建的资料库需要开始补充资料方便随时查阅了。

导游犬小Q体验报告

导游犬小Q是在北京时的同事回武汉后捣鼓的一个项目,4月份的时候同事发来链接说让我点评一下,当时体验了几天,原定在劳动节前搞定的反馈,一直拖到了今天。

现在网上找到的资料分别有来自36kr的一篇去年底的文章,以及仍在保持一定更新频率,但似乎间隔时间较长的 Appstore 页面

从 Appstore 的截图看,将近两个月前更新的版本,与我在4月份时体验的那版并无二致,而与去年36氪报道的则有一定差距。在36氪的报道中,导游犬小Q要做的事情还是依靠项目所在企业数据源优势做“目的地信息选择和决策的智能工具”。但在又过了半年的16年4月份以及将近1年后的现在,导游犬小Q在做的事情已经是结合用户评分,对目的地各类景区、地点进行口碑推荐,根据商店页面的介绍,甚至“聚合携程途牛同程驴妈妈蚂蜂窝旅游攻略”的功能也有在参与(但我疑惑这句话只是为了做ASO而写上去的,毕竟在产品里无丝毫体现)。

一款基于用户标记、标签化描述地点来进行LBS服务的应用,在我看来没有太多令人持续使用的动力。在少数几篇能够查看到的新闻稿件,以及导游犬小Q自己用来做简介的蚂蜂窝、途牛等,在帮助用户生产内容,展示、聚合及推荐内容,还有口碑推荐之外的住宿、旅途票务预订等商业化功能方面,都比导游犬小Q已经做到的功能领先太多。

至于产品功能本身,导游犬小Q自身建立起的一套地方景点分类及类目下具体条目的标签、图片及文本展示等,都完成得中规中矩。UI方面则有不少界面在使用中有生硬的感觉,可以看作是在最低限度标准上实现了比较流畅的业务流程,但未能很好地对产品起到“点亮”作用。交互层面的设置也未有可以单拎出来说道的地方。

作为一款仍在运营中的产品,我对导游犬小Q在与同类产品的竞争中所持有的竞争力表示不大乐观,希望仍在项目当中的老朋友能够在运营与产品研发过程中积攒更多经验,在之后的迭代中让产品产出更多吸引用户的功能与亮点。

以此作为导游犬小Q这款应用的体验报告。

OS X(现在是 macOS 了)使用中

近两个月来项目工作较多,基本没时间写东西。同时也因为前段时间刚在家里切换到了 OS X 环境,稍微有空时都忙着摸索系统和比对软件去了。当然也因如此,攒了不少关于 Mac 软件的使用体会和心得,哪天有时间了能详细说说。

手头正在使用的设备是 14 年底的 Mac mini,听到不少年底这一系列要迎来更新的消息,但实在没忍住 Sketch 等软件的优惠,最终还是 5 月初时入了一台中配加FD的定制机。这几年断续着也使用过一段时间 OS X,整体上手没什么难度,倒是花了不少时间在挑选和对比软件上,动辄三四十刀的软件看着挺美又易用,也还是需要好好考虑一下(这里需要“批评”Sketch,就晚了几天没赶上直涨 30 刀,但眼馋太久,还是第一时间入了,靠谱。)

现在家里和公司的办公环境基本解决了兼容性的问题,因为在家里还没怎么能干活,考虑将服役近 7 年的小黑在年底也换成 rMBP,料想还能将效率提升一些?这些都得搬完砖再去考虑了。

谈 App 的“夜间模式”

最近晚上时常需要外出楼下走两圈,途中不免拿着手机看看新闻,翻翻各订阅源。时间长了发现常用的知乎、Medium 和 Feedly 都分别有了自己的“夜间模式”,切换后界面均变更为深色主题,在昏暗环境下(最开始应该是方便人们躺床上看手机?),观感确实比常规模式来得对眼睛更有好一些。

但同样是“夜间模式”,各款应用之间对于深色主题的处理则是不尽相同。从对眼镜的保护来说,有的应用可能真是在这方面考虑得更多一些,让人用着感觉非常自然。

如某天晚上在转圈途中发的这条豆瓣广播,提到知乎、Feedly 和 Medium,恰好就是在“夜间模式”上做得各有优劣的例子。至于为什么这里把 Feedly 提到了第二位,简单说是因为 Medium 做得实在是令人称赞不起来。

以下应用均为 Android 版。

知乎

知乎的“夜间模式”没有名称,拉出侧栏后,点击“切换主题”就是在明暗两个主题间切换了。

知乎的“夜间模式”没有选用纯黑背景,甚至连黑色都称不上,而是主背景色用了 #36474F,文本颜色则是 #A2AAAD。这个搭配怎么说呢,在晚上只有自然光线的环境下,这个主题色调看得眼睛非常舒服,丝毫没有因为过于光亮而刺激视网膜,并且文本与背景的对比恰到好处,长时间阅读也未见吃力。值得一提的是,知乎在“夜间模式”下对图片也进行了处理,增加了一层灰朦的遮罩,降低了图片亮度的同时也不至于降低内容辨识。将知乎排在第一位,是因为在“夜间模式”下它的阅读体验接近于润物无声的感觉了。

Feedly

Feedly 是我非常喜欢的一款 RSS 阅读器,但因为它的“夜间模式”有些不那么令人满意的细节,于是在晚上外出时我基本不用它进行较长时间的阅读。

正文 #A7A7A7、标题 #B6B6B6、背景 #000000,只看纯文本的 Feedly “夜间模式”,它对暗色主题的处理还是非常不错的。但问题出在图片上。

即便你切换到了“夜间模式”,你在 Feedly 里看到的图片还是常规模式下的过于明亮的模样。这种明暗之间的对比过于强烈,以至于在浏览一篇配图文章时,你将随着手指划拨屏幕而体验明暗快速变化的视觉效果,而最令人无法接受的是,这样的切换对眼镜造成了非常大的困扰,导致我每每尝试阅读一整片文章,却都没办法说服自己去接受、甚至是忽视文章里的图片。

Medium

Medium 是我最近心水的一个写作、发布与阅读平台,上面发布的文章质量非常高(相对于其它类似风格主题站),那么在外面打开它的应用进行阅读也是顺理成章的事情。可是看上去 Medium 根本就没想着把“夜间模式”做得像他们的文章版式那样的优秀。

标题 #C9C9C9 中规中矩,但正文大概是 #EDEDED 则不像那么回事了 —— 这么亮,搭配这样的背景 #000000,令人产生质疑的颜色配置。同时对图片也没有想知乎那样采用暗调处理,与 Feedly 同样存在图片过亮的问题。

另一个人让人意外的是字体。Medium 在正文中采用的衬线字体,在亮调的主题色下显得与平台本身的风格、气息相温和。但在“夜间模式”下,Medium 引以为傲的字体选择立即变成了难以识别的错误范例。我觉得任何人只要有过浏览 Medium “夜间模式”主题的体验,都不会为此进行任何辩护。

就是这样

没有更多内容了,这次同时对三款应用进行了“夜间模式”的切换,获得了与内容带给我的截然不同的“阅读体验”(通常说我的阅读顺序是 Medium > 知乎 > Feedly)。希望优质得更进一步,做得不好的加速迭代,共同为习惯在夜晚昏暗条件下使用 App 的用户带去更好的体验。

404

月中查询项目站点统计数据时,发现 404 页面的访问量飙升,在将问题提交运维排查的同时,发现这张 404 页面自 2013 制作完毕后就没有进行更改。其中大约一半的信息都已经与当前信息不符,包括一级导航这样的重要元素,和页脚联系信息,以及页面文字表述等内容。同时对页面上的引导信息也不是太满意,于是让同事着手提需求进行更改。

项目网站每天固定时间会迎来高峰流量,往往就会高频率出现这张 404 页面。页面上的一句“咻~这个页面已逃往火星……”经过这次事件都已经成为运营和代理商之间的一个梗了。

对这句表述我不是太满意。一没说原因,毕竟“逃”字是有受迫意味的,这里的用法似有不妥;其次没说是否解决,像是说页面出现这样的问题我们也没在担心。虽然实际情况是这个修改需求是我主动提出的,但希望具体负责的同事和我们产品部门能重视类似这样的边缘页面,它们往往在迭代中就被遗忘了。

之后看了下同事提交的需求,跟想象中的理想状态还有差别,还好基础信息都算补全了。考虑看什么时间能完整些考量页面引导,再完全重构页面了。

修改后的页面估计三月三假期前能上线,进度略慢。不过还好经过运维排插,频繁 404 的状况似乎得到了控制。于是这个需求也从紧急更新便曾日常优化了。