構建之法第十一、十二章
用戶體驗有幾個層次:
1 最基礎的是在交互環節,就是usablity,可用性,或者說易用性,大家說得最多的;要把可用性做好,不是太難,業界有成熟的方法,不需要太多天賦,兩個字:“用心”即可。
2 更高層次的乃情感,即諾曼所說的情感化設計,要讓用戶感到愉悅,感到驚喜,感到感動,比較難,需要一定的天賦,關鍵是四個字:“心有靈犀”,如果你能和用戶“心有靈犀”,就能觸動他/她的情感。
3 最高的層次乃“人物合一”,什麽意思呢,用戶用你這個產品,不僅是出於認同這個產品,而是認同他/她自己,自我認同,自我展現,自我實現。。產品成了自我的投射和映射,通過產品,用戶找到了自己的興趣、自己的歸屬、自己的價值。要達到這一境界,你必須搞清楚用戶最渴求的是什麽東西,不是普通的需要,而是心底深處最渴求的東西,然後不是簡單粗暴地滿足它,而是以一種藝術的方式滿足它。構建之法第十一、十二章
相關推薦
構建之法第十一、十二章
交互 業界 用戶體驗 可用性 找到 方法 認同 我認 設計 用戶體驗有幾個層次:1 最基礎的是在交互環節,就是usablity,可用性,或者說易用性,大家說得最多的;要把可用性做好,不是太難,業界有成熟的方法,不需要太多天賦,兩個字:“用心”即可。 2 更高層次的乃情
構建之法第十一章讀後感
思維導圖 我們 加減乘除 圖形 計算 每日 導圖 case 中間 本周進行了構建之法的第十一章軟件設計與實現的學習; 第十一章主要講了典型的開發流程,常見的分析和設計方法:ERD,DFD,UML,開發階段的一些管理方法:每日構建,小強地獄,構建大師; 分析和設計方法包括以文
讀構建之法第四、十七章有感(作業四)
關系 img 作用域 src 而在 clas com 不同的 第十七 第四章: 問題: 看到這裏的時候,才註意到代碼中的“下劃線”這個東西,在之前的敲代碼過程中並沒有怎麽遇到下劃線,在經過百度後得到了一些答案: 這只是Python中下劃線的一部分應用,在不同的語言中
構建之法第四章第十七章
height 多文檔 缺失 後來 更強 最大的 fun 影響 手機 一、關於goto函數:濫用goto語句會使程序變得很難理解,而不是所有人能正確的使用goto函數,我的問題是:是不是因為這樣所以很多文檔規定禁用或少用goto函數?但其實如果可以正確的使用goto語句就不能
讀構建之法第四章第十七章有感
限制 選擇 class blog 了解 什麽 靈活 多重循環 價值 第四章 1、原文;“函數最好有單一的出口,為了達到這個目的,可以使用goto.只要有助於程序邏輯的清晰體現,什麽方法都可以使用。——P69” 問題:關於goto,我記得老師講過,這個在編程中是盡力避
構建之法第八、九章學習
周期 常用 bcd 快速 區別 利益相關者 自省 生命 獲取 第八章:需求分析 這一章主要講述了軟件需求的類型、利益相關者、獲取用戶需求的常用方法和步驟、競爭性需求分析的框架NABCD、四象限方法、項目計劃和估計的技術。 確認軟件需求有以下步驟:1.獲取和引導需求、2.分析
構建之法第六、七章讀後感
敏捷 關註 團隊 項目 提前 敏捷流程 準備 讀後感 合作 Agile——敏捷開發,作為CMM神話崩潰後被引入的一套新的軟件開發模式,這幾年來被廣泛引起關註,並被寄予厚望。 敏捷流程及其原則告訴我們個體和交互勝過過程和工具,盡早為客戶需求做準備和交付有價值的軟件,時時總結如
構建之法 第五章 團隊和流程
ini 之前 組織 第五章 團隊 mod 交互 然而 逆轉 典型的團隊開發模式和流程,完全是新的內容;涉及到更多的術語和有意思的策略性東西 1.團隊模式【我比較認可的】 主治醫師模式 由首席程序員(相當於首席醫生)負責整個工程,周圍人員各司其職,配合支持中心人物的工作;
讀構建之法 第三章:軟件工程師的成長
知識點 可維護 vid -s 評估 不同 fun 可靠 科研 本章理論和知識點:評價軟件工程師水平的主要方法 軟件工程把相關的技術和過程統一到一個體系中,叫“軟件開發流程”,軟件開發流程的目的是為了提高軟件開發、運營、維護的效率,以及提升用戶滿意度、軟件的可靠性和可維護性。
構建之法-第三周
合作 工作 軟件 評價 方差 數據 同時 接收 此外 構建之法第三章-軟件工程師的成長 本章主要的理論和知識點是評價軟件工程師水平的主要方法、技能的反面以及TSP對個人的要求。 首先,不同的數據能夠從不同方面一個展示軟件工程師的技術和能力,例如,通過完成時間平均值的比較
四瀆《構建之法》——計劃估計、敏捷流程、項目經理和用戶場景
理解 流程 ger 改進 學習 解決 可能 觀察 平衡 本周再次打開《構建之法》,這次我閱讀時重點在於學習敏捷流程、項目經理和用戶場景等相對較為宏觀的內容。 第六章開篇即簡單地介紹了敏捷開發的流程:Product Backlog—>Sprint Backlog—>
構建之法第三章讀書心得
如何 讀書心得 初級 知識 技能 任務 項目 標準 技術 在構建之法第三章中,我們主要學習了個人能力的衡量與發展。 初級軟件工程師有以下幾個成長階段:1、積累軟件開發相關的知識,提升技術技能。 2、積累問題領域的知識和經驗。
構建之法 第六章 敏捷流程
小時 所有 管理層 log 匯報 薪水 quest 功能 任務 敏捷是一種很“年輕態”的思路/策略,是以“萬事萬物都在不停地發展變化”為指導去組織軟件工程的需求分析、內部的調和、代碼編寫甚至維護,所以我讀起來會覺得很有共鳴。然而並不是所有的地方都適合讓“敏捷”去闖一闖。 1
構建之法第六周感想 需求分析
感想 研究 心理 調研 問題 生活 情況 進行 做成 這周我學習的是需求分析。軟件團隊通過以下幾個步驟找到軟件需求:獲取和引導需求;分析和定義需求;驗證需求;在軟件產品的生命周期中管理需求。而軟件的需求也分為幾類:對產品功能性的需求,對產品開發過程的需求,非
構建之法第三四五章總結
職業 驅動 技能 自動操作 人的 階段 提升 理解 成員 軟件開發流程不光指團隊的流程,還包括個人開發流程,因為軟件團隊是由個人組成的。在團隊的大流程中,是沒一個具體的人在做開發,測試等,因此,個人在團隊中也有獨立的流程,把每個人的工作有序組織起來,就是團隊的流程。
構建之法 第五次心得
設計 實體關系 以及 ont 討論 nag 有一種 不定 擴展性 構建之法9、10、11章 第九章 學習了第九章之後,了解到了在一個項目中項目經理的重要性。生活中,無論什麽團隊工作,都需要一個領隊,來掌控團隊項目的發展,以及各個成員工作的分配。PM指Product Mana
構建之法第五六章讀後感
例子 spa scrum 過程 困難 老板 敏捷開發 統一 學習 鄒欣老師的這本書,寫得形象生動,第五章用體育運動等團隊例子引出軟件開發團隊的形式。軟件團隊形式多樣,適用於不同的人員與需求。團隊可能會演變的模式有:主治醫師模式、明星模式、社區模式、業余劇團模式、秘密團隊、特
構建之法第六章學習心得
效率 用戶 當前 決定 復雜 技術 原則 核心 back 這周我學習了構建之法第六章敏捷流程,本章主要介紹了敏捷流程及其原則,Backlog、Burn-down、Sprint、Scrum方法論。以及什麽時候選擇敏捷的開發方法,什麽時候選擇其他方法。.敏捷開發的原則是盡早並持
讀構建之法 第四章:兩人合作
應用 結對編程 使用 一對一 測試 一個 比較 以及 領域 程序員寫的代碼最終是人在看,所以代碼規範很重要,原則是:簡明,易讀,無二義性。 不光是程序書寫的格式問題,還牽涉到程序設計、模塊之間的關系、設計模式等方方面面。 代碼復審的正確定義看代碼是否在代碼規範的框架內正確的
構建之法第四章讀書心得
算法 邏輯錯誤 規範 審核 領域 之間 心得 使用 部分 代碼風格規範——主要是文字上的規定,看似表面文章,實際上非常重要 代碼風格的原則是:簡明,易讀,無二義性 代碼設計規範——牽涉到程序設計、模塊之間的關系、設計模式等方方面面的通用原則 代碼設計規範不光是程序書寫的格