Ang Lihim sa Mas Mabilis na Mga Prototype? Magtiwala sa Aming Koponan ng Dalubhasa.

Maraming ideya sa produkto ang nagsisimula sa isang simpleng tanong: gagamitin ba ito ng mga tao? Ang paggawa ng ideyang iyon sa isang gumaganang prototype ay maaaring maging mas mahirap kaysa sa inaasahan. Ang mga koponan ay madalas na gumugugol ng masyadong maraming oras sa pagtalakay ng mga tampok, pagpapalit ng disenyo, o pagbuo ng mga bahagi na hindi nakakatulong sa pagpapatunay ng produkto. Tinutulungan ko ang mga negosyo na lumipat mula sa isang maagang konsepto patungo sa isang malinaw, nasusubok na prototype sa pamamagitan ng nakatutok na pagpaplano, praktikal na disenyo, at tuluy-tuloy na pag-unlad. Ang isang prototype ay hindi kailangang isama ang bawat nakaplanong tampok. Kailangan nitong ipakita kung paano gumagana ang pangunahing paglalakbay ng user. ## Magsimula sa layunin ng produkto sisimulan ko sa pamamagitan ng pagtatanong kung ano ang kailangang patunayan ng prototype. Ang layunin ay maaaring: - Subukan ang proseso ng booking - Magpakita ng bagong dashboard sa mga namumuhunan - Suriin kung naiintindihan ng mga user ang isang mobile app - Magpakita ng konsepto ng serbisyo sa mga kasosyo sa negosyo - Mangolekta ng feedback bago ang buong pag-unlad Ang hakbang na ito ay nagpapanatili sa proyektong nakatuon. Ang isang prototype na ginawa para sa pagsubok ng user ay maaaring mangailangan ng mga naki-click na screen. Ang isang prototype na binuo para sa isang teknikal na pagsusuri ay maaaring mangailangan ng gumaganang data at mga pangunahing koneksyon sa system. Ang tamang diskarte ay nakasalalay sa tanong na kailangan mong sagutin. ## Gawing malinaw na daloy ng user ang mga ideya. Maraming naunang konsepto ang naglalaman ng mahabang listahan ng mga feature. Maaaring hindi lahat ng mga ito kailanganin ng mga user sa unang pagsubok. Tumutulong akong ayusin ang ideya sa isang simpleng daloy: 1. Sino ang gumagamit ng produkto? 2. Anong problema ang nagdudulot sa kanila nito? 3. Anong aksyon ang dapat nilang gawin? 4. Anong resulta ang dapat nilang matanggap? 5. Anong feedback ang magpapakita kung gumagana ang daloy? Ang isang praktikal na halimbawa ay isang platform sa pag-book ng klinika. Maaaring kailanganin lang ng unang prototype ang pag-sign in ng pasyente, paghahanap sa doktor, mga available na time slot, kumpirmasyon sa booking, at mga detalye ng appointment. Ang mga tool sa pagbabayad, mga feature ng katapatan, at kumplikadong mga setting ng account ay maaaring maghintay hanggang sa masuri ang pangunahing landas ng booking. Ang diskarte na ito ay nagbibigay sa koponan ng isang bagay na kapaki-pakinabang upang suriin nang hindi masyadong malaki ang maagang pagbuo. ## Piliin ang tamang format ng prototype Iba't ibang layunin ang tumatawag para sa iba't ibang antas ng detalye. Makakatulong ang isang prototype na low-fidelity na subukan ang istraktura ng isang produkto. Maaari itong gumamit ng mga simpleng layout, magaspang na screen plan, at pangunahing nabigasyon. Maaaring ipakita ng isang high-fidelity na prototype ang visual na istilo, tumutugon na gawi, mga anyo, at mga detalye ng pakikipag-ugnayan. Maaaring angkop ito para sa mga panayam ng user, mga presentasyon sa pagbebenta, o mga pagsusuri ng stakeholder. Ang isang functional na prototype ay kinabibilangan ng mga gumaganang elemento tulad ng: - Pagsusumite ng form - Pag-login ng user - Paghahanap at pag-filter - Pangunahing imbakan ng data - Mga koneksyon sa API - Mga pahintulot sa account - Mga layout na madaling gamitin sa device Hindi ko inirerekomenda ang pagbuo ng isang ganap na gumaganang system kapag ang isang naki-click na disenyo ay makakasagot sa parehong tanong. Ang isang mas maliit na prototype ay kadalasang ginagawang mas madaling maunawaan ang feedback. ## Panatilihing konektado ang disenyo at pag-develop Ang mga desisyon sa disenyo ay nakakaapekto sa oras ng pag-develop. Ang mga limitasyon sa pag-unlad ay maaari ding hubugin ang disenyo. Sinusuri ng aking koponan ang magkabilang panig ng proyekto bago magsimula ang trabaho. Tinitingnan namin ang paglalakbay ng user, istraktura ng screen, mga teknikal na pangangailangan, daloy ng data, at posibleng mga panganib. Nakakatulong ito na mabawasan ang mga huling pagbabago na dulot ng mga nawawalang detalye. Halimbawa, maaaring gusto ng isang serbisyo sa paghahatid ng live na mapa, pagsubaybay sa driver, mga mensahe ng customer, at mga update sa order. Maaaring ipakita ng isang prototype ang proseso ng order at mga screen ng status nang hindi kumokonekta sa isang live na sistema ng pagsubaybay. Maaaring subukan ng team kung nauunawaan ng mga customer ang mga update sa status bago magdagdag ng higit pang teknikal na gawain. Ang ganitong uri ng paghihiwalay ay nagpapanatili sa prototype na kapaki-pakinabang nang hindi ginagawang mas malaki kaysa sa kinakailangan. ## Bumuo sa maliliit na punto ng pagsusuri Ang isang prototype ay nagiging mas madaling pagbutihin kapag nirepaso ito ng team nang paunti-unti. Maaaring sundin ng isang karaniwang proyekto ang landas na ito: - Tukuyin ang pangunahing user at layunin ng produkto - Piliin ang mga pangunahing tampok - I-mapa ang paglalakbay ng user - Gawin ang unang istraktura ng screen - Buuin ang visual na disenyo - Buuin ang mga pangunahing pakikipag-ugnayan - Suriin ang prototype sa iyong team - Subukan ito sa isang maliit na grupo ng mga user - Magtala ng feedback at piliin ang mga susunod na pagbabago na pinapanatili kong nakatali ang feedback sa orihinal na layunin. Maaaring kapaki-pakinabang ang isang kahilingan ngunit nakakagambala pa rin sa pangunahing pagsubok. Kapag nangyari ito, itatanong ko kung nakakatulong ba ang pagbabago sa mga user na kumpletuhin ang pangunahing gawain o tinutulungan ang team na matuto ng bago. ## Makipagtulungan sa isang pangkat na malinaw na nakikipag-usap Ang bilis ay hindi nagmumula sa paglaktaw sa komunikasyon. Nagmumula ito sa pagbawas ng kalituhan. Dapat mong malaman: - Ano ang ginagawa ng team - Aling mga feature ang kasama - Anong impormasyon ang kailangan ng team mula sa iyo - Kailan mo masusuri ang trabaho - Paano ire-record ang feedback - Aling mga pagbabago ang maaaring makaapekto sa nakaplanong saklaw Mas gusto ko ang maikli, regular na pag-update kaysa sa mahabang pulong na walang malinaw na resulta. Ang isang nakabahaging listahan ng gawain, simpleng prototype na link, at nakasulat na feedback ay makakatulong sa lahat na manatiling nakahanay. Mayroon ka ring malinaw na talaan ng mga desisyon. Nakakatulong ito kapag maraming tao ang kasangkot sa gawaing produkto, disenyo, marketing, o teknolohiya. ## Gumamit ng feedback bago ang buong pag-unlad Ang isang prototype ay nagbibigay sa mga user ng isang bagay na maaari nilang i-react. Madalas itong lumilikha ng mas mahusay na feedback kaysa sa isang listahan ng tampok o presentasyon. Sa panahon ng pagsubok, naghahanap ako ng mga senyales tulad ng: - Hindi mahanap ng mga user ang susunod na aksyon - Hindi malinaw ang mga label - Humihingi ng masyadong maraming impormasyon ang form - Parang mas matagal ang proseso kaysa sa inaasahan - Hindi nauunawaan ng mga user ang resulta ng produkto - Hindi nilulutas ng hiniling na feature ang pangunahing problema Hindi lahat ng komento ay nangangailangan ng pagbabago sa disenyo. Maaaring mas gusto ng isang user ang ibang kulay, habang maaaring mabigo ang ilang user na mahanap ang parehong button. Tumutulong ako na ihiwalay ang personal na kagustuhan mula sa paulit-ulit na mga isyu sa kakayahang magamit. ## Pumili ng mga tool batay sa proyekto Dapat suportahan ng tool ang layunin, hindi kontrolin ito. Maaaring sapat ang isang tool sa disenyo para sa isang naki-click na konsepto. Ang isang web framework ay maaaring umangkop sa isang browser-based na prototype na nangangailangan ng mga gumaganang pakikipag-ugnayan. Maaaring makatulong ang cross-platform na diskarte kapag ang konsepto ay kailangang tingnan sa parehong mga mobile at desktop device. Ang pagpili ay maaaring depende sa: - Layunin ng prototype - Inaasahang antas ng pakikipag-ugnayan - Magagamit na data ng proyekto - Mga target na device - Pangangailangan para sa pag-unlad sa hinaharap - Mga kasanayan sa koponan - Mga pangangailangan sa badyet at pagpapanatili Ipinapaliwanag ko ang mga pagpipiliang ito sa simpleng wika upang makagawa ka ng praktikal na desisyon nang hindi nangangailangan ng teknikal na background. ## Ang natatanggap mo Ang mga maihahatid ng proyekto ay maaaring mahubog sa iyong mga pangangailangan. Maaaring kabilang sa mga ito ang: - Mga diagram ng daloy ng gumagamit - Mga Wireframe - Mga disenyo ng tumutugon sa screen - Mga link na naki-click na prototype - Mga pangunahing tampok na gumagana - Mga file ng disenyo - Mga teknikal na tala - Mga natuklasan sa pagsubok ng user - Isang iminungkahing plano para sa susunod na yugto ng produkto Ang eksaktong saklaw ay napagkasunduan bago magsimula ang pagbuo. Nagbibigay ito sa iyo ng malinaw na pagtingin sa kung ano ang maaaring ipakita ng prototype at kung ano ang nananatili sa labas ng kasalukuyang proyekto. Ang isang mas mabilis na prototype ay hindi lamang isang mas maliit na bersyon ng isang tapos na produkto. Ito ay isang nakatutok na paraan upang subukan ang isang ideya, ilantad ang mga mahihinang punto, at lumikha ng isang nakabahaging pag-unawa sa mga taong kasangkot. Kapag nagtatrabaho ako sa isang team ng produkto, tumutuon ako sa tanong sa likod ng build: ano ang kailangan nating matutunan mula sa prototype na ito? Ang tanong na iyon ay gumagabay sa mga feature, disenyo, tool, at plano sa pagsubok. Tinutulungan nito ang koponan na gumugol ng oras sa kapaki-pakinabang na ebidensya sa halip na bumuo ng mga screen na hindi sumusuporta sa isang malinaw na desisyon. Ibahagi ang iyong ideya sa produkto, i-target ang mga user, at pangunahing layunin. Maaari naming hubugin ang prototype sa paligid ng pangunahing paglalakbay ng gumagamit at tukuyin ang isang praktikal na landas mula sa konsepto hanggang sa masusubok na produkto.

Maraming ideya sa produkto ang mukhang kapaki-pakinabang kapag nananatili sila sa pag-uusap. Magsisimula ang tunay na pagsubok kapag nakikita, nahawakan, at nagagamit ng mga tao ang gumaganang bersyon. Madalas kong nakikita ang mga koponan na gumugugol ng mga linggo sa pagpapakintab ng mga plano bago subukan ng sinuman ang ideya. Sa oras na iyon, ang proyekto ay maaaring magsama ng mga tampok na hindi kailangan ng mga gumagamit, habang ang pangunahing problema ay nananatiling hindi malinaw. Maaaring ipakita ng isang simpleng prototype ang mga puwang na ito nang mas maaga, na may mas kaunting oras at mas kaunting mapagkukunan. Ang isang prototype ay hindi kailangang maging perpekto. Kailangan nitong ipakita kung paano gumagana ang ideya. Magsimula sa isang problema ng gumagamit Isulat ang problema sa isang pangungusap: "Kailangan ko ng mas simpleng paraan upang ___ dahil ___." Pinapanatili nitong nakatutok ang proyekto. Halimbawa, maaaring hindi kailanganin ng isang team ng paghahatid ng pagkain na muling idisenyo ang buong app nito. Ang tunay na problema nito ay maaaring hindi madaling baguhin ng mga customer ang mga tagubilin sa paghahatid pagkatapos maglagay ng order. Ang nag-iisang isyu na iyon ay nagbibigay sa koponan ng isang malinaw na lugar upang magsimula. Piliin ang pinakamaliit na kapaki-pakinabang na daloy Ang isang prototype ay dapat sumaklaw sa isang maikling paglalakbay ng user. Maaaring kabilang dito ang: - Pagbubukas ng produkto - Paghahanap ng isang pangunahing tampok - Paggawa ng isang aksyon - Pagkita ng resulta Alisin ang mga karagdagang page, setting, at feature na hindi sumusuporta sa daloy na ito. Ang layunin ay hindi ipakita ang lahat ng maaaring maging produkto. Ang layunin ay upang malaman kung ang pangunahing karanasan ay may katuturan. Sketch bago magtayo Karaniwan akong nagsisimula sa magaspang na mga screen sa papel, isang whiteboard, o isang simpleng tool sa disenyo. Sa yugtong ito, mas mahalaga ang bilis kaysa sa visual na detalye. Gumawa ng ilang posibleng mga layout. Ihambing ang mga ito nang magkatabi. Itanong: - Maiintindihan ba ng isang bagong user ang susunod na hakbang? - Ang pangunahing aksyon ba ay madaling mahanap? - Sinasagot ba ng bawat screen ang isang malinaw na tanong? - Ano ang maaaring alisin? Ang isang magaspang na sketch ay nagpapadali sa talakayan. Ang mga miyembro ng koponan ay maaaring tumuro sa isang screen at magmungkahi ng pagbabago sa halip na pagdedebatehan ang isang ideya na umiiral lamang sa mga salita. Bumuo ng sapat na detalye para sa isang tunay na tugon Kapag malinaw na ang daloy, ikonekta ang mga pangunahing screen sa isang naki-click na prototype. Gumamit ng mga makatotohanang label at sample na nilalaman kung posible. Ang isang button na nagsasabing "Magpatuloy" ay maaaring hindi gaanong sabihin sa iyo. Ang isang button na nagsasabing "I-save ang mga tagubilin sa paghahatid" ay nagbibigay sa mga user ng mas malinaw na gawain. Ang prototype ay maaari pa ring gumamit ng sample na data. Hindi nito kailangan ng buong database, sistema ng pagbabayad, o code ng produksyon sa yugtong ito. Subukan ang ilang target na user Mag-imbita ng mga taong tumutugma sa nilalayong madla ng produkto. Bigyan ang bawat tao ng simpleng gawain nang hindi ipinapaliwanag ang bawat hakbang. Halimbawa: "Ipakita sa akin kung paano mo babaguhin ang mga tagubilin sa paghahatid para sa isang order na darating bukas." Panoorin kung ano ang mangyayari. Bigyang-pansin ang mga pag-pause, maling pag-click, tanong, at komento. Maaaring sabihin ng isang user, "Madali lang ito," habang naghahanap ng tamang button sa loob ng ilang segundo. Ang kanilang mga aksyon ay kadalasang nagbibigay ng mas kapaki-pakinabang na impormasyon kaysa sa kanilang magalang na feedback. Magtanong ng mga bukas na tanong pagkatapos ng gawain: - Ano ang inaasahan mong mangyayari dito? - Anong bahagi ang nadama na hindi malinaw? - Ano ang babaguhin mo? - Makakatulong ba ito sa problemang inilarawan mo? Iwasang akayin ang tao patungo sa isang positibong sagot. Ang matapat na pagkalito ay maaaring magligtas sa isang koponan mula sa pagbuo ng maling solusyon. Gumamit ng feedback upang gumawa ng mga nakatutok na pagbabago Huwag baguhin ang bawat detalye pagkatapos ng isang komento. Maghanap ng mga pattern. Kung maraming tao ang makaligtaan ang parehong aksyon, maaaring kailanganin ng layout. Kung nauunawaan ng mga user ang daloy ngunit walang pakialam sa feature, maaaring nilulutas ng produkto ang mahinang problema. Kung humingi sila ng feature na sumusuporta sa pangunahing gawain, ilagay ito sa susunod na bersyon ng prototype. Panatilihin ang isang maikling talaan ng bawat pagsubok: - Ano ang sinubukang gawin ng user - Kung saan nag-pause ang user - Ano ang inaasahan ng user - Ano ang planong baguhin ng team Ang talaan na ito ay tumutulong sa paghiwalayin ang mga personal na opinyon mula sa paulit-ulit na gawi ng user. Alamin kung kailan lampas sa prototype Nagawa na ng isang prototype ang trabaho nito kapag naiintindihan ng team ang pangunahing daloy ng user, ang pinakamalaking punto ng kalituhan, at ang mga tanong na nangangailangan pa rin ng mga sagot. Lumipat patungo sa pag-unlad kapag: - Ang pangunahing problema ay may malinaw na suporta mula sa feedback ng user - Ang pangunahing daloy ay madaling ipaliwanag - Alam ng team kung aling mga feature ang kailangan para sa unang release - Nasuri ang mga teknikal na limitasyon - Ang gastos at saklaw ay umaangkop sa kasalukuyang plano Ang isang prototype ay hindi patunay na magtatagumpay ang isang produkto. Ito ay isang praktikal na paraan upang bawasan ang panghuhula bago magsimula ang higit pang gawain. Nakita ko ang mga koponan na nakakuha ng higit pa mula sa isang simpleng naki-click na daloy kaysa sa isang mahabang dokumento ng tampok. Natututo sila kung saan nag-aalangan ang mga user, kung aling mga salita ang nagdudulot ng kalituhan, at kung ano ang hindi dapat ilabas sa unang release. Gawing bagay ang ideya na maaaring gamitin, subukan, at talakayin ng mga tao. Ang isang maliit na prototype ay maaaring magbigay sa iyong koponan ng isang mas malinaw na landas nang hindi ka pinipilit na buuin ang buong produkto nang sabay-sabay.

Ang isang magandang prototype ay hindi kailangang magmukhang tapos na. Kailangan nitong tulungan akong sagutin ang mga tamang tanong sa produkto bago ako gumugol ng oras at pera sa pagpapaunlad. Maraming team ang nagsisimula sa mga pinakintab na screen, mga detalyadong feature, at mahabang cycle ng pag-apruba. Pagkatapos ng paglunsad, maaari nilang matuklasan na ang mga user ay hindi makakahanap ng pangunahing aksyon, hindi nauunawaan ang halaga ng produkto, o mas gusto ang isang mas simpleng landas. Ang isang prototype ay nagbibigay sa akin ng isang paraan upang subukan ang mga puntong ito nang mas maaga, kapag ang mga pagbabago ay mas madaling gawin. ## Magsimula sa isang problema ng user Sisimulan ko sa pagsulat ng isang malinaw na pangungusap: "Kailangan ng aking user na ______ dahil ______." Halimbawa: "Kailangan ng aking user na ihambing ang mga opsyon sa paghahatid dahil nakakalito ang pagpili sa pagitan ng presyo at bilis." Ang pahayag na ito ay nagpapanatili sa prototype na nakatuon. Kung susubukan kong lutasin ang limang problema nang sabay-sabay, ang pagsubok ng gumagamit ay nagiging mahirap basahin. Maaari akong mangolekta ng maraming komento nang hindi nalalaman kung aling isyu ang higit na nakakaapekto sa produkto. Ang isang nakatutok na prototype ay maaaring sumaklaw sa isang maikling gawain, tulad ng: - Paglikha ng isang account - Pag-book ng appointment - Paghahambing ng mga plano ng serbisyo - Pag-upload ng isang dokumento - Pagsuri ng katayuan ng order ## Piliin ang tamang antas ng detalye Maaaring sagutin ng isang paper sketch ang mga tanong tungkol sa istraktura at daloy. Maaaring ipakita ng naki-click na wireframe kung paano gumagalaw ang mga tao sa pagitan ng mga screen. Makakatulong ang isang high-fidelity na prototype sa pagsubok ng layout, mga salita, visual hierarchy, at mga detalye ng pakikipag-ugnayan. Hindi ako gumagamit ng detalyadong visual na disenyo kapag ang isang simpleng sketch ay makakasagot sa tanong. Ang isang kapaki-pakinabang na panuntunan ay: - Gumamit ng mababang detalye upang subukan ang ideya - Gumamit ng katamtamang detalye upang subukan ang daloy - Gumamit ng mataas na detalye upang subukan ang karanasan Pinapanatili nitong konektado ang gawain sa desisyon na kailangan kong gawin. Binabawasan din nito ang panganib ng pagpapakintab ng screen na maaaring maalis sa ibang pagkakataon. ## I-map ang pinakamaikling kapaki-pakinabang na landas na isinusulat ko sa paglalakbay ng gumagamit bago idisenyo ang bawat screen. Para sa isang serbisyo sa pag-book, maaaring ganito ang hitsura ng landas: 1. Pumili ng serbisyo 2. Pumili ng petsa 3. Suriin ang presyo 4. Kumpirmahin ang booking 5. Makatanggap ng mensahe ng kumpirmasyon Dapat na may kasamang sapat na detalye ang path para makumpleto ng user ang gawain. Maaaring maghintay ang mga karagdagang menu, setting, at side feature. Kapag sinusuri ko ang daloy, itatanong ko: - Sinusuportahan ba ng bawat screen ang gawain? - Alam ba ng user kung ano ang susunod na gagawin? - Maaari bang bumalik ang gumagamit nang hindi nawawala ang pag-unlad? - Madaling mahanap ba ang mga presyo, petsa, at pangunahing kondisyon? - Ano ang mangyayari kapag nagkamali ang user? Ang mga tanong na ito ay madalas na nagpapakita ng mga puwang bago maabot ng prototype ang isang customer. ## Gumamit ng malinaw na nilalaman bago ang visual polish na Lorem ipsum ay nagtatago ng mga problema. Gumagamit ako ng maikli, makatotohanang teksto na nagpapakita ng produkto. Sa halip na isulat ang "Isumite," maaari kong isulat ang "Magpadala ng kahilingan sa appointment." Sa halip na "Pagpipilian A," maaari kong isulat ang "Karaniwang paghahatid - 3 hanggang 5 araw." Tinutulungan ako ng mga malinaw na label na subukan kung naiintindihan ng mga tao ang produkto. Inilalantad din nila ang mga isyu sa layout. Ang isang button na mukhang maayos sa dalawang salita ay maaaring maging mahirap gamitin sa mas mahaba, mas kapaki-pakinabang na label. Dapat sagutin ng nilalaman ang mga pangunahing tanong ng gumagamit: - Ano ito? - Ano ang maaari kong gawin dito? - Ano ang susunod na mangyayari? - Ano ang babayaran ko? - Maaari ko bang baguhin o kanselahin ang pagkilos? ## Pagsubok sa isang maliit na grupo Hindi ko kailangan ng malaking proyekto ng pananaliksik upang mahanap ang mga pangunahing problema sa kakayahang magamit. Maaari kong hilingin sa ilang tao na tumutugma sa target na madla na kumpletuhin ang isang gawain nang walang detalyadong tagubilin. Maaaring kasama sa isang simpleng session ang: "Mangyaring mag-book ng serbisyo para sa susunod na Martes at sabihin sa akin kung ano ang inaasahan mong mangyari pagkatapos mong kumpirmahin." Tinitingnan ko kung saan nag-pause ang tao, nag-tap sa maling kontrol, humihingi ng tulong, o sumuko. Iniiwasan kong ipaliwanag ang screen nang masyadong maaga dahil ang aking paliwanag ay maaaring magtago ng problema na kakaharapin ng mga susunod na user. Pagkatapos ng session, itinala ko ang: - Tinangka ang gawain - Ang punto ng kalituhan - Ang mga salitang ginamit ng gumagamit - Ang aksyon na inaasahan ko - Ang aksyon na ginawa ng gumagamit - Isang posibleng pagbabago sa disenyo Ang isang paghinto ay kapaki-pakinabang na ebidensya. Gayundin ang isang tanong tulad ng, "Ito na ba ang huling presyo?" Sinasabi nito sa akin na ang screen ay maaaring hindi magbigay ng sapat na impormasyon. ## Pagbukud-bukurin ang feedback ayon sa epekto ng produkto Hindi lahat ng komento ay nangangailangan ng pagbabago sa disenyo. Maaaring mas gusto ng isang tao ang ibang kulay. Maaaring mabigo ang ilang tao na mahanap ang pangunahing aksyon. Ang mga isyung ito ay hindi dapat tumanggap ng parehong atensyon. Nagpangkat ako ng feedback sa tatlong bahagi: Pagkabigo sa gawain Hindi makumpleto ng user ang pangunahing aksyon. Task friction Makukumpleto ito ng user, ngunit parang mabagal o nakakalito ang landas. Personal na kagustuhan Ang user ay nagmumungkahi ng pagbabago na hindi makakaapekto sa tagumpay ng gawain. Tinutugunan ko ang pagkabigo sa gawain bago ang mga visual na kagustuhan. Nakakatulong ito sa team na gumugol ng oras sa disenyo at pagbuo sa mga isyu na nakakaapekto sa paggamit ng produkto. ## Bumuo, sumubok, at mag-adjust sa mga maikling cycle Itinuturing ko ang isang prototype bilang isang gumaganang tanong, hindi isang panghuling sagot. Maaaring ganito ang hitsura ng isang cycle: 1. Tukuyin ang isang tanong sa produkto 2. Lumikha lamang ng mga screen na kailangan upang subukan ito 3. Hilingin sa mga target na user na kumpletuhin ang isang gawain 4. Magtala ng mga aksyon at komento 5. Baguhin ang daloy o nilalaman 6. Subukan ang binagong bersyon Halimbawa, maaaring subukan ng isang app sa pananalapi kung naiintindihan ng mga tao ang isang buod ng paggasta. Ang koponan ay maaaring gumawa ng dalawang bersyon ng parehong screen. Gumagamit ang isa ng buwanang kabuuan sa itaas. Ang iba ay nagpapakita muna ng mga detalye ng kategorya. Maaaring ipakita ng mga session ng user kung aling layout ang nakakatulong sa mga tao na sagutin ang, "Saan napunta ang pera ko ngayong buwan?" Hindi kailangang patunayan ng pagsubok kung aling disenyo ang perpekto. Kailangan nitong ipakita kung aling direksyon ang nararapat ng higit pang trabaho. ## Panatilihing konektado ang disenyo at pagpapaunlad Ang isang prototype ay makakatipid lamang ng oras kapag ang mga natuklasan nito ay umabot sa mga taong gumagawa ng produkto. Ibinabahagi ko ang gawain ng user, mga tala sa pagsubok, daloy ng screen, at mga bukas na tanong sa mga taga-disenyo, developer, tagapamahala ng produkto, at mga team ng suporta. Maaaring kabilang sa maikling handoff ang: - Ang layunin ng prototype - Ang nasubok na gawain ng user - Ang mga pangunahing punto ng friction - Ang mga naaprubahang pagbabago - Mga tanong na nangangailangan pa rin ng ebidensya - Mga detalye na hindi bahagi ng kasalukuyang saklaw Binabawasan nito ang mga pagpapalagay. Makikita ng isang developer kung bakit nagbago ang isang hakbang. Maaaring maghanda ang isang team ng suporta para sa mga tanong na maaaring lumabas pagkatapos ilabas. ## Iwasan ang shortcut na lumilikha ng mas maraming trabaho Ang pinakamabilis na paraan ay madalas na buuin ang lahat bago makipag-usap sa mga user. Ang landas na iyon ay maaaring makagawa ng isang pinakintab na produkto na may mahinang daloy. Nalaman ko na ang isang simpleng naki-click na prototype ay kadalasang nagbibigay ng mas mahusay na direksyon kaysa sa isang mahabang feature na dokumento. Maaaring ilarawan ng isang dokumento kung ano ang dapat gawin ng isang produkto. Ang isang prototype ay nagbibigay-daan sa mga tao na tumugon sa kung ano talaga ang kanilang gagawin. Ang layunin ay hindi lumikha ng higit pang mga screen. Ang layunin ay upang matuto nang sapat upang makagawa ng isang mahusay na desisyon sa produkto. Ang isang malakas na proseso ng prototyping ay nagpapanatili sa gawain ng user na maliit, malinaw ang mga tanong, at malapit ang feedback sa gawaing disenyo. Mas mabilis akong gumagalaw kapag sinubukan ko ang mga mapanganib na bahagi nang maaga, gumamit ng simpleng nilalaman, at binago lamang kung ano ang sinusuportahan ng ebidensya. Makipag-ugnayan sa amin sa lingchao: mr.xu@lingchaopcb.com/WhatsApp +8613780181891.

1. Steve Krug, 2000, Don't Make Me Think: A Common Sense Approach to Web Usability 2. Eric Ries, 2011, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radially Successful Businesses 3. Jakob Nielsen, 1993, Usability Engineeringf4 at Jo.2. UX: Applying Lean Principles to Improve User Experience 5. Clayton M Christensen, Taddy Hall, Karen Dillon and David S Duncan, 2016, Know Your Customers' Jobs to Be Done 6. Donald A Norman, 2013, The Design of Everyday Things