Theory
પહેલી જ વારમાં કોઈને સાચું પડતું નથી
FestConnect ની તમારી ચકાસણીએ સમસ્યાઓની ક્રમ પ્રમાણેની યાદી આપી. આખા વિષય પાછળ રહેલી નમ્ર બનાવતી સચ્ચાઈ આ રહી: એ સમસ્યાઓ સાવ સામાન્ય છે. કોઈ પણ designer, ભલે ગમે તેટલો સારો હોય, પહેલા જ પ્રયત્નમાં સાચો પડતો નથી. પહેલી design હંમેશાં એક ધારણા જ હોય છે, અને ચકાસણી એને અંશે ખોટી સાબિત કરે છે.
એટલે વ્યાવસાયિક નથી નિરાશ થતો કે નથી બચાવ કરવા બેસતો: એ ફરી આંટો મારે છે. તારીખનું field સુધારો, ફરી ચકાસો, જુઓ કે design સારી થઈ છે પણ હવે કોઈ label લોકોને ગૂંચવે છે, એ સુધારો, ફરી ચકાસો. Iterative design એટલે આ જ ચક્ર, અને દરેક સારું product ખરેખર આ જ રીતે બને છે: પ્રતિભાથી નહીં, પણ આંટા મારીને.
Theory
શિલ્પ કોતરવું, છાપવું નહીં
Printer તૈયાર વસ્તુ એક જ આંટામાં છાપી નાખે છે: file ખોટી હોય તો છાપ પણ ખોટી. એ સીધી લીટીની design છે: એક વાર ઘડો, બહાર પાડો, અને આશા રાખો.
શિલ્પી આંટે આંટે કામ કરે છે: પહેલાં કાચો ઘાટ, પછી પાછળ ખસીને જુએ, સુધારે, ફરી પાછળ ખસે, ફરી સુધારે: પ્રતિમા કરવા અને તપાસવાના વારંવારના ચક્રમાંથી ઊપસી આવે છે. એ iterative design છે. તમે એક જ ટાંકણે ઉત્તમ કૃતિ કોતરી નાખતા નથી; તમે આંટે આંટે એની નજીક પહોંચો છો, અને દરેક આંટો તમે જે જોયું છે એ જ દોરે છે.
Theory
Iterative design, ઔપચારિક રીતે
Iterative design એ ચક્રાકાર, વારંવાર દોહરાતી પ્રક્રિયા છે: ઘડો, પછી prototype બનાવો, પછી વપરાશકારો સાથે ચકાસો, પ્રતિભાવ ભેગો કરો, સુધારો, અને ફરી એ જ. ચક્રનો દરેક આંટો એટલે એક iteration, અને દરેક આંટો design ને પુરાવાના આધારે સુધારે છે.
એ સીધી લીટીની (એક જ ઘાએ પતાવવાની) રીતથી બરાબર ઊલટું છે, જ્યાં તમે એક વાર ઘડીને બહાર પાડી દો છો અને આશા રાખો છો કે ચાલી જશે. Iteration એ સ્વીકારે છે કે પહેલા પ્રયત્નોમાં ખામી હોય જ છે, અને design તથા વપરાશકારોની ખરી જરૂરિયાતો વચ્ચેની ખાઈ ધીમે ધીમે પૂરવા માટે વપરાશકારના પ્રતિભાવ ને એન્જિન તરીકે વાપરે છે.
આ ચક્ર એટલે Unit 1 નો UCD નો ક્રમ કામ કરતો હોય ત્યારે (સમજો, ઘડો, તપાસો, ફરી એ જ): iteration એ જ જગ્યા છે જ્યાં user-centered design ખરેખર બને છે.
Theory
પ્રતિભાવ એ બળતણ છે; નાનું અને વહેલું નિષ્ફળ થાઓ
દરેક આંટાને સુધરવા માટે કશુંક અંદર જોઈએ, અને એ અંદર આવતી વસ્તુ એટલે અનેક સ્રોતોમાંથી મળતો વપરાશકારનો પ્રતિભાવ: usability tests, interviews, analytics, સમીક્ષાઓ, ટેકાની ફરિયાદો, અને A/B tests.
એનો ઊંડો ફાયદો ફેરફારના ખર્ચના વળાંક સાથે જોડાય છે: iteration તમને મોટું અને મોડું નહીં પણ નાનું અને વહેલું નિષ્ફળ થવા દે છે. Prototype ના બીજા આંટામાં પકડાયેલી ખામીની કિંમત એક નાનકડો ફેરફાર છે; એ જ ખામી આખા જાહેર launch પછી પકડાય તો કિંમત ગુમાવેલા વપરાશકારો અને દોડાદોડ છે. સસ્તા અને વારંવાર થતા આંટા સમસ્યાઓને ત્યારે જ પકડી લે છે જ્યારે એ હજી સસ્તી હોય.
અને iteration launch પર અટકતું નથી: ખરાં products કાયમ આંટા મારતાં રહે છે, અને વપરાશકારો વિશે વધુ ને વધુ શીખતાં જઈને સતત સુધરતાં રહે છે.
Quiz
Iterative design ને સૌથી સારી રીતે શું વર્ણવે છે?
- Product ને એક જ વાર સંપૂર્ણ ઘડી નાખવું, અને પછી એમાં કશો ફેરફાર કર્યા વગર બહાર પાડવું
- ઘડવું, ચકાસવું, પ્રતિભાવ ભેગો કરવો અને સુધારવું, એવું વારંવાર દોહરાતું ચક્ર જે દરેક આંટે product ને સુધારે છે
- વપરાશકારો પાસે જ code લખાવવો
- ચકાસ્યા વગર છેલ્લી તારીખ સુધી features ઉમેર્યે રાખવાં
- ફક્ત દેખાવનું પડ ઘડવું અને કામગીરી અવગણવી
Show the answer
ઘડવું, ચકાસવું, પ્રતિભાવ ભેગો કરવો અને સુધારવું, એવું વારંવાર દોહરાતું ચક્ર જે દરેક આંટે product ને સુધારે છે
Iterative design એ ચક્ર છે: ઘડો, prototype બનાવો, વપરાશકારો સાથે ચકાસો, પ્રતિભાવ ભેગો કરો, સુધારો, અને ફરી એ જ, અને દરેક આંટો પુરાવાના આધારે product ને સુધારે છે: એટલે કે શિલ્પીના આંટા, printer નો એક જ ઘા નહીં. વિકલ્પ A એ સીધી લીટીની કે waterfall વાળી ઊલટી રીત છે, જેની જગ્યા લેવા માટે જ iteration છે (પહેલી designs ક્યારેય સંપૂર્ણ હોતી નથી). વિકલ્પ C વપરાશકારના પ્રતિભાવ (જે અંદર આવતી વસ્તુ છે) ને વપરાશકારો પોતે design કરે એની સાથે ગૂંચવે છે (એ તો કરતા નથી). વિકલ્પ D ચકાસવા અને સુધારવાના હાર્દ વગર, છેલ્લી તારીખના દબાણે features ઠાંસવાની વાત કરે છે. વિકલ્પ E એ ભૂલી જાય છે કે iteration આખો અનુભવ સુધારે છે, ફક્ત દેખાવ નહીં. સાર: પુરાવા આધારિત આંટે આંટે સુધારો, કારણ કે પહેલી વારમાં તમને ક્યારેય સાચું પડતું નથી.
Think first
એક સંપૂર્ણ યોજના કરતાં iteration શા માટે ચડિયાતું છે
એક manager કહે છે કે 'ચાલો FestConnect ને શરૂઆતમાં જ સંપૂર્ણ ઘડી નાખીએ, જેથી પછી ક્યારેય બદલવું જ ન પડે અને આ બધો ચકાસણીનો સમય બચી જાય.' આ લોભામણી યોજના ખરેખર વધુ જોખમી અને વધુ મોંઘી શા માટે છે? વિચારીને પછી tap કરો.
Show the answer
કારણ કે 'શરૂઆતમાં જ સંપૂર્ણ' શક્ય જ નથી: ખરેખરા વપરાશકારો એને વાપરે નહીં ત્યાં સુધી એ કેવું વર્તન કરશે એ તમે જાણી શકતા નથી. એટલે એક જ ઘાએ ઘડાયેલી મોટી design પોતાની અંદર ધારણાઓ પકવી લે છે, જે ખામી તરીકે છેક launch પછી જ બહાર આવે છે, જ્યારે સુધારવું સૌથી મોંઘું હોય છે અને વપરાશકારો તો ક્યારના જતા રહ્યા હોય છે.
Iteration એ બગડેલો સમય નથી; એ જોખમનું સંચાલન છે: એક મોટા, મોડા અને મોંઘા સુધારાને બદલે અનેક નાના અને સસ્તા સુધારા (એ જ ફેરફારના ખર્ચનો વળાંક). વિચિત્ર વાત એ છે કે સમય બચાવવા iteration ટાળવાનો પ્રયત્ન સામાન્ય રીતે ઘણો વધુ સમય અને ઘણા વધુ વપરાશકારો ખાઈ જાય છે. પુખ્ત વલણ આ છે: તમે ખોટા પડવાના જ છો; પસંદગી ફક્ત એટલી છે કે એની ખબર સસ્તામાં અને વહેલી પડે, કે મોંઘી પડીને મોડી.
Watch out
Iteration માં થતી ભૂલો
એક જ ઘાએ પતાવેલી design: પહેલી આવૃત્તિને ચકાસ્યા વગર બહાર પાડવી એટલે એમ માની લેવું કે તમને સાચું પડ્યું છે (અને પડ્યું નથી).
પ્રતિભાવ વગર આંટા મારવા: પુરાવા વગર, ફક્ત મત પ્રમાણે ફેરફાર કરવા એ iteration નથી: એ તો ગોળ ગોળ અટકળો છે.
દિશા વગરના આંટા: દરેક આંટાએ ચકાસણીમાંથી નીકળેલી અગ્રતાવાળી સમસ્યાઓ પર જ નિશાન તાકવું જોઈએ અને પછી ફરી ચકાસવું, નહીં કે આડેધડ ફેરફાર કરવા.
Launch પર અટકી જવું: સારાં products બહાર પડ્યા પછી પણ સતત આંટા મારતાં રહે છે.
Design નો બચાવ કરવો: ટીકાને હુમલો નહીં પણ બળતણ ગણો; ધ્યેય વધુ સારું product છે, સાચો ઠરેલો designer નહીં.
Theory
મોટા ભાગના માટે સારું હોવું પૂરતું નથી
Iteration FestConnect ને તમે જેમની સાથે ચકાસ્યું એ વપરાશકારો માટે સરળતાથી ચાલે એ દિશામાં લઈ જાય છે. પણ 'મોટા ભાગના વપરાશકારો માટે ચાલે છે' એ પછી પણ વિકલાંગતા ધરાવતા લોકોને બહાર જ રાખી શકે છે: જેઓ રંગ જોઈ શકતા નથી, અવાજ સાંભળી શકતા નથી, કે mouse વાપરી શકતા નથી. Product ને સૌ કોઈ માટે ચાલતું બનાવવું એ જ હવે પછીનો અનિવાર્ય પાઠ છે: ACCESSIBILITY માટે design કરવું, જે કોઈ વધારાનું જોડાણ નથી પણ સાચું કરવાનો જ એક ભાગ છે. પછી વિષય એક આખા case study સાથે પૂરો થાય છે.
Summary
Key takeaways
- Iterative design એ વારંવાર દોહરાતું ચક્ર છે: ઘડો, prototype બનાવો, ચકાસો, પ્રતિભાવ ભેગો કરો, સુધારો, ફરી એ જ.
- દરેક આંટો design ને પુરાવાના આધારે સુધારે છે; એ સીધી લીટીની, એક જ ઘાએ પતાવવાની રીતથી ઊલટું છે.
- પહેલી designs માં હંમેશાં ખામી હોય છે; વપરાશકારનો પ્રતિભાવ ધીમે ધીમે ખરી જરૂરિયાતો સુધીની ખાઈ પૂરે છે.
- પ્રતિભાવ usability tests, interviews, analytics, સમીક્ષાઓ, ટેકાની ફરિયાદો અને A/B tests માંથી આવે છે.
- Iteration તમને મોટું અને મોડું નહીં પણ નાનું અને વહેલું નિષ્ફળ થવા દે છે (ફેરફારનો ખર્ચ), અને એ launch પછી પણ ચાલુ રહે છે.
- દરેક આંટાએ ચકાસણીમાંથી નીકળેલી અગ્રતાવાળી સમસ્યાઓ પર ધ્યાન આપવું જોઈએ, અને પછી ફરી ચકાસવું.
- યાદ રાખવાની કડી: આંટે આંટે કોતરો, એક જ ઘાએ છાપી ન નાખો.