Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Het gaat bij ontwikkelen ook om de buitenkant

 

Computable Expert

ir. Sebastiaan Rieter
IT Consultant bij Unisys Nederland N.V., Unisys Nederland N.V.. Expert van Computable voor het topic Development.

Het einde van het ontwikkeltraject is in zicht. De applicatie is helemaal getest en geaccepteerd door de eindgebruikers en het in productie nemen was een groot succes. De champagne kan open, want het record is verbroken: het was dus toch mogelijk om nog meer knoppen, menu's en invoervelden op een enkel scherm te krijgen dan de vorige applicaties!

Het begon allemaal zo goed, de 'business' wilde een nieuwe applicatie en de functioneel ontwerper had een prachtige applicatie in gedachten. Precies waar de doelgroep op zat te wachten, vol met alle functionaliteit die de eindgebruiker nodig had. Het functioneel ontwerp was compleet en was zonder al te veel reviewcommentaar - het bevatte immers alle functionaliteit - richting ontwikkelaars gegaan. De uitdaging was om al die functionaliteit beschikbaar te maken en het liefste ook nog op één scherm, zodat het lekker overzichtelijk zou blijven. En inderdaad, het paste dus op één scherm, maar de overzichtelijkheid was ver te zoeken.

Natuurlijk, het bovenstaande beeld is wat aangedikt, maar ik kom zo veel applicaties bij klanten tegen die een dergelijk traject hebben doorlopen. De gebruikersinterface ziet er niet uit en is zo contra-intuïtief dat ik echt medelijden krijg met de eindgebruikers. Het lijkt haast onmogelijk om een applicatie te bouwen die én functioneel compleet én gebruikersvriendelijk is. De hoofdoorzaak zit hem in het ontbreken van een aantal applicatie-interfaces en -flow elementen in het bovenstaande proces.

Eindgebruikers

De focus van applicaties ligt te vaak op de functionaliteit en te weinig op de eindgebruiker. En het zijn juist deze eindgebruikers die de applicatie in hun dagelijkse werkzaamheden moeten integreren en ook zij hebben een visie op de bruikbaarheid van de applicatie: hoe bijvoorbeeld menu opties gegroepeerd zouden kunnen worden of in welke volgorde invoer velden moeten staan op een scherm. Het zijn allemaal kleine elementen, maar kunnen veel ergernis wegnemen.

'Het oog wil ook wat ', maar dat aspect wordt, met name bij applicaties voor intern gebruik, meestal uit budgetoverwegingen verwaarloosd. Het gevolg is het ontbreken van een eenduidige ontwerp voor zowel de grafische opmaak als de workflow, waardoor je als gebruiker aan de grafische kunsten (onkunsten) van een ontwikkelaar bent overgeleverd. Het is daarom verstandig om na of parallel aan het functionele ontwerp ook na te denken over het ontwerp voor de gebruikersinterface. Betrek hier je eindgebruikers bij en zorg dat er een duidelijk afbakening is voor de ontwikkelaars die aan de slag gaan met de applicatie. Wellicht is het een keuze om een externe partij te betrekken bij het ontwerp.

Aan de andere kant ben ik van mening dat een ontwikkelaar ook zelf vaker aan de bel moet trekken op dit gebied. Als ontwikkelaar moet je trots kunnen zijn op, of tenminste tevreden met, het door jou gebouwde stuk software. En een te vol scherm met een lelijke onlogische interface behoort niet tot deze categorie. Jammergenoeg komt het te weinig voor dat een ontwikkelaar bezwaren aankaart op gebruikersinterfacegebied en maar 'gewoon doet wat hem (of haar) wordt opgedragen'.

Het wiel uitvinden

Veel standaard functionaliteit is al veel vaker gemaakt, maar toch blijft elk project het wiel weer opnieuw uitvinden. Functionaliteiten zoals 'winkelwagentjes', online betalen, zoeken en account beheer is al zo vaak toegepast en uitgewerkt dat je alleen maar kunt concluderen dat het zonde is van de tijd om dergelijke functionaliteit zelf te gaan bedenken.

Het kan gelukkig ook anders. Af en toe kom je klanten tegen die zich wel bewust zijn van het belang van een goede applicatie-interface en flow. Zo hebben we een klant die wel over hun gebruikersinterface nadenkt en zelfs uitrekent dat een beperking van het aantal muisklikken per proces aan het einde van het jaar duizenden euro's bespaard. Pak bijvoorbeeld een gemiddeld callcenter met zo'n vijf miljoen interacties per jaar. Als daar de interactietijd met vijf seconden wordt teruggebracht dan is de besparing op jaarbasis rond de zevenduizend uur.

Zorg er dus voor dat er aan het einde van het proces champagne wordt opgetrokken om te vieren dat er een applicatie staat die ook daadwerkelijk gebruikt gaat worden en efficiënt om gaat met tijd van de gebruikers. Een applicatie dus die zowel van binnen, functioneel, als van buiten, intuïtief, in elkaar steekt.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4539816). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Mijn grootste irritatie is wel het invoeren van een datum. Of het zijn listboxen die meters lang zijn of het zijn van dit popups en dan moet je voor je geboorte jaar 53 jaar terug. Als je als medewerker zo vele malen informatie moet invoeren dan wordt je gillend gek.
Verder ben ik het helemaal met je eens, maar ik denk niet dat een ontwikkelaar hier veel keuze in heeft. Hij moet maken wat er op zijn bordje ligt. Het moet dus eerder in het proces meegenomen worden.

@Ruud de Ridder: datums zijn altijd lastig, maar zijn veel standaard controls voor. Wat betreft ontwikkelaars: je kunt het in ieder geval altijd aangeven als je iets tegen komt waarvan je denkt dat het echt niet gaat werken of eenvoudig beter kan.

Leuk artikel, had wel korter gekund. De boodschap is eigenlijk dat er bij ontwikkeling teveel focus is functionaliteit en minder om gebruiksvriendelijkheid.

Dit heeft drie redenen:
1) Requirements zijn in de basis functioneel en een stuk lastiger voor gebruikerservaring anders dan "het moet gebruiksvriendelijk en overzichtelijk zijn"

2) Gebruiksvriendelijk... is rocket science.

3) Er word op functionaliteit afgerekend.

Vooral het derde punt zorgt dat er minder tijd en geld wordt besteed aan de ervaring.

Veel ontwikkelaars denken in termen van functionaliteit en database records vullen en stappen niet buiten de kaders. Dit zie je bijvoorbeeld terug in urenregistratie tools. Vul datum, begin en eindtijd in, kies een projectcode en doe een omschrijving van de werkzaamheden.

Waarom niet inspreken of gewoon een zinnetje typen (met auto aanvullen);
"Vandaag 3 uur gewerkt aan Project X; Wijziging aangebracht op datamodel." of "van twee tot vier overleg met klant x"

Maar goed. Het blijft lastig, laatst zag ik een mooi project wat alles op papier goed deed, dus met Interactief Ontwerper en Mockups en usability experts. Toch was het eindproduct verre van optimaal omdat de designers het domein van de business niet goed begrepen.

Heel goed artikel complimenten! Door toename van consumenten producten als gadget wordt de vraag om gebruiksvriendelijke software steeds groter. Toen ik drie jaar geleden begon met een nieuw software bedrijf hoorde was het nog redelijk uniek, maar merk dat dit nu snel veranderd.

Als software bedrijf doen wij het anders dan de meeste software bedrijven. Wij hebben aparte designers in dienst die elke functionaliteit eerst qua design en interaction ontwerpen en laten testen. Dan wordt het ontwikkeld door de 'echte' developer. Vervolgens gebeurd het stuk Q&A ook door dezelfde designer die test of de prakijk echt werkt. Waar wij indien mogelijk gebruik maken van standaard componenten die wij 'opnieuw' stylen. Of te wel standaard techniek die wij mooi maken door middel van grafisch design.

Wij merken dat er steeds meer interesse en vraag komt naar onze manier van werken en maken van Sexy software. Zelfs zo dat we nu voor andere bedrijven bezig zijn om bestaande producten te verbeteren of nieuw design te maken. Of te wel, merk echt dat dit meer aandacht krijgt.

Ga zo door!

Groet, Erik

Ik verwacht dat de vraag naar een goed doordachte (en sexy) user interface ook steeds groter gaat worden met de toename van mobile devices. De gemiddelde enterprise applicatie kan je echt niet een-op-een overzetten naar mobiele varianten. Je zult opnieuw moeten gaan nadenken over de opbouw van je applicatie en de interface en zoveel mogelijk aspecten gaan benutten die de mobile OS'en je bieden.

Wat is sexy? Zelf vindt ik Doutzen Kroes wel sexy, maar ik kan me voorstellen dat homosexuele of vrouwelijke vakgenoten zich hier niet in kunnen vinden.

Zo ook met gebruikers interfaces. Zoveel mensen, zoveel wensen. Handig is een relatief begrip. Pak het voorbeeld van Ruud. Iemand van 25 jaar vond de interface wellicht wel handig omdat voor hem het goede jaartal wel op het scherm stond. Voor de wat oudere jongeren onder houdt dit in dat we wat naar beneden moeten scrollen voor het goede jaartal. Persoonlijk vindt ik het handiger om dan even die 4 getallen in te tikken in plaats van te scrollen.


Kijk ik even naar de website waar ik dit nu in zit te tikken, denk ik: welke malloot heeft dit ontworpen? Ik heb links en rechts een brede grijze balk waar niets in staat. Hiermee gaat toch al gauw 30% van mijn mooie breedbeeldscherm verloren. Dat moet toch ook slimmer kunnen, niet dan?

Maar goed, ik weet dat ik niet representatief ben voor de gemiddelde IT-er. 40+, geen .net ervaring en zo, je kent het wel. Op mijn desktop staan alleen de meest gebruikte shortcuts, de rest zit mooi weggewerkt in het menu.En ja, ik heb het liefste een full size toetsenbord met numeriek gedeelte. Pad's, Pod's en tabletten zijn leuk voor de heb, maar niet om een hele dag op te werken. (en een toetsenbord is fijner als je je even uit wil kuren, zijn een stuk goedkoper om te vervangen dan een touch-screen :) )

Echter, ik weet wel wat (voor mij althans) handig is. Command line is niet sexy (zelfs niet met roze letters op zwarte achtergrond) maar o zó handig voor een aantal toepassingen.
Databases met gelikte webinterfaces zien er leuk uit, maar als ik een batchverwerking wil doen, dan kan een CLI of API toch ook wel heel handig zijn. Niet sexy, niet grafisch, maar gewoon praktisch!!!

De grootste uitdaging bij het ontwerpen van de gebruikers-interface is het vinden van een REPRESENTATIEVE gebruikersgroep. Te vaak worden er maar aan één of enkele gebruikers die toevallig tijd hadden gevraagd hoe zij ermee denken te willen gaan werken. De kleine groep gebruikers die bijv. rapportages uit het tool moeten krijgen, of veel batchverwerking moeten doen worden dan vaak vergeten, en zij lopen later tegen de problemen aan omdat het tool weliswaar sexy eruit ziet, maar er niet mee valt te werken voor hun.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×