• 未分類
  • 平面理論教程
  • Flash教程
  • 其他作品
  • 標誌設計
  • 海報招貼
  • 包裝設計
  • 畫冊設計
  • 網頁設計
  • 名片設計
  • PS作品
  • CG設計
  • MAYA教程
  • Illustrator教程
  • AutoCAD教程
  • 3DMAX教程
  • Painter教程
  • 繪畫教程
  • FireWorks教程
  • 攝影教程
  • 工業設計
  • 網頁設計教程
  • 其他資訊
  • 摺紙大全




  • [ 平面理論教程 ] 如果通過組隊接設計外包學習這4個經驗—- 設計教程




    教學主題: 如果通過組隊接設計外包學習這4個經驗

    大家好!! 小編今天來和大家分享關於 設計教程中的平面理論教程教學

    今天的這個教學主題是: 如果通過組隊接設計外包學習這4個經驗

    這教學的重點為這幾點 [ 學習,經驗,外包,設計,通過,如果,交互,他們,這些,一個, ]

    希望你可以從這幾點中領悟到修圖的精華

    本文重點

    這段時間和朋友接了一個設計外包項目,我是交互設計師,其他兩個負責視覺設計,第一次組團隊,無論團隊內部還是合作公司那邊,都是邊磨合邊工作,進行不是很順利。磕磕碰碰做完后,回顧這次項目經驗,有4點經驗想跟大家分享一下。

    這段時間和朋友接了一個設計外包項目,我是交互設計師,其他兩個負責視覺設計,第一次組團隊,無論團隊內部還是合作公司那邊,都是邊磨合邊工作,進行不是很順利。磕磕碰碰做完后,回顧這次項目經驗,有4點經驗想跟大家分享一下。

    一、項目需要一張數據表

    這次算是一個全新的項目,從零開始,但是實際上第一版出來的功能已經非常多了。產品那邊沒有一個完整的功能列表給我,需求也是時不時進行改動。所以,在做設計的時候,總感覺會遺漏某些狀態的變化,所以,針對這一點,我覺得可以有一張數據表。這張表就是工程師後台的數據記錄,產品在規劃功能的時候就需要把這張表格給羅列出來,然後在設計交互流程的時候,每進行一個步驟,都需要考慮這個步驟對於這個數據表格的影響,然後把這些變化完整地寫進交互文檔裡面。

    舉個例子,由於我們的平台是一個優惠券發放的平台,那麼這個時候涉及到兩個主體:優惠券和領券的人,優惠券的數據就是一個數量的問題。不過對於領券人,數據表有如下:1、未使用的券;2、已使用的券;3、已過期的券;4、待付款的訂單;5、已付款的訂單;6、已退款的訂單;7、積分;8、返利。

    羅列了一下,這些是最主要的數據,然後比如說訂單的數據,因為訂單是進行購買優惠券的活動的,所以訂單的數據也會影響優惠券的數據。優惠券消費會有返積分或者返利,所以,優惠券的狀態也會影響積分或者返利的數據。那麼也就是說訂單的變化也會影響積分或者返利。這些數據之間關係錯綜複雜,如果有一張詳細的表格,可以把這些變化寫進交互設計文檔裡面,我覺得邏輯會更加完整,對於開發人員來說也比較便捷。只是可惜,這些都是做完了才發現的,所以當時就沒有做。

    如果通過組隊接設計外包學習這4個經驗

    二、將功能模塊化

    這次的項目是我有史以來接到的最大的項目,項目功能比較多也比較雜亂,特別是後期加入了一個支付功能,導致整個交互邏輯的複雜度大大增加了。複雜度變大的壞處有三個:①難以梳理邏輯;②容易遺忘一些邏輯;③難以恰當地闡述設計。針對這三個缺點,我在做的過程中嘗試將功能進行模塊化。模塊化的意思是將一些功能進行打包,然後只梳理這些功能之間的關係。梳理完之後,這些功能就形成了一個整體,然後其他功能只和這個整體進行交互而不和其中的功能進行交互。

    這麼說有點不形象,舉個例子吧,就說電腦吧,電腦可以看成是由顯示器、CPU、內存、硬盤等部件構成的,而其實顯示器裡面又是由各種零件構成的,顯示器裡面的零件就相當於我的功能,我所做的就是先把一部分打包成“顯示器”,一部分打包成“CPU”,然後把他們當成一個整體來考慮。

    顯而易見就是,這麼做首先每次處理都只是一部分問題,邏輯比較容易梳理,也不容易遺忘邏輯。當然,更重要的就是表達的問題。如果不進行模塊化的話,我真的不知道該如何在一張畫布上把這些邏輯流程表達出來,所以,模塊化之後,我可以在每張畫布只表達其中一個模塊,當我把所有模塊都闡述清楚了,整個項目也就清楚了。

    當然,除了以上的種種優點之外,模塊化還有一個優點就是方便復用。一些常見的模塊,比如註冊登錄模塊,消息通知模塊,個人中心模塊,這些模塊在當今的APP里基本都存在,也就是說他們的復用率都比較高。如果在設計的過程中就已經將這些功能進行模塊化了,之後如果需要設計新產品的功能時,這些模塊就可以直接拿過來複用,省時省力。這個省時省力節約的是功能規劃、界面設計、邏輯推演等等這些時間和精力,所以還是相當可觀的。

    如果通過組隊接設計外包學習這4個經驗

    三、定義公共交互

    如果說前面的模塊化是為以後的設計做準備,那麼公共交互這一塊其實就是貫穿整個設計的過程。在做設計的過程中,其實會發現很多小流程的處理,之前已經做過了,做過了我當然不會再畫一遍,再寫一遍邏輯,我一般只會寫“此處XX邏輯參考XX頁的XX圖”,不過慢慢地,這些一多,就發現自己也會亂掉。當出現次數超過四次時,我就每次寫那句話都有點不太放心,怕自己引用的那個地方也是缺省的,所以每次都要把交互稿翻一下,然後才能信心滿滿地寫下這句“此處XX邏輯參考XX頁的XX圖”。

    碰巧之前在一家公司遇到過他們的交互稿,一個公司的產品那就是相當複雜了,所以他們會把一些公共的交互給羅列出來,放在交互稿的前面部分,然後每次引用的時候就是引用公共交互的東西。我覺得這個可以借鑒到小項目的交互稿裡面。也就是說,交互稿除了一開始的說明以及後面的線框圖之外,中間再加入一張畫布“公共交互”,然後把所有出現過兩次以上的交互都可以總結到這張圖上,這個公共交互當然是自己一邊做一邊維護的,不過想來,這樣子做,既可以保證自己畫圖的質量和效率,對於開發來說也是很有裨益的吧。

    一些常見的公共交互有:刪除操作、編輯操作、分享操作。只要把這些操作流程在公共交互里完整地寫一遍,後面的就可以大膽地復用這些公共交互了。

    如果通過組隊接設計外包學習這4個經驗

    四、溝通方式

    正如我一開始說的,我們是一個新的團隊,大家彼此之間都沒有合作過,也不清楚各自的工作方式,導致在設計過程中會暴露出很多問題。我是交互設計師,可能對於整體的把控會更加良好一些,視覺設計師天生比較浪漫主義一些,所以一些事情需要我為他們考慮到,如果沒有考慮到,他們可能就會耽誤項目的進度。

    說兩點在溝通方式上出現的問題,供大家參考一下。

    第一點出現在進度安排上,在我做完交互稿之後,發現頁面的數量大大超出了預期,結果他們一聽到就開始信心大受打擊。雖然我一直反覆跟他們說,增加的頁面都比較簡單,但是他們完全都聽不進去,直到後面他們兩個人的分工出現了問題。所以這時候我就只能跳出來做協調人。首先當然是統計頁面的數量,然後給頁面分級,分為“主-次-送”三個等級,主要頁面當然是比較複雜的頁面,次要頁面是簡單頁面,考慮到有一些頁面實在太簡單了,就當作贈送給公司的。分級的好處就是,他們對於項目的難度有一個較為良好的認識,壓力沒有那麼大。然後我根據他們的工作能力(一個工作經驗較為豐富,另一個經驗稍顯欠缺)、剩餘的時間以及他們之前的協商結果,把整個計劃表表做出來,計劃表一是可以方面地查看進度,更加重要的是對視覺設計師的一種“束縛”,束縛他們的浪漫主義。所以計劃表一出來,整個項目才得以順利實施下去。

    第二點出現在成果交付上,首先就是他們的視覺稿。他們習慣用Photoshop作圖,然後也比較隨性,隨性的結果就是雖然界面看起來很乾凈整潔,但是圖層的管理就一坨shit,各種“組1”、“圖層1”、“方塊1”的命名層出不窮,外人根本沒法看。你要問為什麼這會是溝通的問題?因為我也要審核他們的視覺稿,有些小問題我自己就改掉了,但是面對這麼雜亂的圖層結構,真的是沒什麼改動的慾望。

    接着,就是視覺稿PSD的命名了。我在做交互稿的時候已經將功能模塊化了,每個模塊都會有各自的命名和編號,注意這裡的編號才是最重要的,因為可以方便地回溯。但是他們在命名的時候恰恰忘了把這個編號加到每一張PSD上,所以後面整理的時候出了糾紛,還是在我的強烈要求下,他們才全部改了一遍。然後是這麼一堆PSD文件,不可能就隨便打個包吧,至少按每個模塊建立一個文件夾吧。然後如果PSD文件有改動,要怎麼命名吧。這些問題都是一開始沒有想到的,也沒有協商好,結果導致合作上出現了問題。雖然都是小問題的,但是這些都是會在項目的末尾暴露出來,說實話,影響最大的其實是心情,真的是心好累。

    看完小編分享的教學之後 是不是對平面理論教程中的設計教程教學更熟悉了呢?

    希望我們所介紹的 如果通過組隊接設計外包學習這4個經驗 這教學會喜歡

    文章標題: 骨子愛創意- 如果通過組隊接設計外包學習這4個經驗–轉載請註明來源處

    本教學分類為平面理論教程中的 設計教程相關教學

    文章相關關鍵字為: 學習,經驗,外包,設計,通過,如果,交互,他們,這些,一個,

    本文永久連結 :如果通過組隊接設計外包學習這4個經驗

    本文轉載自 :VIA