一般的項目中UI是非常重要的一部分芥颈，我們今天談?wù)勗诿艚蓍_發(fā)交付團(tuán)隊中我們是如何創(chuàng)造UI的mockup以及該UI是如何到DONE的。
我理解中的UI分兩個部分泻骤，第一是樣式围肥，即這個頁面長啥樣兒待笑，用啥字體鸣皂，有啥樣的style guide等等；第二個就是交互暮蹂，何時能點(diǎn)擊某個button，請求成功或者失敗應(yīng)該發(fā)生什么等等癌压。
正常的能夠到ready for dev的帶UI的story都是這么來的仰泻，在了解了下個迭代的需求之后，UX會根據(jù)需求draft一個mockup出來滩届，然后跟相關(guān)需求的BA到一個小黑屋碰一下集侯，倆人討論的結(jié)果沒問題就會把mockup放到該故事卡里，并且上傳到zeplin這樣的工具里供開發(fā)參考帜消。這個mockup不只是說簡單的一個樣式棠枉，有可能一張卡里面有好多mockup，是不同用戶行為的不同展現(xiàn)形式泡挺。我之前在TechOps項目的時候UX簡直不要太好辈讶，她會利用invisionapp模擬這些交互，我們就可以隨時去check哪個頁面的交互是怎樣的娄猫。
從上面的UI生成過程中可以看出贱除，UI跟需求是密切相關(guān)的，不可能說需求里面沒有一個叫‘A’的概念媳溺，UI上卻顯示了一個叫做‘A’的模塊月幌。那么必然UX和BA需要經(jīng)常與對方交流信息。
那么到了開發(fā)可以開始做的時候悬蔽，開發(fā)可能先要看一下這個mockup扯躺，一般來說都比較容易根據(jù)需求看懂mockup是什么意思，但是會經(jīng)常出現(xiàn)在做的過程當(dāng)中才會發(fā)現(xiàn)一些未知的參數(shù)，比如說如果要兼容IE那么我的input框尾巴那里的叉叉的樣式是怎樣的录语，再比如說我們需要一個icon但是還未上傳等等倍啥。太多細(xì)節(jié)需要常常跟UX溝通，甚至有時候開發(fā)需要跟UX pair來一起完成钦无。
從而可以看出逗栽，UX和DEV也需要常常互相交流來確認(rèn)設(shè)計失暂。
我是一個非常幸運(yùn)的開發(fā)彼宠，在以前所有的項目中UX都是我們自己人，完全精通UI的設(shè)計理念弟塞，也懂得如何順暢地跟BA以及開發(fā)合作凭峡。而在現(xiàn)在的項目，客戶爸爸由于某某原因用了另外一個vendor的UXs决记。這里有兩個問題摧冀，第一是由于remote，溝通是不方便的系宫；第二個是有時差索昂，當(dāng)有了問題只能郵件去問，然后就是等待回復(fù)扩借。在經(jīng)歷了第一次合作之后我發(fā)現(xiàn)了另外一個問題椒惨，她們貌似不是根據(jù)story來創(chuàng)作的，需求里面有的東西她們不給潮罪，需求里面沒有的她們卻畫出了康谆，畫出了樣式之后也不考慮交互，當(dāng)我們提及交互是怎樣的時候嫉到，她們卻回答說還沒想好沃暗。這時候我才覺的，我想念我們的UX何恶！但是比較不錯的是孽锥，她們在sign off這些mockup之前會給我們先看一下，所以可能開發(fā)要多考慮下导而，不能按照以前一樣什么都是設(shè)計好了的忱叭，我們得全方位地每一個細(xì)節(jié)地想好，還有什么是她們應(yīng)該考慮而沒有考慮的今艺，也不至于因?yàn)橐粡坢ockup catchup了7韵丑，8次最終才確定。
在與別人家的UX合作方面道路且長且遠(yuǎn)虚缎，也許自己也要想想如何最大限度地避免溝通成本的浪費(fèi)撵彻。
