設計APP軟件圖標的思路：
APP圖標的主要風格（設計表現手法）主要分為：色彩絢麗型，極簡會意型兩種。遊戲類的圖標大都要求顏色豐富，充滿動感，極具吸引力。應用類的圖標大都要求簡潔明快，主題突出。
APP圖標製作的主要思路：突出功能，突出用途，突出品牌。
APP圖標製作的常用工具：photoshop, fireworks, coredraw，設計工具有像素繪圖工具，向量繪圖工具，像素圖由小變大時會變模糊，影響美觀，因此一般都是做大圖，然後壓縮成需要的各種規格小圖。
APP圖標的常用色系搭配， 仔細觀察會看到應用市場中的圖標顏色五花八門，豐富多樣，但大部分都是基於紅色、藍色、綠色、白色搭配而成。白色給人清晰、簡潔的美感，紅色充滿熱情活力，藍色讓人覺得可信任，綠色給人以健康、自然的印象。
要根據自己的應用選個合適的顏色，這樣才能事辦功倍。
2.app ui設計 要求 怎麼寫1. 行業，業務介紹；告訴設計師app是用來做什麼的。及用户羣體大多是哪類人；有經驗的設計師會根據以以往經歷來斟酌設計。
2. 設計要求及技術事項；如果你希望用什麼顏色；或什麼風格。可以把一些好的案例發給設計師。（但是也別太多；這無疑是把范冰冰眼睛，章子怡都嘴，林志玲都鼻子等諸多好東西從新拼湊；會起到反效果）技術事項是比如你的app是否需要兼容pad及安卓；
3. 準備文案，比如app都首頁會有一張大廣告圖；但是圖上面的廣告語；得你來想好；如果設計師自己隨便弄個；也許不符合你的意願；完了修改。這又造成了時間與工作量的浪費。
本答案由祝明園ui設計工作室專業回答
3.android app設計文檔怎麼寫數字內容的存儲，分發和娛樂服務。用户為資源社區的註冊用户。
1.1. 編寫目的
本文檔的目的，旨在規範軟件開發，推動項目有序正常的進行，使相關人員遵守統一的規範。節省製作相關文檔的時間，降低系統實現的風險，加快項目實施進度，做到系統設計的規範性和全面性，以利於系統的設計、實現、測試、維護和版本升級。
1.2. 項目範圍
本文檔用於軟件設計階段的概要設計，它的上游（依據的基線）是項目需求分析書，它的下游是項目詳細設計説明書，併為詳細設計説明書提供測試的依據。
軟件概要設計的範圍是：客户端軟件系統總體結構、外部接口、主要部件功能分配、全局數據結構以及部件之間的接口等方面的內容。
2. 軟件概述
2.1. 愛私貨概括
本文檔用於軟件設計階段的概要設計，它的上游（依據的基線）是項目需求分析書，它的下游是項目詳細設計説明書，併為詳細設計説明書提供測試的依據。
2.2. APP功能
本文檔用於軟件設計階段的概要設計，它的上游（依據的基線）是項目需求分析書，它的下游是項目詳細設計説明書，併為詳細設計説明書提供測試的依據。
4.設計説明怎麼寫這個挺簡單的。
其實就像是在和客户交流思想，你用什麼色調，什麼模式，風格又是什麼樣子的，每個地方的設計理念和設計的合理化都要一一説明，用語言把你做出來的圖表描述出來，讓不懂和不理解的人一看就知道你要説明的是什麼了。比如一個現代風格的簡約裝飾最簡單的説明：我的設計理念：（自己的評價）簡約大方，時尚而不缺乏美感，用最簡單的造型表達出最美的效果，又不缺乏實用性。
首先-客廳：（你要對客廳進一步的描述）白色為主色調，用橙色烤漆玻璃做背景，給人一種温馨舒適的感覺，在冬天裏橙色是給人很温暖的色系之一。在用墨灰色做牆面壁紙，給人一種很柔軟舒適的空間，灰色給人平穩安靜的感覺，讓你感覺不到特別跳躍的動態空間。
主要分為橙色、墨灰色、白色，三大色系。在加一簡約的傢俱，布藝沙發為主。
絨織地毯最好，因為柔軟質地也好，檔次也高。此設計適合時尚白領家居風格。
5.怎樣寫好一個APP產品介紹功能+場景；例如
我是小靈靈語音機器人是新一代的智能語音手機軟件。您説話我就能懂，還能用我的聰明才智給您回答，為你提供衣食住行、諮詢娛樂等種種智能服務。
1、（李經理問）
李經理：明天飛北京
小靈靈：以為你找到明天廣州到北京的航班
2、（小明問）
小明：最近有什麼電影好看
小靈靈：這是附近影院上映的電影
3、（週六李爸爸問）
李爸爸：北京路怎麼去
小靈靈：現在為你提供路線方案。
4、（小紅問）
小紅：四川有那些好玩的
小靈靈：這是我推薦的成都的旅遊景點，需要我為您定製行程嗎？
目前還支持：“找房子、找家政、查天氣、生活提醒、智能旅遊定製、導航、各類生活服務、百科知識查詢、景點酒店推薦、熱點附近查詢”等涵蓋生活方方面面30多種功能。你想知道的，小靈靈都能告訴您。
6.軟件詳細設計説明書面向對象軟件設計説明書模板 1 概述 1.1 系統簡述 對系統要完成什麼，所面向的用户以及系統運行的環境的簡短描述，這部分主要來源於需求説明書的開始部分。
1.2 軟件設計目標 這部分論述整個系統的設計目標，明確地説明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需提及。
需求規格説明書對於這部分的內容來説是很重要的參考，看看其中明確了的功能性以及非功能性的需求。 這部分必須説清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。
在隨後的文檔部分，將解釋設計是怎麼來實現這些的。 1.3 參考資料 列出本文檔中所引用的參考資料。
（至少要引用需求規格説明書） 1.4 修訂版本記錄 列出本文檔修改的歷史紀錄。必須指明修改的內容、日期以及修改人。
2 術語表 對本文檔中所使用的各種術語進行説明。如果一些術語在需求規格説明書中已經説明過了，此處不用再重複，可以指引讀者參考需求説明。
3 用例 此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敍述。 4 設計概述 4.1 簡述 這部分要求突出整個設計所採用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客户/服務器結構）以及使用到的相應技術和工具（例如OMT、Rose） 4.2 系統結構設計 這部分要求提供高層系統結構的描述，使用方框圖來顯示主要的組件及組件間的交互。
最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了説明圖中用到的俗語和符號。
4.2.1 頂層系統結構 4.2.2 子系統1結構 4.2.3 子系統2結構 4.3 系統界面 各種提供給用户的界面以及外部系統在此處要予以説明。如果在需求規格説明書中已經對用户界面有了敍述，此處不用再重複，可以指引讀者參考需求説明。
如果系統提供了對其它系統的接口，比如説從其它軟件系統導入/導出數據，必須在此説明。 4.4 約束和假定 描述系統設計中最主要的約束，這些是由客户強制要求並在需求説明書寫明的。
説明系統是如何來適應這些約束的。 另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。
這種情況下，要求清楚地描述與本系統有交互的軟件類型（比如某某某數據庫軟件，某某某EMail軟件）以及這樣導致的約束（比如只允許純文本的Email）。 實現的語言和平台也會對系統有約束，同樣在此予以説明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。 5 對象模型 5.1 系統對象模型 提供整個系統的對象模型，如果模型過大，按照可行的標準把它劃分成小塊，例如可以把客户端和服務器端的對象模型分開成兩個圖表述。
對象圖應該包含什麼呢？ 在其中應該包含所有的系統對象。這些對象都是從理解需求後得到的。
要明確哪些應該、哪些不應該被放進圖中。 所有對象之間的關聯必須被確定並且必須指明聯繫的基數（一對一、一對多還是多對多，0..1,*,1..*）。
聚合和繼承關係必須清楚地確定下來。每個圖必須附有簡單的説明。
可能經過多次反覆之後才能得到系統的正確的對象模型。 6 對象描述 在這個部分敍述每個對象的細節，它的屬性、它的方法。
在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。
如果對象是存儲在持久的數據容器中，標明它是持久對象，否則説明它是個臨時對象（transient object）。 對每個對象的每個屬性詳細説明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
對每個對象的每個方法詳細説明：方法名，返回類型，返回值，參數，用途以及使用的算法的簡要説明（如果不是特別簡單的話）。如果對變量或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此説明。
列出它或者被它調用的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
6.1 子系統1中的對象 6.1.1 對象：對象1 用途： 約束： 持久性： 6.1.1.1 屬性描述： 1. 屬性：屬性1 類型： 描述： 約束： 2. 屬性：屬性2 6.1.1.2 方法描述： 1. 方法：方法1 返回類型： 參數： 返回值： Pre-Condition: Post-Condition： 讀取/修改的屬性： 調用的方法： 處理邏輯： 測試例：用什麼參數調用該方法，期望的輸出是什麼…… 7 動態模型 這部分的作用是描述系統如何響應各種事件。例如，可以建立系統的行為模型。
一般使用順序圖和狀態圖。 確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。
不要自己去想當然地創造場景，通常的策略是描述那些客户可以感受得到的場景。 7.1 場景（Scenarios） 對每個場景做一則條目，包括以下內容： 場景名：給它一個可以望文生義的名字 場景描述：簡要敍述場景是幹什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的。
