Dezvoltatorii „dețin” codul, deci designerii nu ar trebui să „dețină” experiența?

Publicat: 2022-03-10
Rezumat rapid ↬ Am fost cu toții acolo. Ați petrecut luni de zile culegând cerințele de afaceri, pregătind călătorii complexe ale utilizatorilor, creând elemente de interfață de precizie și testându-le pe un eșantion reprezentativ de utilizatori, doar pentru a vedea un produs final care seamănă puțin cu experiența dorită.

Cu toții am fost acolo. Ați petrecut luni de zile culegând cerințele de afaceri, pregătind călătorii complexe ale utilizatorilor, creând elemente de interfață de precizie și testându-le pe un eșantion reprezentativ de utilizatori, doar pentru a vedea un produs final care seamănă puțin cu experiența dorită .

Poate că ar fi trebuit să fii mai puternic și să insisti pe o abordare agilă, în ciuda credinței tale că organizația nu era pregătită? Poate că ar fi trebuit să faceți o treabă mai bună cu portofoliile dvs. de modele, asigurându-vă că dezvoltatorii v-au folosit biblioteca de coduri modulare în loc să creeze cinci variante diferite ale unui carusel. Sau, poate chiar ar fi trebuit să stați lângă echipa de dezvoltare în fiecare zi, asigurându-vă că ceea ce ați proiectat sa realizat.

Citiți suplimentare despre SmashingMag:

  • De ce ar trebui să includeți dezvoltatorul dvs. în procesul de proiectare
  • Colaborarea în echipă și eliminarea lacunelor de eficiență în proiectarea receptivă
  • Designeri și dezvoltatori care joacă frumos
  • Cum să comunicați eficient cu dezvoltatorii

În schimb, ai rămas cu un amestec de elemente UI, cu toată subtilitatea eliminată. Nu au putut vedea că ai lucrat zile întregi pentru a obține tranzițiile corecte, doar pentru ca ei să intre într-o bibliotecă de animație implicită? Și de unde naiba a venit acel pas suplimentar de check-out. Pun pariu că marketingul a aruncat asta în ultimul moment. Știai că integrarea va fi grea și ar trebui făcute compromisuri, dar ar trebui să facem viața mai ușoară a utilizatorilor aici, nu a echipei de tehnologie.

Mai multe după săritură! Continuați să citiți mai jos ↓
Când mulți oameni sunt implicați într-un proiect, este foarte important să vă asigurați că au o înțelegere comună a problemei și a soluției acesteia.
Când mulți oameni sunt implicați într-un proiect, este foarte important să vă asigurați că au o înțelegere comună a problemei și a soluției acesteia. (Credit imagine: The Next Web)

Desigur, există o mulțime de motive bune pentru care site-ul este astfel. Echipe diferite cu niveluri diferite de abilități care lucrează pe diferite părți ale proiectului, o grămadă de modificări de ultimă oră care scurtează ciclul de dezvoltare și o serie întreagă de provocări tehnice. Totuși, de ce nu a putut veni echipa de dezvoltare să vă ceară sfatul cu privire la modificările UI? Nu te încurci cu codul lor, așa că de ce trebuie să-ți schimbe design-urile? Mai ales când impactul afacerii ar putea fi uriaș! Ești doar după colț și ai fi fost bucuros să ajuți dacă tocmai ar fi cerut.

În timp ce povestea de mai sus poate fi fictivă, este un sentiment pe care îl aud din toate colțurile lumii designului, fie în interior, fie în agenție. O experiență creată cu grijă, ruinată de o echipă de dezvoltare cu mâini grele.

Această experiență îmi amintește de o știre pe care am văzut-o pe un canal de știri local din SUA în urmă cu câțiva ani. Un târg județean desfășura o competiție de anduranță în care ultima persoană rămasă cu mâna pe o camionetă a câștigat premiul. Adesea cred că designul este ca un joc masiv de „atinge camionul” , cu echipa de dezvoltare mereu plecând cu cheile la sfârșitul concursului. La fel ca ultimul cuvânt dintr-o ceartă, ultima persoană care intră în contact cu site-ul deține toată puterea și poate dicta cum funcționează sau cum arată. Mai ales dacă ei susțin că experiența țintă nu este „posibilă din punct de vedere tehnic”, ceea ce este adesea prescurtare pentru „foarte dificil”, „Nu mă deranjează să o fac așa” sau „Cred că există o modalitate mai bună de a face asta”. așa că o să trag cardul de dezvoltare”.

Acum știu că sunt nedrept de dur cu dezvoltatorii de aici și nu vreau să fiu. Există niște tehnologi uimitor de talentați, cărora le pasă cu adevărat de utilizare și doresc să facă tot ce este mai bun pentru utilizator. Cu toate acestea, de multe ori se simte ca și cum există un nivel asimetric de respect între discipline datorită credinței că designul este ușor și, prin urmare, ceva despre care toată lumea poate avea o părere, în timp ce dezvoltarea este grea și numai pentru cei special inițiați. Deci, în timp ce designerii sunt încurajați (uneori de așteptat) să implice pe toată lumea în procesul de proiectare, adesea nu li se oferă același lux.

Sincer să fiu, nu-i dau vina pe ei. La urma urmei, știu doar destulă dezvoltare pentru a fi periculoasă, așa că ai fi un idiot dacă ai vrea părerea mea despre structura bazei de date și performanța codului (în afară de ceea ce cred că performanța este un lucru bun). Apoi, din nou, știu destule pentru a spune când dezvoltatorii înșelează lucrurile și este întotdeauna distractiv să revin la ei cu un prototip funcțional a ceva despre care au spus că este imposibil sau durează luni de zile să fie implementat - dar mă opresc.

Problema este că cred că mulți dezvoltatori sunt în aceeași poziție în ceea ce privește designul - pur și simplu nu își dau seama. Așadar, atunci când efectuează o modificare a unui element de interfață pe baza a ceva ce au auzit la o conferință cu câțiva ani în urmă, este posibil să le lipsească un context important. Poate că acesta a fost ceva pe care l-ați testat și ați redus deja, deoarece a funcționat slab. Poate ați ales acest element în locul altuia dintr-un motiv anume, cum ar fi accesibilitatea? Sau poate că opiniile dezvoltatorilor au fost pur și simplu greșite, pe baza modului în care experimentează web-ul ca superutilizatori, mai degrabă decât ca un Jo obișnuit.

Acum să clarificăm ceva aici. Nu spun că dezvoltatorii nu ar trebui să-și arate interesul pentru design sau contribuții în procesul de proiectare. Cred ferm în perechea interfuncțională și cred că unele dintre cele mai bune soluții de utilizare provin din echipa de tehnologie . Există, de asemenea, o mulțime de oameni talentați care se întind pe o multitudine de discipline. Cu toate acestea, la un moment dat, experiența trebuie să fie deținută și nu cred că ar trebui să fie deținută de ultima persoană care deschide fișierul HTML și „atinge camionul”.

Așadar, dacă designerii buni respectă abilitățile și experiența pe care dezvoltatorii mari o aduc la masă, ce zici de puțină paritate? Dacă designerii sunt fericiți că dezvoltatorii „dețin codul”, de ce să nu arate un grad similar de respect și să-i lași pe designeri să „dețină experiența” ?

Comunicarea este cheia, deci fii disponibil.
Toată lumea are o părere. Cu toate acestea, nu este un motiv suficient de bun pentru a te scufunda și a începe să faci schimbări. Credit imagine: Open Source Way

A face acest lucru este destul de simplu. Dacă vă aflați vreodată într-o situație în care nu sunteți sigur de ce ceva a fost proiectat într-un anumit mod și credeți că s-ar putea face mai bine, nu vă aruncați și începeți să faceți modificări . În mod similar, dacă ați lovit un obstacol tehnic și credeți că v-ar ușura viața să proiectați ceva într-un mod diferit, discutați cu designerul dvs. S-ar putea să fie absolut în regulă cu modificările propuse de dvs. sau ar putea dori să plece și să se gândească la alte modalități de a rezolva aceeași problemă.

La urma urmei, colaborarea merge în ambele sensuri. Deci, dacă nu doriți ca designerii să înceapă să „optimizeze” codul dvs. pe serverul live, în afara proceselor de control al versiunilor, vă rugăm să nu mai faceți același lucru cu designul lor.