Calectro: Informationsarkitektur för B2B VVS-styrning

Brief

"Ge VVS-fälttekniker snabb åtkomst till korrekt information för att konfigurera en styrenhet eller identifiera inställningarna på en aktuell installation"

Obs: Produkten har inte lanserats ännu så vissa detaljer har suddats ut.

Kärnproblem

Identifiera hierarkin av beslut en VVS-tekniker går igenom när de konfigurerar en styrenhet och presentera de olika vägarna på ett otvetydigt sätt.

Bonusutmaning

Produkten är inte ute på marknaden förrän 2025 och vissa tekniska aspekter samt dokumentation är pågående arbete, så jag har varit tvungen att komma med en anpassningsbar lösning snarare än en fast för att parera eventuella framtida revideringar.

Den centrala begränsningen

Detta projekt hade en betydande begränsning: ingen åtkomst till slutanvändare (VVS-tekniker). Trots upprepade förfrågningar genom hela uppdraget kunde jag inte intervjua tekniker, observera fältarbete eller validera designer med faktiska användare.

Detta innebar att alla IA-beslut baserades på:

• Heuristisk utvärdering av kontrollens programstruktur
• Feedback från klientkontakten (inte själv tekniker)
• Allmänna UX-principer för beslutsträd och mobila gränssnitt

Implikation: Detta är en IA-övning med intressentvalidering, inte UX research. Den resulterande designen är strukturellt sund inte validerad av tekniker som faktiskt skulle använda den.

Styrenheten innehåller sensorer för flera parametrar som luftfuktighet, temperatur, etc, och denna data kan antingen styra uppvärmning/kylning direkt, eller matas in i ett huvudkontrollsystem. Till exempel, när den relativa luftfuktigheten når 80% kanske du vill öka luftflödet i ett rum tills du är nere på 70%, men samtidigt vill du hålla temperaturen på mysiga 22°C. VVS-sensorer och kontrollsystem är de som ansvarar för att upprätthålla dessa klimat.

Varje modernt kontors- eller lägenhetshus kommer att ha sådana sensorer spridda överallt, och eftersom olika byggnader och rum kan ha olika krav, tillåter denna styrenhet en fälttekniker att ändra inställningarna beroende på kraven.

Denna styrenhet är liten och diskret, vilket innebär att gränssnittet för att styra inställningen är litet, i detta fall med SPST DIP-switchar. Det finns inte tillräckligt med utrymme för att visa inställningarna på ett meningsfullt sätt på själva styrenheten, så traditionellt har tekniker varit tvungna att använda tryckta manualer eller PDF-dokument.

Även om min föreslagna applikation inte helt gör sig av med behovet av en ordentlig manual, är den avsedd att ersätta den i en av de vanligaste uppgifterna i fältet: ställa in eller analysera inställningarna på en styrenhet.

Efter diskussioner med kunden om omfattning beslutade vi att det primära problemet de ville lösa var att låta en tekniker identifiera hur man ställer in DIP-switcharna för att uppfylla ett platskrav. Eftersom styrenheten har 15 olika applikationer - var och en med fyra parallella utgångar - började jag med att gå igenom dokumentationen och klustrade applikationerna.

Det fanns stort överlapp mellan de olika applikationerna och jag var tvungen att göra några antaganden om deras hierarki och order-of-operations för en fälttekniker, men det var tillräckligt bra för att låta mig skissa ett första flödesschema av interaktioner.

Flödesschemana är bra för att diskutera användarflödet samtidigt som man respekterar kravet på god informationsarkitektur, och med det i handen kunde jag snabbt byta ut flöden baserat på feedback från kunden. Ett flödesschema tillåter dig inte att vifta bort problemet; det finns inget "kanske" eller "vi fixar det i kod". Flödesscheman kommer att belysa dina blinda fläckar utan nåd, och tvingade både mig och kunden att fatta beslut som möjliggjorde snabb utveckling.

Utan tillgång till användare eller användardata föreslog jag en preskriptiv metod för lösningen: Tillsammans med kunden skulle jag prioritera de olika applikationsfunktionerna (temp, luftfuktighet, CO2) och låta en användare göra val steg-för-steg baserat på den prioritering vi bestämde.

En användare ska aldrig behöva välja mellan fler än tre alternativ, och få max två applikationsförslag som båda löser deras problem. Så länge hierarkin av val matchade användarnas förväntningar skulle detta ge ett resultat snabbt och vara lätt upprepbart i andra situationer. Viktigast av allt: Det skulle vara lätt att testa en sådan preskriptiv lösning med faktiska VVS-fälttekniker.

Med begränsad tid för design och utveckling - och utan användare att faktiskt utvärdera denna mycket mer knepiga proposition - valde jag en preskriptiv lösning och fokuserade på att göra funktionerna så uppenbara och konsekventa som möjligt.

Ett alternativt tillvägagångssätt skulle vara att designa ett multi-select-filter som skulle tillåta användaren att ställa in alla parametrar för den "ideala" applikationen, och sedan presentera de matchande applikationerna. Jag förkastade den lösningen eftersom den skulle kräva en design som måste "misslyckas graciöst" i tusentals fall där de valda funktionerna var ömsesidigt uteslutande.

Fördelen med en sådan "öppen" lösning är att den kunde utformas för att hantera förändringar i själva applikationerna utan att behöva omvärdera en flödesschemaprioritet, och den skulle tillgodose skillnader mellan olika användarfall (till exempel, i en skola kan CO2 vara viktigast, i ett kök relativ luftfuktighet, osv.).

Varför beslutsträd över sökning?

VVS-tekniker arbetar i trånga, dåligt upplysta miljöer: vindsutrymmen, källare, maskinrum, ofta med handskar eller annan utrustning.

Sökbaserat gränssnitt - avvisad lösning

• Att skriva på mobil i fältförhållanden är långsamt och felbenäget
• Kräver söklogik, autokomplettering, stavningskorrigering
• Röstigenkänning opålitlig i bullriga VVS-miljöer
• Tekniker känner inte alltid till programnamn/terminologi

Valt: Binärt beslutsträd

• Stora pekområden lämpliga för handskklädda händer
• Progressiv visning: Inget behov av att se alla 16 program samtidigt
• Förutsägbar navigering (tillbaka/framåt genom träd)
• Fungerar utan tangentbord/röstinmatning

Varför flödesschema över uppslagstabell?

Avvisat: Platt lista eller tabellvy

• Kräver att tekniker håller alla 16 programmen i huvudet
• Jämförelsekostnader (skanning, utvärdering av skillnader)
• Liten text krävs för att få alla alternativ på skärmen

Valt: Flödesschemabaserad navigering

• Stor, läsbar text och knappar
• Enkla binära val minskar kognitiv belastning
• Progressiv: Visar bara relevanta alternativ vid varje steg
• Fysiskt lättare att navigera i fältförhållanden

Avvägning: Tar 5 klick istället för potentiellt 1, men dessa 5 klick är mer tillförlitliga och tillgängliga än att rulla/jämföra en lång lista.

Den första versionen av appen tillåter en fälttekniker att göra tre saker:

• Använda en interaktiv guide för att identifiera den aktuella inställningen på en styrenhet - till exempel vid felsökning av en befintlig installation, eller om dokumentation på plats saknas.
• Lista alla möjliga inställningar på en sida, samt markera vissa som "favorit" för snabbare åtkomst.
• Använda en installationsguide för att gå igenom ett beslutsträd baserat på styrenhetens viktigaste funktioner. Är temperatur viktigare än luftfuktighet, osv.

Jag skapade interaktiva Figma-prototyper för att demonstrera användarflödena, som utvecklingsteamet sedan använde för att bygga OutSystems-versionen. Den största skillnaden mellan iterationer har varit i det faktiska flödet och hierarkin, men eftersom den mentala modellen har förblivit densamma kunde jag fortsätta förfina designen medan vi finslipade flödesschemat.

Den slutliga föreslagna appen designades på svenska, och vissa av de grafiska tillgångarna skulle behöva uppdateras eftersom styrenhetens design inte var färdigställd, men den nuvarande versionen håller sig till kundens varumärkesriktlinjer vad gäller färg och typografi.

Jag gjorde designen gles både för att en stressad fälttekniker lätt skulle kunna skilja mellan information och affordans, men också för att lättare kunna ta emot senare varumärkesintegration med andra kundprodukter.

Även om utvecklarna inte har några problem med att navigera Figma-prototyper, finns det problem med att använda prototypen som en enda sanningskälla: Det är för lätt att göra misstag och missa viktig information, så teamledaren bad om en bättre presentation av all användarinriktad information. Jag tog till ännu ett flödesschema, men denna gång redigerat för tydlighet och återanvändning av några av de grafiska elementen från prototypen för att bättre passa in i deras mentala modell av appen.

Resultat

Utvecklingsteamet skapade en funktionell OutSystems-prototyp, levererad till klienten på en testplattform tillgänglig via mobilwebbläsare.

Projektstatus: Projektet gick inte vidare utan lades på hyllan i väntan på organisatorisk buy-in.

Ingen fältvalidering skedde: Prototypen testades aldrig med faktiska VVS-tekniker. Så även om IA-strukturen är logiskt sund, förblir dess verkliga användbarhet obevisad.

Vad jag lärde mig: Vikten av att validera stakeholder buy-in tidigt, och begränsningen av IA-arbete utan användaråtkomst. Denna erfarenhet förstärkte att heuristisk design, oavsett hur välgrundad, inte är en ersättning för användartestning.