iOS10 新設計的弊端，跟風需謹慎

不吹不黑

從最初的一個產品概念到最終的產品上線，中間凝聚著一個IT團隊的心血和付出。產品經理作為其中的主導者，在一定程度上影響著產品的成敗和優劣。在整個產品研發流程中，每一環節都需要產品經理穩扎穩打的來推動項目前進，那主要的環節有哪些呢？我感覺從概要層面上可以將產品經理的工作分為三個步驟：需求整理、原型設計、開發跟蹤。

其中每一個環節都有很多的知識技能以及方法論需要我們去掌握，今天主要是探討一下從需求到原型的過程，有哪些地方是值得產品人去學習掌握的。畢竟，在一個好需求的框架之上設計出適用的原型才是打造一款優秀產品的基礎條件。

每當設計工作過不了稿時我會很痛苦，會寢食難安，即而是一種堅決要盡快過稿，解脫痛苦，達到客戶和自己滿意的信念，同時也有一定不服的氣憤。為使自己遠離痛苦，我會嘗試多種方法：

1.主動，多次，溝通，迅速改稿。

多問為什么，清楚頁面交互和每一個元素的由來，探討好如何做的種種嘗試，再定一兩種先做出來。同創，與客戶及客戶的客戶共創。

加班，快速迭代。

2.自己反復看，順眼了，對了，再給別人看。

要想順利，自己先做好，有毛病，一看就有漏洞的不要拿出去。人都是有自尊心的，為了自己的自尊，為了自己那份的責任心。

3.盡可能快，多的，掌握更多的此行業的知識、理論，根據，找到目前運作雙方的不足，有了強有力的武器，披荊斬棘，旁征博引。

請教高手。

4.能聽得進去意見，并有同理心。

當客戶不認可自己作品時，連帶基本上是不認可設計師這個人的。這時候百口莫辦，唯有行動來說明自己。

消極應對，推一推動一動，或回報以不滿或不認可的情緒化，顯然是不可取的。如果每次栽在這里，只能說自己的能力和水平有限，處世不夠成熟。

在界面上通過下列方式來控制出錯幾率，會大大減少系統因用戶人為的錯誤引起的破壞。開發者應當盡量周全地考慮到各種可能發生的問題，使出錯的可能降至最小。如應用出現保護性錯誤而退出系統，這種錯誤最容易使用戶對軟件失去信心。因為這意味著用戶要中斷思路，并費時費力地重新登錄，而且已進行的操作也會因沒有存盤而全部丟失。那么在軟件界面設計過程中，關于安全性，都有哪些詳細的規則呢？下邊我們就來分享下安全性的詳細細則：

菜單是界面上最重要的元素，菜單的位置應該按照功能來組織。通常菜單設置需要把握的一些細則如下：

1.菜單通常采用“常用--主要--次要--工具--幫助”的位置排列，符合流行的Windows風格。
2.常用的菜單有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，要根據不同的系統有所取舍。
3.下拉菜單要根據菜單選項的含義進行分組，并且按照一定的規則進行排列，用橫線隔開。

界面設計的風格，色彩應基于公司的VI手冊，形成自己獨特的品牌風格；另外，頁面元素應該大小適合美學觀點，感覺協調舒適，能在有效的范圍內吸引用戶的注意力。那么美觀性和協調性的細則有哪些呢？

1.長寬接近黃金點比例，切忌長寬比例失調。
2.布局要合理，不宜過于密集，也不能過于空曠，合理的利用空間。

前言

生活有度，人生添壽。

Javascript從當初的一個“彈窗語言”，一步步發展成為現在前后端通吃的龐然大物。javascript的受歡迎程度也是與日俱增，今年編程語言又是花落javascript，這實在是一個充滿了活力的語言。如今，隨隨便一個網頁javascript代碼量都不下數千行，要是node后端那更不止幾千行了。（WTF）代碼量的增加給編程帶來的首要的問題就是如何去編寫和維護如此龐大的代碼呢？答案就是模塊化思想，其實就是面向對象（OOP）編程，如今比較流行的三大前端框架（angular,react,vue）基本都實現了組件化編程，但組件化和我們所說的模塊化又有所不同，應該可以這么理解，組件化是模塊化的升級版，模塊化是組件化的基礎。那么，問題來了，javascript怎么面向對象編程呢？我想這很多老鳥也不定說的清楚吧，前端雜而活躍的各種社區，很多前端er一度依賴各種插件，根本不需要去了解這些深層的東西卻照樣能完成任務。但我想作為一個有追求的前端er還是很有必要去學習這些看似用不著的東西的，別的不說，就單單因為我們是前端er,只會用jquery一個稍微厲害的后端都能代替你。好吧，廢話不多說，到底如何面向對象coding呢…..

很不幸，es5中并沒有給出明確的定義‘類’的概念，所以傳統的面向對象編程似乎是行不通的，那么又該腫么辦呢？值得慶幸的是，前輩們通過不斷探索總結，成功的用javascript模擬出了“類”。那么，javascript的類又該怎么定義呢？

在面向對象編程中，類（class）是對象（object）的模板，定義了同一組對象（又稱”實例”）共有的屬性和方法。

深挖產品設計背后的工作方式和工作流程，讓產品經理受益匪淺。

Design Sprint Method （谷歌沖刺計劃）是由谷歌創投的 Jake Knapp 發明的一種產品設計工作法，是指由一支不超過 7 人的團隊，在 5 天之內，通過 5 個步驟，能夠快速解決產品難題的產品設計方法。其基礎概念來自于敏捷開發、設計思考和個性游戲法，先后被 100 多家創業公司實踐，打造了諸如 Slack、 Nest、Blue Bottle Coffee 和 23andMe 等多個成功的互聯網產品。

搜索功能無論在web端還是移動端，都是產品中十分重要的功能。文章主要從用戶體驗和產品功能、策略角度來分析，提出一些對應的設計方法。

搜索能夠幫助用戶快速找到想要的結果，其中兩個重要目標是提高搜索結果的相關性，降低結果觸達的延遲性。用戶使用搜索功能來滿足其信息獲取的需求，其搜索目的是在搜索結果中進行內容消費。搜索功能一般來說都是全局性質的“模糊搜索”（用戶可以搜索到產品的主要內容），有時也會出現在局部結構中（如某個功能模塊下的“定向搜索”）。

@黃紅藝Designer ：對于交互設計師而言，一個項目的開始，是從接到產品經理的需求文檔開始的。從需求的確認到交互稿的確認，再到產品開發效果的確認，都考驗著交互設計師設計能力以外的技巧。在這個過程中，有一些要點需要你知道，來保證你的設計過程更加順暢。

第一點：確認你所理解的需求是否正確

一千個人的眼中，就有一千個哈姆雷特。對于需求的理解也是一樣，我們拿到需求以后，要和產品經理進行溝通，將自己對需求的理解與簡單的頁面構思，闡述給產品經理，以確定自己的理解與設計方向是否準確。切忌，拿到需求就開工去做，以為可以節省時間，卻不知錯誤的理解和方向，讓你付出更多。

不要認為，產品經理給的需求就像數學定理一樣可以深入理解，詳細解讀，沒有那么多的產品經理有這個功夫和能力去做這個事情。因此，溝通才是保證你對需求的理解，對設計方向正確把握的基石。

那么，在需求交流之前你要準備好什么呢？第一，認真研究需求，理解需求；第二，是你在研究需求時，發現的問題，最好整理出來，以便在討論時提出，讓產品經理為你解答，而不是自己”以為“；第三，如果時間充足，最好整理出界面的框架，或者用草圖來展示你的設計思路，看產品經理是否認可你的設計。

對于討論中形成的共識，最好以郵件的形式發出，一方面可以作為會議紀要，便于隨時解答疑惑，另一方面，是立字為證，防止需求的隨意變更。