Jump to content
SynTAX

Usable Software Design

Recommended Posts

  • Active Members

Ori de câte ori vorbim despre design în alte domenii decât software-ul, discut?m din punct de vedere orientat c?tre utilizator. Produsele Apple sunt renumite pentru c? se concentreaz? pe experien?a utilizatorului cu dispozitivul: cum se simte, cum arat?, cât de repede r?spunde, sunetele pe care le scoate, etc. .

Software Design-ul este singurul tip de design care pare s? nu aib? utilizator. La urma urmei utilizatorul final nu are nici o idee despre cum este organizat? aplica?ia pe care o folose?te ?i nici m?car nu-i pas?. Tot ce conteaz? pentru el este ca aceasta s? func?ioneze bine.

...

Software Design-ul are un utilizator: programatorul care va trebui s? schimbe codul scris de echipa ta. Dac? folosi?i collective code ownership (ca majoritatea echipelor Scrum), ar fi bine s? lua?i în considerare user-centric software design (software design orientat c?tre utilizator).

Idei precum "Clean Code" ating aceast? abordare dar nu o dezvolt?. În continuare, a? vrea s? explorez acest subiect în detaliu.

1. Dezvoltatorii noi care lucreaz? cu Usable Software Design vor deveni mai productivi mai repede

De ce este gradul de u?urin?? în folosire al aplica?iilor web un subiect atât de important ast?zi? A? argumenta c? motivul îl constituie avantajul competitiv pe care îl aduce, deoarece utilizatorii g?sesc mult mai u?or s? înceap? s? foloseasc? o aplica?ie care este construit? având utilizatorul în minte. Niciun utilizator nu are timp s? înve?e un produs nou; vrem s? începem s? îl folosim imediat ?i s? ne aduc? beneficii instant.

Noii utilizatori ai software design-ului sunt noii dezvoltatori care se al?tur? echipei. Vom presupune c? ?tiu limbajul de programare, framework-ul principal utilizat ?i au lucrat în domeniul business înainte. Cât timp le ia s? devin? productivi în mediul vostru? Timpul petrecut îi familiarizeaz? cu designul aplica?iei ?i cu modul în care lucrurile se fac în mare parte, dar se traduce prin cheltuieli. În termenii produsului, se nume?te pierdere.

2. Cerin?ele cele mai comune sunt implementate mult mai rapid cu Usable Software Design

Gânde?te-te la tipul de activit??i desf??urate pe produsul curent. ?ansele sunt ca multe dintre ele s? fie repetitive.

În aplica?ia de eHealth pe care o dezvolt?m, primele func?ionalit??i au luat ceva timp pentru a fi implementate (NB: în acela?i timp înv???m ?i o nou? tehnologie). Privind atent la ceea ce ne-a încetinit lucrul ?i ajustând designul, am optimizat dezvoltarea ?i am ajuns la punctul în care aproximativ 60% din munca este UI / UX design. Acum, dezvoltarea nu mai are bottleneck. Ne-am uitat apoi la optimizarea activit??ilor de UI / UX, dar asta e alt? poveste.

Cheia acestei îmbun?t??iri a stat în faptul c? privind în urm?, ne-am dat seama c? dezvoltam func?ionalit??i care corespund câtorva tipuri de munc?:

  • Ad?ugarea unei noi activit??i aplicat? pe situa?ia medical? a pacientului:create, display, change, hide;
  • Legarea unei entit??i medicale de o intrare în jurnalul pacientului;
  • Afi?area unui istoric filtrat dup? diverse criterii; Etc...

Din moment ce ?tiam din roadmap-ul proiectului c? vor ap?rea din nou astfel de cerin?e, am început optimizarea pentru aceste tipuri de munc?. Ocazional, trebuia s? facem un nou tip de munc? care dura mai mult. Un exemplu a fost un serviciu de c?utare a unui medicament, care este rapid, scalabil ?i u?or de modificat pentru a func?iona corect cu ultima versiune a bazei de date de medicamente. A trebuit s? înv???m s? folosim vertx ?i mongodb pentru a face lucrul acesta, ?i ne-a luat de 3-5 ori mai mult timp decât o sarcin? normal?. Deoarece aceasta este o situa?ie local?, care este pu?in probabil s? se repete, nu am f?cut nimic pentru a optimiza.

Ideea este: ca o aplica?ie care este u?or de folosit pentru taskuri mai comune, Usable Software Design permite implementarea rapid? a celor mai frecvente tipuri de caracteristici.

Acestea sunt principalele beneficii pe care le v?d pentru Usable Software Design. Dar cum s?-l ob?inem? Primul lucru este ...

3. M?soar? ?i îmbun?t??e?te

Procesul pe care l-am folosit pentru a face designul mai opera?ional a fost destul de simplu:

  • m?soar? cât timp este nevoie pentru a implementa fiecare caracteristic?;
  • discut? devia?iile la retrospectiv?;
  • identific? ce ne împiedic? s? mergem mai repede;
  • define?te ?i pune în aplicare modific?rile;
  • repet?.

Noi folosim un proces Kanban / XP, a?a c? am folosit the cycle time distribution diagram ?pentru a identifica punctele de devia?ie. Avem o retrospectiv? recurent? la fiecare dou? s?pt?mâni în care discut?m impedimentele ?i identific?m solu?iile. Implementarea a fost f?cut? în urm?toarele dou? s?pt?mâni, ?i ne-am p?strat un ochi la cycle time distribution în urm?toarele luni. A fost u?or s? vedem îmbun?t??irile deoarece majoritatea task-urilor s-au mutat la stânga.

a31.jpg

Într-un context Scrum, echipele nu m?soar? cycle time, doar viteza. Problema este c? viteza este un indicator agregat pentru toate func?iile implementate pe durata sprintului. Prin urmare, echipele Scrum au dou? op?iuni pentru a ajunge la usable software design:

  • Cantitativ?: începe m?surarea timpului efectiv petrecut pe user story;
  • Calitativ?: executa o retrospectiv? recurent? pe tema de usable design. Întreab? developer-ii ce le ia mai mult timp decât ar trebui. Într-o echip? în care exist? încredere ?i transparen??, ve?i identifica imediat problemele.

Aceasta este metoda de baz? pentru a ob?ine usable software design. Metoda avansat? este preluat? din practicile de usability.

4. Ruleaz? teste de usability pe Software Design-ul t?u

Testele de usability pot fi rulate în mai multe moduri. Am g?sit totu?i un format care se potrive?te cel mai bine pentru Software Design:

  • Noteaz? o list? de task-uri pe care utilizatorul trebuie s? le execute.
  • Adu într-o camer? utilizatori care nu au v?zut niciodat? produsul ( sau p?r?i ale produsului pe care vrei s? le testezi).
  • Cere-le s? execute task-urile.
  • M?soar? cât timp le ia s? fac? asta. Noteaz?-?i unde se blocheaz?.
  • Folose?te feedbackul pentru a îmbun?t??i produsul.

Iat? câteva exemple de task-uri comune pentru o aplica?ie web:

  • adaug? un nou formular cu un câmp text ?i un buton save;
  • adaug? validari suplimentare unui câmp;
  • schimb? textul unei etichete (pentru o limb? sau toate limbile suportate);
  • adaug? o nou? regul? de business;
  • afi?eaz? o list? de entit??i într-o pagin?. Etc...

Enumer?m câteva lucruri importante de ?tiut despre teste de usability:

  • Asigur?-te c? le spui participan?ilor c?, dac? nu ?tiu s? fac? ceva, este vina designului, nu a lor. Încurajeaz?-i s? pun? întreb?ri când se blocheaz?.
  • Un test complet cu o singur? persoan? n-ar trebui s? dureze mai mult de o or?.
  • Începe cu task-urile cele mai comune întâi ?i cu cât mai pu?in? informa?ie posibil?. Ofer? informa?ie doar atunci când cineva se blocheaz? ?i cere ajutor.
  • Preg?te?te cam zece task-uri, dar a?teapt?-te s? finalizezi mai pu?ine.

Acum ?tim cum s? identific?m probleme. Sunt sigur c? urm?toare întrebare este...

5. Cum arat? Usable Software Design?

Pentru început men?ionez c? ideea de a se centra pe developer, ca utilizator al Software Design-ului, este foarte nou?. Am v?zut discu?ii oarecum în jurul acestui topic, ?i am contribuit ?i eu la unele. Literatura din trecut despre Software Design a atins acest subiect, dar nu în mod explicit.

Exist? totu?i foarte mult? literatur? despre usability. Voi men?iona doar trei principii de baz? ale usability-ului care se aplic? în Software Design:

  • Claritate,
  • Consisten??,
  • Reducerea surprizei.

Prezentam cateva exemple:

Claritate: Nume?te pachetele în func?ie de denumirea func?ionalit??ii (pachete func?ionale)

Iat? un screenshot de la o aplica?ie pe care o dezvolt. Po?i spune ce face doar pe baza numelor?

a32.png

Prima oar? l-am auzit pe Sandro Mancuso vorbind despre ideea aceasta la I T.A.K.E. Unconference 2014 (2014.itakeunconf.com) ?i am fost foarte interesat s? încerc. V?d ideea ca pe un bun start în Usable Software Design.

Consisten??: P?streaz? o structur? consistent? pentru fiecare pachet func?ional

A?a arat? un pachet func?ional când este extins:

a33.png

Fiecare con?ine trei lucruri:

  • o clas? de request,
  • o clas? de controller,
  • o clas? de view.

Înc? trebuie s? g?sesc un loc mai bun pentru InvoiceFileNameGenerator, dup? cum pute?i vedea limpede. Aceasta este o înc?lcare a celui de al treilea principiu, reducerea surprizei.

Consisten??: Fiecare tip de clas? trebuie s? aib? o interfa?? consistent?

Am v?zut mai devreme c? un pachet func?ional const? din trei tipuri de clase: a clas? de request, o clas? de controller ?i o clas? de view. Exist? ?i un nivel mai ridicat de consisten?? la care se poate ajunge, mai specific în interfa?a fiec?reia dintre aceste tipuri de clase.

În acest exemplu, toate clasele de Request men?ionate mai sus au o metod?:response()?Toate func?iile controllers au o metod?:render().Fiecare func?ie de controller folose?te un view pentru a reda informa?ia. Aceste interfe?e sunt consistente în toate pachetele func?ionale.

Gânduri finale

Usable Software Design vor aduce dou? beneficii economice majore:

implementare mai rapid? pentru task-urile comune ?i integrare mai u?oar? a oamenilor noi în proiect.

Pentru a ob?ine Usable Software Design, avem nevoie de feedback de la utilizatori, mai exact de la dezvoltatori. Exist? dou? metode pentru a ob?ine: prin retrospective ?i rulând teste de usability.

Ideea nu este complet nou?. Principiile precum claritate ?i consisten?? au fost folosite mul?i ani la rând pentru a ob?ine Design mai bun. Ideea de usable Software Design este totu?i o schimbare de perspectiv?; a te gândi la dezvoltator ca la utilizatorul software design-ului ?i a încerca activ s? ob?inem feedback de la el sunt demersuri care vor aduce modific?ri în modul în care ne organiz?m codul.

Sursa: todaysofmag.ro

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...