Ⅰ web端及移动端原型设计规范
第一次绘制原型图的时候觉得主要功能表达清晰即可，尺寸大小、元件间距全凭感觉，因此一开始也挨了不少骂。后来慢慢摸索出规律，大概总结如下：
端口类型：
目前长需设计的端口分为：web段（即网页）、移动端（APP、小程序等移动设备）、IPAD（IPAD是一种移动设备，但也有自己特定的尺寸），智能设备（例如智能电视、智能手表等等）
由于我更多接触的是网页端已经小程序端口，后面会以这两个为主。
网页端：
目前市面上显示器屏幕尺寸为19-21寸，屏幕分辨率大概在1280px*800px—1440px*900px之间，前端工程师在写页面的时候，宽度一般设为1180px—1220px（当然，这个宽度也不是绝对固定的）。
因此在做产品设计的时候，设计web端产品，宽度会设为1400px作为容器，位于容器上方再画一个1200px的矩形，内容区域的容器。（PS：内容区域的矩形需与底部容器左右间隔10px，作为留白）
可能有人会问，为什么要底部容器上面划出一块内容区域？
首先，我们要知道， 容器决定产品的边界 ：
我的理解是：
按照市面上显示器的分辨率，前端页面可展示的内容区域，平均宽度在1200px，预留出来的空白部分，是为显示器较大的人群考虑的：屏幕越大，可展示的区域也越大，超过产品本身内容可展示区域的话，会自动留白。
另一方面，为保证开发团队的成员可查看完整的原型图，我们需考虑下他们电脑屏幕的分辨率可能为1280*800px。
稍稍总结下，就是跟随大多数人的屏幕尺寸大小，以及方便开发团队查看。
给大家看我电脑上查看大的原型图大小，是不是很清晰的看到内容呢？当然，这也是我个人的看法，如果有别的看法的，可以互相交流交流 （我算是个野路子的产品） 。
至于高度的问题，这个是没有要求的，一般都是根据需要展示的内容来决定的，也就是高度自适应。
讲完容器的宽度，接下来讲讲字体。正常情况下，字体大小都是14px，最小字体12px（字体太小可能就不方便查看）。
字体上，我所在的企业并没有太多要求，只要求能看懂主要功能就行，所以上面的字体是来自一位B站的up总结的。
移动端：
说明之前，给大家感受下刚入门时候，画的线框图，话不多说，先上图。
（OS：简直惨不忍睹，当然这并不是给开发的图纸，而是草稿。由于各种问题，我需要兼顾产品跟UI设计，所以都是输入高保真原型图的）
虽然最终效果跟第一版草稿的差距特别大，但这样让我知道原型尺寸的重要性。但凡在自己随手画的容器上觉得觉得间距大小差不多了，可以了。有这样的想法，那你离被开发揍一顿就不远了。
以自己一开始的惨痛经历说了这么多，接下来聊一聊移动端的设计规范。
常见的移动端多是手机，基本上整个手机都是屏幕既是容器也是内容可视区。常用字体14px，最小字体一般是12px（你懂的，手机屏幕小，字体太小用户也很难看清的）
上图是我个人画线框图的习惯，并不是标准，只是提供个参考给大家。各个区域的底色，也只是为了便于自己区分，实际上底色并没有什么特别多的要求。至于字体，一般都是使用14px的字体。
产品在原型设计上还是有很多规范的，只不过我就职的企业并没有太多要求，但基本也算通用了，具体情况还是看看自己企业内部有没有什么特别的要求。
上述的设计规范仅限于个人习惯，也是非常基础的部分。如果有别的见解也可以一起分享。像容器内，各类原件的一些规范，后续也会慢慢整理出来。
Ⅱ 绘制线框原型图的10个要点，做与不做
线框图是设计过程中的第一步，也是整个设计流程中最重要的步骤之一。线框图是你想法开始成形的时候。尽管线框图看起来很简单，但也可以做得很好或很差。相框图的好坏可能对最终产品产生重大影响。下面将介绍正确的与错误的线框图。这些技巧可以帮助打造更好的Web和移动端体验。
线框图是用户界面布局的基本框架。线框图使用使用占位符，而不是使用真实的界面元素。线框图被用于早期阶段设计和开发过程中，验证信息架构和用户流程。
相框图有助于确定移动端程序或网站的界面功能与视觉框架，所以说线框图是设计产品过程中的关键步骤。线框图还可以作为产品文档，指导设计师快速搭建移动端程序或网站。
设计师如何充分利用线框图，以及应该注意什么？
如果想绘制好的线框图，你必须研究用户需要什么和他们想要什么。考虑两个重要的目标：业务目标和用户目标。这两个目标对产品是否成功起着至关重要的作用。线框框架之前的研究将帮助您设定明确的期望，即您想要使用线框图实现的目标。
绘制线框图与设计其它步骤的主要区别是要简单、快速。其中速度尤为重要。你需要快速的用线框图尝试很多不同的方案，在为问题提出适当的解决方案之前。线框图尽可能的保持简单是至关重要的，因为这可以帮助你避免分心，并且可以清晰地传达你的想法。
在绘制线框图框架时，要尽可能多地提出方案。一般而言，提出的设计方案越多，就会越有机会朝最佳解决方案进行迭代。如果能够在一个想法上产生多种想法和变化，可以让您看到每个想法的优点和缺点。
线框图可以说是项目前期的一种沟通工具，它可以帮助其他人理解你的想法。当你与其他童鞋对接时，请确保任何人都可以轻松的看懂并使用线框图。如果只有一个人能够理解你的线框，这么说，你的线框图就是不ok的。
a.向一个与你的项目无关的人展示你的线框，并向他提出一些关于工作的问题。这将有助于你理配汪解应该做些什么来提高理解力。
b.为你的线框图进行注释，使其更易于阅读和理解。阅读某些元素或交互的描述要比过看静态图像来理解事情要容易得多。
切勿单独思考。当你与其他人一起集思广益时，能收获更多及培神仔更好的解决方案。在设计过程的早期应该多向团队成员展示线框图，这有助瞎扮于验证和改进你的想法。
团队成员的反馈有助于您改善方案 - 听取其他成员对你的设计的看法，根据反馈进行重复性修改。
例如：我们电子商务网站的产品中，有结账页面，这与许多其他网站类似的。如果你觉得因为一样可以选择不绘制产品这个部门的线框图，而是专注于应用程序中不太明显的部分。其实这样会导致你遗漏交互内容，影响用户体验。所以请避免这样的误区，确保应用程序的每个部分都有线框图。
当你准备绘制线框图时，直接使用你最喜欢的电脑软件工具绘制，这看来是没有什么问题的。虽然像 Mockplus 这样的现代原型开发工具可以在几分钟内创建出功能完整的原型，但在最好先用笔和纸勾勒出你的想法，然后才使用电脑软件。
你有没有想过为什么线框经常以灰度创建？灰色防止颜色对你造成的分心，帮助你快速完成绘制。线框图的主要目的是搭建用户界面内容并描述应用程序的功能。添加多种颜色可能会导致分心，因此最好避免在线框中使用颜色（除非要突出显示某些特定元素）。
不要过分关注线框的外观。线框不是最终设计稿。它们不需要看起来感觉像成最终产品。请记住，线框图是一种工具，帮助了解界面中视觉或交互设计元素的层次结构。当你过分关注美观度，你可能会绘制特别精美的线框图，但可能不会产出真正的解决方案。因此，绘制线框图要努力让它们能用，可以轻松传达你的想法。视觉和交互设计应留在产品设计过程的后期阶段。
不要依附于你的个人想法。可能你很难放弃一些你花费了很多时间的某些东西上（特别是当结果本身并不坏时，但却不符合你设计的产品概念）。但重要的是，线框图被绘制出来前。你需要尝试很多不同的选择（可能10种、50种、甚至100种方案），然后选择最适合问题的一个（或两个）方案。
绘制线框图是用户体验设计师的基本技能。时间就是一颗良药，任何技能都可以慢慢熟练掌握。同样熟练掌握绘制线框图技巧的关键也在于练习。你做得越多，你就会越好。因此，你平时需要投资更多的时间在相框图上，这样在下一次个项目开始时，可以节省大量时间。
原文链接：https://medium.com/mockplus/10-dos-and-don-ts-of-wireframing-8a6d0b3429d8
Ⅲ 想问问有没有一种产品经理 是直接先让ui出设计稿 自己再照着设计稿出原型的
那么问题来了：为什么许多垂涎产品岗位的人，会第一个注意到界面的美丑呢？原因很简单：因为人类都是视觉动物，这是学习成本最低，且不需要深入了解其他东西就能说出个一二三的技能。既然刚入行，就要画图的命运改变不了，那么我们就要想着如何把他画出来，并且画好。
接到需求后，如何将他变成原型图？
这是很实际的问题。比较“笨”的人（其实在说自己）。在听到一个需求后就会立即画图，不知道有多少菜鸟会这样，可能聪明的人会更多吧。
为什么说这样做很笨？因为大部分情况下，你“听”到的需求都不是详细的具体的可执行的。在从产品经理或总监那边获得需求之后，以为自己理解了就开始动手画了，往往画好之后会推翻的可能性很高。不知道你是不是这样，我将这样的行为，称为“臆想”。
反思一下，站在需求或业务方，对于有价值的信息你收集了吗？你有跟需求方深入谈论这个需求了吗？真正了解他想要做什么？他想要达到什么效果？什么功能？哪些是他能想出来的规则、流程、逻辑？
收集完了信息，整理一下思绪，思考一下，他这样做合理吗？不合理的部分，你能想到更好的解决方案吗？如果有，你又该如何有理有据的说服别人？那么，整理好自己的思路，再去和需求方碰，直到敲定结果。
当你将需求基本明确后，请召集项目干系人，一起坐下来聊一聊？聊什么？一是告知干系人我们要做这样一件事情了？二是让各个职能的人了解一下具体的需求，是否可执行？
因为每个人站在的角度不同，所处的观察点就会不同，这时候不妨听取一下大家的意见，适当修改需求。但切记：可以砍的往往是边边角角不妨碍主流程的东西；有些产品喜欢紧握用户体验的金牌，这样做有时候会适得其反。如果产品在初期时，体验可以退居其次，让功能跑通才是重点。
这种算需求评审会吧，是种考验情商的东西。你需要说服大家，如果某个点需要调整，不会提高开发成本，那么你可以坚持一下；前提是你需要有站的住脚的理由。如果反之，就大度的放弃吧。
如果这一切的很顺利，需求、流程、规则都确定下来后，就开始动脑思考原型了。看过许多交互书，会做焦点小组，访谈，调查，可用性测试等等，说实话，不知道你们公司有吗？反正我这里没有。。
那怎么办？那就划船不用桨喽~业务流程、操作流程、功能模块都搞出来，再画图，画图的话，我会先看很多同类或有类似功能的产品，看看这样的形式是否适合用到我们的产品上，能否进行改良或是有无改进的空间。
接下来思考什么呢？简单的说就是，你的产品核心是什么？这样设计有没有突出你要突出的东西，有没有让用户的使用效率提升，用起来很“友好”。这些交互的文章，有很多，大家肯定平时也没少看啦。
要不要画高保真的原型图？
这个问题靠实践才真正获得真理，不过各个公司的状态可能有不同。
原型图是干嘛的？原型图是一种表达你想法的工具，它让你的想法图像化。那图像化给谁看？这个就决定了原型图是否要高保真。给投资人，需要。给技术，不是特别需求。给UI，你需要，尤其是经验不足的UI。给什么人看，决定了你要达到什么目的，有时候原型图只需要表述清楚，有时候原型图，需要传达给你下游你想表达的东西，哪里是重点，突出什么，想要如何引导用户使用和查看等等，这时候就要高保真起来。
再说一个类似的东西就是PRD，PRD是干嘛的，就是一种评判产品的标准，他不是特别能推进产品进度的东西，却是一种呈堂证供和历史存档，有时候我会将PRD与图形化的界面合并起来一起提交给下游。
不过如果我说以上都是扯淡呢，很多情况下高保真低保真PRD都冇用，最后都要靠嘴与勤快的双腿，文档什么的都不管事，多沟通，来避免信息上的不对称。
那么如何让原型看起来高保真起来？
见过有的画原型真是厉害，跟真的APP一样，我比较推崇一半一半吧。有些美观度，但一些特效交互我就偷懒了；这些就用嘴，网上的案例或是文字描述吧。
第一次画原型的时候，画的奇丑无比，这里就不贴出来吓人了。总结起来，如果想要提高你的画原型图水准，下面给几你几个方法，真的只是方法论，更多的还需要你不断的练习。
比例
布局
大小
关联
颜色
先说比例，无论是网络还是现实生活中，我们看起来很和谐的东西都是比例很好的东西，在做原型图的时候也是一样。如果你画的尺寸与真实网页相差无几的话，对一般的观者来说就有很好的效果；而且对于你的下游UI，也能在很快的时间，了解你的意图，不需要在为你调整比例。我只做过两次网页版的设计，经验寥寥，不过我在画WEB端的时候，会先确定整体页面的宽度是1200PX，还是1000PX；确定宽度后登录/注册的状态栏的高度，导航的高度等等；比例这东西渗透到整个原型制作的每个细节。
最后是颜色，颜色一样可以达到突出重点的目的，但是控制颜色也是件技术活儿， 控制不当就会“花”。比如上图，本来设计的时候在“服务地址”的地方，我是突出了“更改”；但是在与技术和接口方沟通后发现更改城市会改变价格，那么就给用户一些提示吧~突出一下，尽量弱化更改，避免用户做这个操作，所以我就用颜色来加重了提示。
基本上按照上面的思路去思考，就能画出能看到的过去的原型图了。但是经过UI的加工后，你才会发现：原型图果然还是原型图。人就是这样不容易满足，而且我们也确实不应该满足，当一个画图人。
那么该如何慢慢摆脱“画图人”的头衔
我很喜欢一个理论叫“用户体验五要素”；这个方法论很厉害，能让你在任何问答与思考中保持一个逻辑思路清晰的状态。
他包括以下五个层次：
战略层
网站的范围基本上是由网站的战略层（strategy）所决定的。这些战略不仅仅包括了经营者想从网站得到什么，还包括了用户想从网站得到什么。就我们的网上书店的例子而言，一些战略目标是显而易见的：用户想要买书，我们想要卖出它们。另一些目标可能并不是那么容易说清楚的。
范围层
结构层确定网站各种特性和功能的最合适的组合方式，而这些特性和功能就构成了网站的范围层（scope）。有些卖书的网站提供了一个功能，使用户可以保存之前的邮寄地址，这样他们可以再次使用它。这个功能——或任何一个功能——是否应该成为网站的功能之一，就属于范围层要解决的问题。
结构层
与框架层相比更抽象的是结构层（structure），框架则是结构的具体表达方式。框架层确定了我们的结账页面上交互元素的位置；而结构层则用来设计用户如何到达某个页面，并且在他们做完事情之后能去什么地方。框架层定义了导航条上各项的排列方式，允许用户可以浏览书籍的不同类别；结构层则确定哪些类别应该出现在那里。
框架层
在表现层之下是网站的框架层（skeleton）：按钮、表格、照片和文本区域的位置。框架层用于优化设计布局，以达到这些元素的最大效果和效率——使你在需要的时候，能记得标识并找到购物车的按钮。
表现层
在表现层（surface），你看到的是一系列的网页，有图片和文字组成。一些图片是可以点击的，从而执行某种功能。例如把你带到购物车里去。一些图片就只是图片，比如一本书的封面或网站自己的标志。
当他人让你介绍产品时你可以这么思考；当你在思考一款新产品时你可以这么思考；当你在做产品规划时候请思考一下。等等等等。。真的很厉害，大家可以经常拿出来做做练习。其实产品经理在“产品”方面的造诣，就是不断的深入这几个要素！越是深入产品的功力越的强，有表入里，层层递进。
Ⅳ 推荐下几款web原型设计工具，介绍下其各自的优缺点.
我们公司目前在用的是Axure RP Pro 6.5，这应该也是主流吧；我是测试人员，原型不是我设计，所以不好说优缺点
Ⅳ 如何进行web页面原型图设计
最后半天心不在焉拖拖拽拽把各个部分都搭建好了，可是做出来的页面惨不忍睹，自己都没勇气打开。晚上回家后和邻居又讨论了三个小时，最后熬夜把原型图完成。虽然最后原型图也没有被采纳，但是这次原型图居然受到了表扬，领导说我的原型图有了提升。今天就写下这篇文章，为这段时间的工作做一个总结。原型设计前：①�0�2�0�2 重点突出内容：要清楚明了页面需要突出的内容是什么，这个在前期的讨论中一般就已经确定；②�0�2�0�2 第一功能目的：除了内容以外，功能方面需要突出的是什么？如引导注册或像下一级页面引导流量。③�0�2�0�2 如果是改版要考虑改版要解决的问题是什么？对于前一版页面存在什么问题 画原型图要考虑：④�0�2�0�2 内容板块如何划分，页面的内容主要分成几个模块，每个模块内存放的都应该是一些相近的内容；⑤�0�2�0�2 模块与模块之间的关联性：每个模块与其相近的模块之间应该有一些逻辑上的关联性，而不能随意的进行拼接；⑥�0�2�0�2 页面的流程：模块与模块的上下承接关系，模块与模块应该上下存在某些逻辑上的连接性。 页面完成后：完成原型图后一定要进行检查，主要从以下三个方面进行检查：⑦�0�2�0�2 内容是否完整：对比框架中的每一部分内容检查是否完整；⑧�0�2�0�2 第一屏是否把最重要的内容展现出来：页面第一屏以外的内容基本都是辅助内容，如果不能在第一屏就把内容全部展现，基本上就等于内容不完整；⑨�0�2�0�2 功能是否实现：想要表达的功能是否在明显的地方表现出来；⑩�0�2�0�2 流程是否顺畅：把相应的流程走一遍，看是否流畅。 注意tips：①�0�2�0�2 未完成的作品拿出来讨论页面不完整不代表思想不完整，即使是不完整的页面，里面应该也要有一个清晰的逻辑图。通过这种方法可以强迫自己想明白再下手。②�0�2�0�2 理清自己的思路要有属于自己的清晰思路，对内容、功能和流程自己要先想明白，可以列举一些具体的问题来辅助理清自己的思路。③�0�2�0�2 坚持自己的想法每一个人都有自己的想法，只要你理清自己的思路，就一定要坚持下去。用自己的逻辑解答别人的疑惑和质疑，形成自己的思路。 关于工具和作图：之前花了很多时间去研究axure，是学会了一些作图的技巧，可是渐渐发现这些对页面的提高基本不大，我是觉得在掌握基本的工具使用时可以暂时忽略工具。页面最重要的是你的想法，等到想法成熟之后不妨慢慢的考虑工具的深入，太多的考虑技巧方面的问题反而会模糊视线。思考的过程和画图的时间可以在7:3都无所谓，前期的框架和流程思路想好后，后面的原型图也就水到渠成了。
Ⅵ AXURE原型需要做到什么程度
AXURE做原型分为低保真、高保真两种，再复杂就是有交互效果的原型。
低保真就是只有线框图。 纯粹的只用线框来表示功能，没有做任何的渲染。 这种低保真我认为适合在公司内部最初梳理功能、流程，并且不需要想客户演示时候使用。
高保真原型。 下面我认为都是高保真原型。 前面的只是简单的很白色渲染，后面是用真正的图片渲染。 这两种可以根据客户类型和项目时间来决定出那种。 前面好处是更接近真实效果，而且不影响美工视觉，出的速度很快。 后面的对美工影响很大。很可能会完全照做。
还有一种就是可以交互的。比如你输入用户名和号码后，点击登录会跳转到首页。只是数据是静态数据。这种原型做出来要花很长时间。但却是搜集客户需求，避免开发成本的最好原型。因为是可以交互的，最大程度还原产品。 另外原型就是拿来不断修改的，并不是做了一次就定下。之所以做原型就是开前确定需求功能，避免因客户需求变动返工。
高保真的原型图的用途有几大方面：
一、开发人员需要参与高保真原型图的设计当中，同时，他需要对这款产品的交付期作一个判断，而产品经理根据开发人员的判断，对于整个产品的周期做一个监控;
二、高保真原型图还需要给你的总监以及老板看，让你的管理层知道真实的产品的样子;
三、用于产品原型测试，把你的产品创意真正的传递到用户眼前。相对于写在纸上的产品设计文档，产品原型更加有效，因为这可以让所有的测试人员以及用户知道你的产品创意所在。 在制作产品高保真原型的时候，你需要密切的与产品交互设计师进行合作，以将产品设计的尽量的简单和易用。产品经理与交互设计师最好能在同一处的办公室办公，因为这样能方便对于产品的交流。
在有些公司，产品的交互设计以及产品高保真原型通常也由产品经理来完成。高保真原型的制作涉及的东西更多，不仅仅只是核心功能的设计，有时候一个按钮是设计和文字的描述就很要命。相信很多产品经理都设计过一些按钮，如果一个按钮既要表达状态也要表达操作，那么这类的按钮是十分费神的。
高保真原型的制作软件目前较为流行的是AXURE，这款软件设计绝大多数的交互内容。并且使用起来也十分方便。笔者也十分喜欢。在完成高保真原型图后，你需要做的就是，可用性测试，也就是确定你的设计方案能满足用户一看就懂的基本需求。
原型的测试有很多方式，如果某些产品已经拥有自己的用户群，可以直接在用户群当中进行测试，如果你的产品没有，那么简单点，公司的同事就是你的测试用户。在公司中，找出你的目标用户，用你的高保真原型图让她们用用。
制作一个高保真原型图很耗时间的。但是用户测试也是必须的，在产品还没有进入开发前做用户测试会让你的产品后续的逻辑更加清晰。无论是客户端产品还是web端的产品，能用高保真原型做用户的可行性测试最好还是用原型进行一次的测试。
Ⅶ 一个小程序的后台是web端
小程序
第一个web项目-微信小程序后端开发
第一个web项目-微信小程序后端开发
前言
需求分析
团队分工
总体设计
开发工具及编码实现
小程序前端
后端
数据库
接口代码
管理系统前端1.0
管理系统前端2.0
测试
后端本地测试
前后端联合测试
部署
总结
第一个web项目-微信小程序后端开发
前言
去年暑假一个偶然的机会我和几位同学加入了学院一位老师主持的教改项目，需求是开发一个基于SPOC与翻转课堂的计算机组成原理课程的学习app（类似慕课、知到），后来经过讨论决定降低难度，先做一个微信小程序，附带一个后台管理系统，于是我的第一个web项目就开始了~
需求分析
这里简单介绍下SPOC和翻转课堂的意思
翻转课堂
“翻转课堂”（Flipping Classroom）是一种颠覆传统教学由“课堂授课听讲 + 课后作业练习”转变为“课前自主学习 + 课堂协作探究”的新型教学模式。
SPOC
SPOC（Small Private Online Course）一般被译为小规模限制性在线课程或者小规模私有型网络课程，音译为“私播课”。
这次项目的需求是开发一个学习类型的小程序，用户分为学生和教师，其中学生可以观看视频、课件、动画，完成作业、考试以及发布评论、点赞、回复，而教师可以上传教学视频、课件、动画和发布作业、考试、通知，以及查看学生的学习情况，也可以查看评论回复，及时解答学生的疑惑。
团队分工
团队一共有四个人，总体工作分为产品设计、前端开发、后端开发三部分，然后每部分由两人负责。其中我是负责后端开发的，同时兼任项目负责人（其实也没有听上去那么高大上，只是需要承担更多决策、协调、沟通的角色）。
总体设计
这里分为小程序和管理系统
首先是小程序，放几张使用墨刀制作的原型图，这里多说两句，市面上的小程序基本都是微信授权直接登录，最多绑定手机号，我们这个由于要统计学生的学习情况才设置了注册和登录功能
至于管理系统，由于是10月份才开始做的，而且是我和另一位做后端的同学负责的，时间比较紧，我们作为前端小白没有十分系统的方法去做开发，只是大概确定了需要做哪些模块，每个模块对哪些表的增删改查，这里原型图就不放了（较简陋）
开发工具及编码实现
小程序前端
据我了解，做前端的同学先去微信公众平台注册账号，然后做一些开发设置，具体步骤自行网络。前端用的是微信开发者工具，有不会的基本上在微信开放文档都可以找到，包括许多实用的API。
后端
这里分为数据库、接口代码两部分
数据库
用的是mysql数据库，之前是跟着学堂在线的一个小程序入门教程做的，它推荐的本地开发环境是phpstudy，里面集成了php、mysql、apache、FTP、Nginx以及数据库管理工具phpMyAdmin，关于phpMyAdmin使用请看https://blog.csdn.net/u012767761/article/details/78238487
原本的数据库设计得不好，存在较多冗余数据，后来学习了数据库系统这门课，我进行了大改，先确定有哪些实体以及实体之间的联系，然后画er图，最后再建模，通过外码约束大量减少了冗余，也减少了表的数量。
接口代码
教程使用的是php语言，框架是thinkphp5，开发手册看https://www.kancloud.cn/manual/thinkphp5/118003，我当时是去b站找视频学了下php基础语法，然后就去学原生php以及框架如何操作数据库。然后根据业务逻辑开始编码，其实每个接口（或者叫类里面的一个函数）结构都差不多，主要是三部分：接收前端传来的数据、增/删/改/查、返回结果给前端。
顺便说下代码编辑用的是sublime text3，教程看https://blog.csdn.net/sam976/article/details/75333079/，这个不是ide，没有那么多的功能比如调试、运行，单纯是只有编辑、加注释、格式化等等，这里吐槽下自带的格式化代码功能（先选择代码，再Edit -> Line -> Reindent），有点辣鸡。而且如果有语法错误不会像eclipse那样自动检测出来，之前被坑了几次，肉眼找不到的话只能用postman去测试了。
管理系统前端1.0
一开始我们是不知道还要做个管理系统的，以为所有功能都放在小程序，后来老师跟我们讨论聊到这个问题，我们才知道原来还有这回事，其实就是管理系统应该具有一切功能，即对数据库所有表的增删改查，而小程序只需要有些轻量的功能即可，至于上传大容量文件、查看学习情况这些不够轻量的功能全部放在管理系统。好吧，凡事总有第一次，我们就开始学习基本的前端三件套html,css,javascript。
开始做的时候我们希望先实现功能，界面难看点没有太多关系，于是学了部分三件套的基础后又学了ajax技术（因为要与后端通信），这里最开始用的是创建XMLHttpRequest 对象，用open()方法设置请求类型和url，用send()方法发送数据到后端，直到遇到了jquery，后面的请求统一都用$.ajax()了。
接下来又遇到了一个难点，因为基本都用表格来展示数据，那获取数据后如何动态地加入表格呢？查找资料后用每一条数据拼接成由tr标签包含的字符串，然后用jquery获取表格标签后调用append()方法加入表格中。
除此之外，我们想在每行末尾设置按钮进行事件处理，于是我们append数据的同时也把button标签放入刚才的字符串中，然后给每个button设置id属性，比如用于修改数据的就叫fixi，最后这个i是代表表格第几行，然后添加事件监听，点击button时获取id，然后查看最后一位是多少从而确定是第几行。
这些做法实现起来是挺繁琐的，而且感觉在重复造轮子，我们也做得有点郁闷，因为每个页面基本都要这样做，但是当时没有那么多的时间精力去学习框架，只是想先实现功能（u1s1，上学期的课多到我快吐了）。
放两张界面图
管理系统前端2.0
之前放假，总算有较多空余时间了，我们决定要改下界面，但毕竟自身水平不高，因此需要用一点第三方的东西了。
在跟小程序前端测试了部分功能后，有一天后端同学找到了一个开源的框架然后我们一起看了下说明文档，最后决定：就用它了。
有请layui登场，经典模块化前端框架、低门槛开箱即用。
真正使用之前可以先看看文档https://www.layui.com/doc/，个人感觉上手还是挺快的。layui提供了许多实用的组件包括弹出层、表格、表单、文件上传、流加载等等。
就拿表格来说，之前我们用append动态添加数据，现在直接table.render()，设置好参数就行了；之前我们给button设置id进行事件处理，现在绑定工具条，直接table.on()就行了；而且之前我们没实现的分页，现在设置分页参数就行了，然后查询数据库时分页读取。
另外，layui提供了一个页面布局的模板，包括logo、用户名、退出按钮、导航栏以及一些css动画。我们要做的就是按照它的模板来，页面元素的样式也参考它提供的。
有了layui的助攻，我们可以将更多注意力放在业务逻辑上，更多关注用户体验。
测试
后端本地测试
工具：postman
使用：打开一个新窗口，选择请求类型，输入url，设置参数，点击send
这种测试我认为是模拟前端发送数据然后运行后端代码，看结果是否正确，属于白盒测试，但是我们不是专业测试人员，目前这样测试不是做得很规范，只能尽可能想到不同的测试用例。
前后端联合测试
由于放假回家了没办法面对面，只能借助腾讯会议线上测了。
在部署工作完成之后，一般是我们写好接口代码，然后把url和需要的参数告诉前端同学（这里注意下，微信小程序的请求api只允许https开头的url，而且前端必须在微信公众平台配置好合法域名，不然会报错），前端把这些东西填入那个wx.request的api然后运行，他们会查看返回的数据是否正确，我们会查看数据库的情况，如果没问题会测试多几个数据，都可以的话就到下一个功能，这种方式应该是属于软工讲到的V模型的单元测试。
部署
用的是新浪云，实名认证、学生认证后会送一些云豆（新浪云的计费单位，1RMB=100云豆）
跟着之前说的教程把整个thinkphp项目部署到新浪云，具体步骤看https://www.kancloud.cn/cnzxo/sae_thinkphp/1423806
代码
在代码管理那里可上传压缩包，或者在线编辑（跟记事本差不多），改动大的最好在本地写好再贴上去
数据库
开启共享型mysql服务，目前用了phpmyadmin4.9版本，然后建表或导入sql文件
缓存
开启memcached服务，设置容量16MB（省点钱），其实这个服务我不是很清楚干什么的，但如果不打开访问接口时会报致命错误？
文件存储
我们需要保存许多类型的文件包括视频、课件、动画、作业、考试、头像，因此需要存放在服务端。这里开启storage服务，使用方法看https://www.sinacloud.com/doc/sae/php/storage.html#cyberck，普通用户配额5个bucket，每个容量10G，然后直接当作本地磁盘那样用就行了，控制台或写代码都可上传文件，上传后获得url，然后就可以通过网络访问，关于新浪云环境下php如何操作看官方文档http://apidoc.sinaapp.com/source-class-sinacloud.sae.Storage.html#。
域名
应用信息可查看二级域名，独立域名需要购买且备案
日志
日志中心可查看每次请求的接口、时间、请求方设备等信息
其它
控制台还可以实时查看流量统计、资源使用情况，以及消费情况
总结
这个项目我也算前后端都做了一遍，感觉前端不太适合自己，可能是对页面元素样式、用户体验不够敏感，不过必须承认前端是挺有意思的。至于后端是更加注重逻辑，目前我对后端的了解只停留在数据库、网络、部署层面，其实如果用户数量非常多还要考虑高并发的问题，也就要使用多线程、负载均衡、消息队列等技术了，所以还有很多技术需要学习
Ⅷ web 界面原型 使用什么工具
Pencil 是一款开源的原型图绘制工具，手绘风格的，就像自己在纸上画的那样。Pencil 还可以用来绘制各种架构图和流程图，同时还提供 Firefox 的插件。
Framer 是一个开源原型设计工具，使用 CoffeeScript 编写。支持动画效果和交互操作。