微信小程序项目开发总结

1. 微信小程序知识总结和案例分析

微信小程序知识总结和案例分析 1.如何做好微信小程序数据分析

实时统计：即当前在线访问的用户数，包括：。

访问时长（0~30s,30s~60s,1min~3min,3min~5min,5min~10min,10min以上）。 访问页数（1页，2页，3~5页，6~10页，11~20页，20页以上）。

访问地域（全部，自由选择国家，地区组合）。 详细数据（一键生成小程序第一次访问时间，地域，访客类型，入口页面，最后停留页面，访问时长，访问页数）。

累计访问用户数：默认显示的是30天的数据，累计访问次数即小程序自上线到当前的所有访问用户数。 实时访问：访问小程序所有或单个页面的总次数，多个页面之间跳转，同个页面的重复访问计为多次访问（实时数据处理同步可能有15分钟以内的延迟，只统计已发布的线上版本使用数据）。

打开次数：昨日打开小程序总次数，用户从打开小程序到主动关小程序开发多少钱闭小程序或超时退出为一次。 访问次数：昨日访问小程序内所有页面总次数，多个页面之间的跳转，同一页面的重复访问计为多次访问。

访问人数：昨日访问小程序内所有页面的总用户数，同一用户多次访问不重复计。 新访问用户数：首次访问小程序页面的用户数，同一用户多次访问不重复计。

2.微信小程序有哪些商店案例

微信小程序商店很多的，想要找到一家好的商店小程序开发公司不容易，需要注意以下几方面：

第一，看美不美小程序从看到的第一眼到打开页面的整体都得好看。如果第三方公司给你提供的小程序你觉得页面很LOW，不好看一定影响转化率，丑的一定没有转化率。在这个拼颜值的年代，界面美不美观是块敲门砖。

如果你希望自己的小程序装修得非常漂亮，其实需要非常多的模块。如：图片轮播广告、视频播放、语音播放、公告、商品组件、店铺导航、关联链接、商品搜敏稿索等等。这就像积木一样，商家要根据自己品牌调性和商品特点，来个性化自定义自己的店铺。可以提供丰富的店铺模板、装修组件等选择，帮助店铺搭建。

第二、看快不快

如果一个小程序2s钟都没打开，你一定会关掉，没有人会等3s。所以，在正常4G环境下，小程序打开页面必须在2s之内，因为大部分是冲动型购买场景。所以小程序系统的访问速度必须非常快，比如说H5做到1s以内返拿拿，小程序需要做到1.5s以内，如果第三方公司给你做的小程序慢于2s才打开，不建议你选择。

第三、看稳不稳定

小程序如果不稳定，给商家带来的损失是致命的。因为你做到一定程度时，做一次活动，一次群发和一次推广影响到的人群很庞大。当所有人都参与活动的时候，如果一次群发宕机访问不了，你就会失去了一大批用户。判断第三方公司做的小程序系统是不是稳定，你要看一年的稳定时间。

第四、看营销功能多不多

小程序没有关注行为，没有像公众号图文群发的功能。所以，营销功能要足够多，才能实现裂变。根据多年漏搭微商城的经验，比如多人拼团、分销员、好友瓜分券、多网点、限时折扣、优惠券、发券宝、秒杀等，这些都是很好实现裂变传播、推广获客、营销成交、留存复购的营销功能。

3.旅游小程序开发的优秀案例有哪些

小程序种类多，方便快捷，而对于旅游这种范围广，涉及多个产业群的产业可开发的小程序就更多了，包括食住行游娱购等六个主要方面。

旅游电商•在线交易在旅游出行中，包括机票预购、酒店预订、车辆预约以及门票购买等等，都可以在小程序实现。达到了方便快捷。

户外活动•组织报名通过微信小程序发布活动消息，借助微信好友、群聊和公众号分享传播，通过小程序进行活动报名。旅行社•虚拟货架打破门店空间限制，将传统产品手册同步至线上渠道，以虚拟货架的形式，展示门店产品和服务旅游景区•信息发布旅游景区及时高效的信息发布平台，通过小程序介绍景区资源，发布旅游信息，提供游玩攻略，参与游客互动。

旅游出行类小程序目前开发的案例：一家民宿是一个民宿预订平台，功能唯一，但高度专注，提 *** 品齐全，基本满足需求。一家民宿针对人们旅行住宿的需求，整合资源，力图为每一个自助出境游的华人提供住宿帮助，在小程序的开发上，该平台也以实用性作为了标准，携程作为国内OTA的领头羊，在规模上对其他同行保持了绝对的优势，携程也不仅仅再局限于在线旅游代理平台，实用性也远远超过了其它一些提供单一业务的平台，携程小程序同样具备完善的功能，从订酒店订车票车辆预约甚至定制旅游等都出现在首页面，个人中心一目了然，包含了出游每一个环节，提供一站式旅游服务这一直都是携程的主张。

旅游小程序的开发可不止这些主流的开发方向，因为与这些拥有资源和经验优势的大佬们没有可比性，可以尝试从细分垂直领域去开发小程序，旅行小账本就是非常另类的一个小程序，功能定位明确，也是旅途非常有必要的 *** 作，在整个旅游服务环节能包车保持较高的使用频率，一直从游前贯穿到游后，并且还能作为数据留存，是游客产生依赖感。小程序中完全为了游客记账的方便而设计。

以上三种不同类别的小程序开发可为当前旅游业小程序开发提供借鉴思路。

4.案例分析实验总结

相关案例资料，熟悉了我们组的PPT流程。

我们组首先从书本入手查阅相关的资料，进而分析了案例的相关知识、优缺点等等，融合之后进行总结制作PPT。四、实验中遇到问题及解决方法1、不善于对知识点的总结与应用，总结资料能力多少都有些欠缺，经常锻炼这些能力是十分必要的。

2、对信息的处理不到位，考虑分析问题的时候不能做到全面细致，由于思考和理解存在局限性，应该听老师和同学的讲解来解决。3、对案例分析题中所涉及的知识，不能熟练的找出来。

而想到某一些知识点也不能很好的概括并加以分析说明。对有些财务政策比较陌生，以后应该多研读政策原文，理解政策精神。

4、语言表达能力有所欠缺，比较死板缺乏活力，以后要加强这方面的经验，继而有所提高。5、对于PPT的制作很陌生，遇到不少的困难。

再加上对方案进行比较、择优时，考虑得不够全面，分析得不够透彻。经常犯一些不必要的错误。

五、实验结论具体参见同学的【附页】：案例分析报告六、心得体会在我大三的下半学年，我们上了叫“财务管理案例分析”的实验课。短短两周的实验课程竟然是将近两年不见的赖老师给我们授课。

这令我万分的怀念。除了这一惊喜外，赖老师还给我们贮备了另一个惊喜：那就是赖氏特色的教学方式。

以前的实验课老师都是紧紧抓住书本，让我们做书本上的题、计算一类的。但是本次的校内实习，老师让同学们组成小组通过多个不同的案例进行分析，我们分成人数不等的小组，然后进行分工，有的查阅资料，有的制作PPT，有的是陈述人，有的是答辩人。

然后让我们团结协作做成PPT并用类似演讲的形式展示出来，然后又通过问答的环节，让全班同学都积极参与进来。当然回答问题的小组成员也要事前做足了充分的准备。

我们每天都有不同的案例或者一天就多个案例的进行着，除了小组案例分析外还有班级对抗赛、小组自由选择案例分析等等多方面的创新。这不但能熟悉财务管理这门学科中所涉及的知识和问题，让我们掌握了现实当中的多类企业的财务管理中面对的不同问题，这还锻炼了我们的思维思考、语言表达、组织能力等等。

我在小组中做过陈述人、资料查阅、还答辩了一个问题。这不仅加强了我的专业知识掌握度还加强了我的个人综合能力，从而为实际工作打下良好基础。

我们懂得了在案例中涉及教材上的知识点，从而对案例如何进行系统的分析。我们通过互联网进行资料查询，使我们对案例有了进一步的了解，更便于我们对其进行分析总结，并从中进行知识的扩展。

老式教学都是针对课本做计算做题，这无疑于纸上谈兵，在现实工作中，我们对于课本上的理论知识的运用是不太现实的，工作中的不定因素太多，而书本只是把理论性的东西写了出来。赖老师把我们从传统的教学模式中拉了出来，这个新式的教学方法很特别，常常带给我们不一样的全新感受。

这次试验对于我来说最大的收获是综合能力的提高，好比原来搜索资料的时候只知道看原文，从不知道还要标注作者、出版社、出版年限等等，还有就是PPT的使用，之前我很少制作PPT，运用得相当不熟练，制作出来的PPT也没有什么特色而且速度相当缓慢，现在的我对于这种软件有了比较充分的了解，做出来的效果也较之前好了不少速度也有了相应的提高。这对于我今后的工作帮助是很大的。

再一点就是同学之间的协作沟通，因为在之前的学习生活中很少与同学有这种知识的交流，所以也发现了每个人的想法是多么的不同，看问题的角度千奇百怪，这使得可能我找出来的资料，总结制作的同学觉得并没有用处，这也就锻炼了我的沟通能力和协作能力，几个同学也在这种沟通下更加的了解彼此，加深了我们的友谊。特别是我们组的人比较少，只有四个，而且相对于其他小组对于分工有着明确的划分，我们组则是机动性的时刻变化着，每个人都是身兼数职，所以我们就更加团结、更加了解彼此了。

不过对于我本人最大的锻炼则是作为陈述人在讲台上讲述PPT，这对于我来说是很难得的经历，因为我本人对于演讲主持这类的工作是不大热爱的，那么自然也就很陌生，当然这也就使我很紧张。讲解的也就比较生硬相对于其他小组的陈述相比之下就不是很有特色了，不过先不论我讲解的好坏，单单上台去讲这对于我已经是不小的突破了。

这成为我珍贵的经验。做了这么多天的案例分析，自然也就对于这些案例的知识点有了更深一步的认识，这使我的会计知识更加丰富了，理解的也更加透彻了。

还锻炼了我们的思维思考能力、语言表达能力、组织能力等等。要知道个人的综合能力的高低是在职场上获得成功的关键所在。

所以提高综合能力是多么的重要。

        这几天一直在暗中观察同事们对这次"外卖小程序"项目的一些反馈，下面我会站在一个产品经理的角色对以下四个部分进行：用户行为&分析、餐品本身、场景流程、个人建议

前置条件：在用户心理分析有一个专业术语：叫“均匀悬浮注意”，意思是需要像一个旁观者一样在观察者被访对象和观察对象发生了什么，“均匀悬浮注意”一样适用于我们的产品。由于分析不能受到个人主物散态观意愿影响，需要形成较为客观、事实的分析，截止今天为止我并没有下过一次单，也不参与各种吐槽环节。

分析目的：通过多维度分析，找出项目中运营、程序、流程上存在的不足点，提出可行性建议。

一.用户行为及分析

        先引入一句话--“ 一个产品对于用户的意义存在于他对这个产品所罩源产生的反应之中 ”，你也可以理解为--不同的用户对同一个产品会产生不同的反应，产品经理必须通过各种设计手法， 缩短或改良使用者对产品的认知过程 。

        我在南山办公，所以对南山的同事能观察到的行为举止包括有语言、表情、肢体语言、情绪等方面的因素，对于在福田的同事，我只能通过他/她在群里的吐槽进行表象的分析。以下列举出出现较多的场景：

        场景一： A同事抱怨点了餐，在小程序上付了1元，但是却没有拿到他想要的那份餐品，于是另外一个B同事和A解释到可能是在一个测试时间段点的餐，所以数据被忽略了。A同事无法理解，我为什么付了钱却给不了我想要的东西。

        分析：

        A虽然是我的同事，但首先他也是一个用户，作为一个用户，A同事的抱怨理由依据都非常充分。

        B同事也是我的同事，这个时候他扮演的角色是开发，在B看来你在测试时间段点的餐我也有充分的理由不计算到我实际的配送份额内。

        这个场景引出1个问题：制造期望&控制期望 

        1.针对"制造期望/控制期望"这个问题还原场景：A用户打开了小程序，小程序页面展示的是主流点餐页面，此时，在A用户的心理已经产生我可以选择餐品的感知，当A用户点击了下单之后，小程序制造了一个"确认订单"的期望，并且这个期望通过小程序的交互被用户所感知及反馈到大脑中，最后A用户支付了这1块钱，完成一个订单的销售闭环，此时此刻，我们给到A用户的期望---明天中午我能吃到通过小程序下单的那顿"雪菜小黄鱼套餐"。

        2.A用户的期望是在对产品认知的过程当中一步一步的建立起来的，用户会在认知产品的场景当中，一直做着同一个事情---无限接近他所期望结果的 *** 作。

        结论：通过分析可以知道在场景一中我们做到了第一步，通过小程序制造了A用户能吃上饭的期望，但是制造了期望总要去兑现，如何去控制这个期望让它得以实现，需要解决的问题是我们的线上线下运营能力，沟通是否顺畅，如果中间缺失了一环，那么这种情况可能还会出现。

        通过这个结论我提出了一个建议： 特别是在当前程序并非完善的情况下， 沟通变得很有必要 ，打破沟通的屏障才能让整个项目运作更顺畅。其实作为旁观者的我来说，场景一中的根本问题是沟通问题，如果A同事提前知道测试时间段内下单的数据无效，就可以完全避免这个问题。同样，我们也不能要求我们的用户去适应我们带出来的问题，如果A同事这种情况发生在正式上线的情况，这个小程序会从此在A用户的小程序列表里消失，所以在项目运营层面来说，应该增强各个部门之间的沟通，只有内部沟通顺畅了，才能更加容易的切入我们中，实现“控制期望”。

        场景二： 部分同事抱怨点餐截止时间不合理，这里我先不给出截止时间是否合适的结论，还是那句，客观的分析，成型的产品不应该是产品经理个人执念的产物，而是遵循市场规律设计出的产品才是好的产品，否则产品生命周期会提前结束。

        首先来看看某个同事A做的调查，

        A同事：“你觉得掘咐提前点餐，你能接受吗？”

        路人甲：“可以”

        好，到这里为止我认为类似这种引导性问卷已经没有必要往下看了，因为这种问卷是基于引导式的场景提问了，除非这个场景是用户自己提出的，否则基于一个引导性场景做出的调研后面得到的反馈和数据是没有意义的。

        点餐本身是个随机事件(何时在哪个平台点哪个店铺的哪个餐品)，既然是随机事件，那么调研之初就不能用这种直接切入的访谈/提问/问卷去做调研，如果是假设对方会提前点餐的前提下去做调研或者只能二选一，那么你调研的结论应该是和你的商业论证呈现惊人的一致或大概率一致。

        这种随机事件调研最好的办法是观察/数据采集/数据分析，不需要去提问，因为用户的行动是不会说谎的，你只要观察或者用数据得出结论即可，一旦用引导性方式提问，将会影响被受访者的本身意愿/甚至带偏。

        在以前还没有做出外卖小程序之前，我得出南山这边点餐的数据(随机抽样，6个同事包括我自己,每个同事抽取12月的随机6个样本，因为当时大家都不知道年后要做外卖小程序，所以抽样规避了引导性的问题)：

        点餐时间样本：

        1号调研对象：11:03 11:15 11:13 11:10 11:06 11:08

        2号调研对象：11:00  10:58 10:55 11:02 11:03 10:58

        3号调研对象：11:11  11:15  11:08 11:11 11:12  11:07

        4号调研对象：11:22  11:40  09:30 11:08 11:24 11:05

        5号调研对象：11:30  11:35  11:10 11:16 11:10  11:10

        6号调研对象：11:10  10:55  11:12  11:08  10:55  11:20

        从抽样数据来看，用户点餐时间最早时间09:30 ，最晚时间11:40，排除掉拐点3个方差范围外的离散点(09:30)，得出结论，点餐高峰期和前期做外卖小哥接头采访(参考2020-03-05发布的《取餐柜调研分析》案例二第13条，如下图)的结论惊人相似，再把外卖小哥调研的12:30时间往前推40分钟(配送时间)，得出结论，点餐高峰期是11:00-11:40，这个时间段也符合我们以上6个抽样调查结果的结论。

        到这里为止，我们可以看到，用户的习惯点餐时间在11:00-11:40，和我们设置的点餐截止时间不吻合。

        再看看我们是否可以通过我们的产品设计控制来达到改变用户习惯的效果，下面继续分析。

        首先，得知道用户习惯从何地/从何时而来，这里直接给出答案

         1.用户习惯，在最初的需求解决方式中形成

         2.用户习惯，在新的需求解决方式中展现

         3.用户习惯，在新的需求解决方式中改变

         然后回头看看，我们的这个项目是否满足以上三条，不着急，一条一条来分析。

         在最初的需求中，外卖平台的上线是用来解决用户维度里面的“懒-贪-装”中的 “懒” (参考我《直播/视频行业分析》一文中所提到)

         自此之后，外卖平台的上线已经解决了核心问题--- 如何将远距离的餐品直接送到用户手中 ，之后外卖平台核心的需求没有改变，那么就没办法满足以上第2、第3条。再回过头看看，核心的需求已经被美团、饿了么等各大平台占领了，那么用户习惯就已经被这两大巨头培养起来了，如果这时候我们需要通过我们产品设计来培养用户新的用户习惯会 出现两种结果 ：

        1.用户被层层的规则限制，呈现出漏斗形过滤，用户在每层漏斗中被筛选转化(可以参考电商的转换模型)， 最终到达支付闭环的用户占比很少 ，这里指的规则包括所有和现在主流平台不一致的业务。

        

        2.假设用户习惯被培养起来了，但是出现的复购概率不高。引用美团的数据，一个用户点同一家店的频率为3次/月，这意味着，大概一个星期会吃一次这个店的餐品。

        然后这里举一个场景的例子：用户A平时使用美团/饿了么外卖点餐，习惯点餐时间一直保持在11:00-11:40，然后突然有一天，用户想起来要吃我们《塘食》的外卖，结果点进去发现此时已超过点餐时间，无法点今天的餐(因为我们的点餐截止时间不在当天11:00-11:40之内)，此时用户只有两种选择，第一，点击右上角关闭小程序，第二，出现这种情况的时候，我们的小程序本身针对这种情况是有提示用户可以去浏览每周的其他餐品，于是用户就点了进入“每周餐品”的页面进行浏览，再之后的 *** 作无法确定也无法控制。很显然，以上两种 *** 作都对我们小程序很不利( 用户流失 )，因为我们没法控制用户在这种情况下会产生哪种情绪，会对小程序进行哪些 *** 作，那换然之会进入到支付步骤的用户数更不能明确，如果我们有足够时间做埋点，可以大胆猜测这个数据会很惨淡。

         那么回归我们的“外卖小程序”场景当中，我们解决了用户什么需求？ 核心需求还是没有改变 ，远距离餐品送到用户手中，那么我们的餐品是定点进行领取，那么我们的目标用户就限定了在取餐点的短距离范围之内，如果一个餐品需要一个用户走很远的距离去取，那么这个和最初的需求所冲突，所以产品也会自动排除掉了一部分用户

          总结了以上分析得出以下结论：

           1. 假设用户距离我们取餐点太远，那么没有解决核心需求，远距离的用户直接会被过滤掉 。

           2. 没有新的核心需求在市场上出现，培养用户习惯会导致用户被层层筛选

           3. 小程序现有规则大概率影响到我们用户的复购率

        到此，对于场景二的分析也完毕，得出的结论也比较残酷，虽然这只是我们自己公司的内测阶段，但在产品经理的这个岗位里有一句话“产品如果连自己都不能感动，又怎么能感动市场呢？”换言之，只有当我们自己用都觉得用得很舒服的时候，才有可能获得市场的认同。

         针对场景二以上得出的结论，提出个人的一些建议：

         1.基于我们的取餐点附近进行重点的推广，比如南山可以推广赛西周边的几栋写字楼，距离远的用户很难驱动。

         2.我们的点餐截止时间可以设置在11:00左右，根据数据分析得出结论，用户提早点餐或在11点前点餐概率很低，因为这个本身是个随机事件，在用户眼里，我什么时候点餐-点哪家的餐-点哪个餐品需要三个步骤，我们不能认为用户都会点塘食的基础上做假设。

         3.优化一些点餐的流程，从业务流程上优化，比如缩短用户可感知的产品的路径(比如如何能获取到我喜欢的餐品在哪一天会出现)，会复购的用户一般都是我们的忠实用户，所以我们应该更重视这部分用户的使用。

二、餐品本身

        核心竞争力是产品 ，在我们这个项目当中，指的就是我们的餐品，下面列举2个关于餐品的实际场景进行分析

        场景一： 我一直在观察着是否有部分同事不会点小程序的餐，想验证下这部分同事具有怎样的共性，结果我发现有三个同事是不点的(当然在利招下发通知必须点后，我可以认为这是外部环境因素而对产品数据结果造成影响，不过没关系，我还有前三天的数据可以做分析)。

        A同事，看到餐品从楼下被领上去，会好奇凑上去看餐品的卖相，没表达任何不满或者嫌弃的意思，但没有点餐

        B同事，被其他同事问及为啥不点的时候，直接来了句“这看上去一点都不辣”

        C同事，我还是比较喜欢重口味的，这个我吃不下

        结论： 以上就是三位不同的同事，他们具有的共性就是对餐品本身不感兴趣，我们主推的是江浙菜，那么必定会有一部分的用户不是目标群体，这部分用户在小程序浏览的餐品时候已经被过滤掉，自然不会产生订单，那么针对我们的餐品，我们是否需要做调整，如果不做调整我们该如何在运营上如何快速定位我们的目标用户呢？继续往下分析

        建议：         

         如果我们需要做调整？ 那么我们可能只有一种可能，就是通过市场调研，了解我们目标区域内用户的主流菜系，对应做出调整。

        如果我们不调整？ 那么我们需要让我们自己的产品被标签化，让用户更容易感知我们主推的菜系，那么会在具有相同属性的用户群体当中进行裂变，而且产品的标签化是产品运营中必不可少的因素，显然在小程序当中，用户并不能通过快速浏览我们的主页获得这层信息，如果我们能在产品当中给用户打下某个烙印，第一，有助于用户快速识别我们到底是做什么菜系的，第二，我们可以把更多精力集中到我们这部分用户的反馈当中，无需花时间、成本、精力去照顾我们的非目标用户。

        场景二： 然后我们看看那些点了餐的同事的真实反映，这种反映包括语言、表情、肢体语言，我认为这些是最真实的体现，而在群里发表的意见并不一定是用户本身的真实意愿，所以在南山的同事我只考量这些客官因素

        A同事，(猪脚饭)，味道不错，就是分量少了点(还是笑着在评价)

        B同事，这个饭分量太少了，吃不饱(带有抱怨的语气)

        C同事，这个价格如果有优惠还行，外面的话就不是这个量了

        D同事，这条鱼也太小了吧(脸上略有不满）

        这些同事都很充分的角色代入了，没有因为是公司餐品而掩饰不满，非常好，我需要这种客观反馈

        结论: 对小范围内抽样调研，如果出现反馈具有很多同一属性的问题，那么这个问题如果投放到市场，会被无限放大，直指餐品存在一个问题：量少

        建议： 对于多少，每个人评判标准不一，到底是多是少，需要量化，前期如果无法使用一些高额成本的量化工具，可以用某些固定容器作为参考标准进行量化生产，然后收集反馈，继续优化，再收集反馈，达到一个较为理想且大部分用户都能接受的一个量，然后通过这个量倒推成本，再对产品定价进行修改，希望定价方面要经过计算，不要靠感觉，这样以后万一定价出现问题，也容易追查到哪个评估的环节出了问题。 餐品是我们的核心竞争力， 价值需要由用户来评判，我们首先给到的是优质的餐品，再去想别的事情(身边已有较多这种案例，哪怕是网吧楼下卖炒粉的，核心竞争力是这个炒粉是否满足广大用户的口味)

三、场景流程

        对于用户来说，大概的场景是这样的：

        1.某时刻我在小程序上点了某一天的某一个餐品

        2.在某时刻我看到路边有人在做外卖推广，于是我扫码尝试去点个餐

        我们只需要针对这两个场景去做分析就好了，复购/朋友圈/搜索的这部分用户符合第一个情况，拉新/递推符合第二种情况，基本上不存在第三种。

        对于第一种，自己不做分析，自己分析自己的设计存在主观因素，当局者很迷，只能对提出的问题作出解答，为什么这样设计之类的问题，至于好不好不分析。

        针对第二种，市场部在策划跟进，在这当中我也从市场部的得到了比如说易拉宝、产品外观设计这块的一些资料，但是具体如何推广的流程还没有具体获知，下面我举一些例子，通过市面上较为成功的案例倒推我们现在存在的一些问题

        案例一：

        下面是一个电饭煲(俯视图)

        

            这个画面需要表达的是三个事情，第一，我可以控制温度，第二，我可以控制时间，第三，如果你想提起来，我还有个把手，至于怎么调整温度、时间，怎么拎起把手无需我做过多的说明。

            分析： 反问一句，你是如何从画面中感知这些要素的，为什么你在调整温度时，会顺其自然顺时针去扭动，其实这个是用户心理模型当中的感知造成的，这里不深究，简言用一句，就是最简单的设计表达用户可感知的事情，所有多余不是核心的元素只会让用户在认知层面出现感知困难，比如我以前提过最好不要用d幕形式做背景一样，视觉信息量大，变相没重点，用户潜意识会产生一种这个背景没有一个中心思想去表达，人的心里都是这样的，越复杂的事情越抗拒去看。

            结论： 现在处于拉新阶段，无需把太多元素暴露给用户，先让自身产品打上一个“最硬核、最简洁”的标签(包括视觉、solgan、公司logo等)，易于形成品牌记忆，举几个简单的例子，一句话搓中用户的，梅赛德斯--"The best or nothing "，携程--"携程在手，想走就走"，碧桂园--"给你一个五星级的家"，产品需要不断更新迭代，我们只需要一个亮点，让用户铭记于心就好。

四、个人建议

        我们每天都会想到很多好玩的东西，每天可能都会发现市场上存在的空缺及机会，在商言商，我们有好的想法，就要想办法落地，落地需要更多的观察市场、分析市场、揣摩市场，站在产品岗--我需要站在一个较为客观的维度去给大家分析项目，时间宝贵，避免少走弯路，前期的调研分析必不可少，只有分析透彻了，才能做出顺应市场的产品。

最近一直在做小程序，工作中也遇到了一些问题，踩了一些坑，所以想着写篇文章记录下来，并借此将小程序开发的相关知识进行梳理，方便以后参考，也为刚刚接触小程序的人提供一些思路方法，互相学习，共同进步。

1、微信小程序的目录结构及配置说明

app.json是小程序的全局配置文件，所有配置项key必须使用 双引号括起来 ，value值为字符串类型的也必须使用双引号， 不支持单引号 。

1.1 pages

pages选项是必须配置的。该配启孙置项注册了小程序所有页面的地址，其中每一项都是页面的 路径+文件名 。每一个页面都是由.json、.js、.wxml、.wxss四个文件组成，并且 四个文件的名字必须要一致 。

1.2   tabBar

tabBar 配置项指定 tab 栏的表现，以及 tab 切换时显示的对应页面。其中 list 接受一个数组，只能配置最少 2 个、最多 5 个 tab

1.3 usingComponents

使用自定义组件或者插件提供的组件前，必须先在这里声明

2、开发微信小程序遇到的问题及解决办法

2.1 双向绑定

微信小程序不支持通过v-model的方式实现自动双向绑定，需要给表单元素通过绑定事件，并使用this.setData来赋值实现。

2.2 computed和watch

微信小程序默认是不支持computed和watch的，如需要使用这两项功能，需要安装miniprogram-computed ，安装方法见 官方文档

2.3 对象赋值

如果给对象的属性赋值，可以使用this.setData({'obj.key':value})来赋值，但是如果给某个团含属性名是变量的属性赋值，通过这种方法是会报错的，经过多次尝试，发现使用如下的方式赋值成功。

let newObj = `obj.${key}`

this.setData({

[newObj]: value

})

2.4 scroll-view

当页面存在d框容器，并且d框里的内容是需要滚动条滚动展示时，如果d框下面那层的容器使用view元素的话，会导致滚动d框内容时，同时会触发d框下面那层的页面容器也会一起滚动，解决此问题可以将d框下面的容器使用scroll-view元素替代view元素

3、小程序测试和发布

由于服务器域名request合法域名每个月 只能修改5次 ，因此在本地开发小程序时，需要在微信调试工具中设置不校验合法域名。等小程序上线前再一次性将所有域名添加到小程序管理后台。

以上便是此次小程序开发中积累的一些经验，希望能给刚刚接触小程序的人提供一些思路方法，悄或链在以后的开发中，如果遇到新的问题，继续更新文档......

---