Ⅰ 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 編寫。支持動畫效果和交互操作。