Kan varje uppgift få sitt eget gränssnitt?

Inledning

Mitra:
‍Varmt välkomna till Syntra. Detta är alltså podden för dig som driver din funktion framåt och vill förstå hur samspelet mellan system och användare påverkar vårt arbetssätt. Vi delar med oss av insikter om hur nya tekniska möjligheter transformerar vårt sätt att arbeta och interagera med teknik. Och rakt från sommarhettan, håller jag på att säga, men hängmattan kanske, så sitter vi här nu samlade. Välkommen tillbaka, Glenn.

Glenn:
‍Tack så mycket.

Mitra:
‍Härligt att ha dig här. Och idag har vi en ny härlig kollega, nämligen Lukas med oss. Vem är du, Lukas?

Lukas:
Hej, hej! Jo, jag är utvecklare här på Fiwe. Jobbat här de senaste sju åren, med fokus på PIM, där vi jobbat med att automatisera och förbättra processerna hos kunderna.

Mitra:
‍Väldigt roligt att få höra dina tankar om dagens ämne, som är om intuitiva gränssnitt. Så jag tänker att vi kör igång. Vi har ju trettio minuter på oss som vanligt och tiden går ju snabbt. Och om vi börjar med: vad är problemen med dagens gränssnitt? Vad säger ni?

Systemen som ska klara allt

Glenn:
‍Jag tror att innan vi hoppar in i själva problemet så kanske vi ska landa i vilka typer av gränssnitt det är vi pratar om idag. I alla fall har jag en bild av vad vi bör fokusera på. Och jag tänker mig främst interna applikationer som CRM-system, ERP-system och PIM-system. De här stora systemen. Eller har du någon annan uppfattning, Lukas?

Lukas:
‍Nej, nej, men precis, det är väl dem. De är ju tänkta att vara generalister, de ska funka för alla. Man köper in ett stort SAP och så ska det funka för hela bolaget. Och så får man försöka gräva i hur det fungerar och hur man anpassar det till sina processer.

Glenn:
‍Och de här systemen, de kommer ju ofta med en tanke om hur man ska göra saker. De har en åsikt, de vill styra en organisation i en riktning. För som du säger, de här systemen är ju generalister och är anpassade för att funka på många olika bolag. Men då måste de göra saker på ett visst sätt. Och det finns ju inte två bolag som är likadana och gör saker på samma sätt. Så det blir att man måste gå emot systemen lite grann och göra sina saker på ett sätt som inte är tänkt i systemet.

Lukas:
‍Precis. Antingen så gör man våld på systemet och tvingar in sina processer i det, eller så får man rätta sig i ledet.

Glenn:
‍Mm. Och samtidigt så ska de här systemen kunna stötta alla olika typer av roller. Man ska kunna göra allting från tabulära massuppdateringar till att justera en enskild datapost, eller kunna få en översiktsanalys av vad det är som har hänt på försäljningen den senaste veckan.

Lukas:
‍Det blir många knappar, många undermenyer.

Glenn:
‍Väldigt många funktioner på ett och samma ställe, som kommer ifrån ett DNA där du försöker styra någonting i en riktning som inte riktigt är riktningen som ni arbetar utifrån.

Mitra:
‍En reflektion som dyker upp nu när jag lyssnar på er: varför vill vi att de ska göra allt? Oftast så föds det en idé av att jag har problem med det här, kan du hjälpa mig fixa det? Hur går det från att den skulle hjälpa mig fixa ett problem, till att den sedan ska kunna göra allt?

Lukas:
‍Ja, men det är väl lite economy of scale. Alltså man köper in ett stort supersystem som är byggt för att det ska funka i alla scenarion. Och tror att det är billigare och bättre än något annat.

Mitra:
‍Mm. Så det är en säkerhet man går efter. Hellre betalar jag mer, mot att de här hundra andra scenarierna kanske aldrig faller in. Men om de skulle falla in så har jag en backup.

Glenn:
‍Precis, då finns redan de funktionerna där som nästan stöttar dig. Så du har i princip redan köpt det färdiga receptet för hur du ska lösa uppgiften som du kommer få i framtiden. Men den stöttar dig inte riktigt.

Mitra:
‍Och istället då, jag köper den här backupen, istället ställer den till det för mig. Jag vill utföra en uppgift, men så kan den inte göra den riktigt bra, för att den istället kan göra allt.

Glenn:
‍Den kan göra allt, men inte riktigt bra. Men den stöttar dig till fullo så att du kan göra allt. Det finns inga gränser.

Glenn:
‍Men kostnaden blir att du inte får ett intuitivt gränssnitt.

Sju saker i huvudet och en skog av knappar

Mitra:
‍Så hur gör vi gränssnittet mer intuitivt? Och varför räcker det inte då att bara använda systemet bättre?

Glenn:
‍Jag läste någon gång att man som människa bara kan hålla sju saker i huvudet samtidigt. Jag vet inte om den siffran stämmer, det är säkert mer eller mindre på olika människor. Jag tror inte jag kan hålla så många saker i huvudet samtidigt. Men vi bygger gränssnitt i de här applikationerna som har betydligt fler än sju knappar och datapunkter att titta på, som man ska hålla koll på. Tänk på ett större CRM-system. Du har massa menyer som är dropdown, och så finns det dropdown i dropdown. Det finns hur många undermenyer som helst. Det blir ju mental overload att sätta sig in i så ofantligt många knappar.

Lukas:
‍Så minskar man antalet knappar så blir det mer intuitivt.

Glenn:
‍Men då kan du inte göra allting igen.

Lukas:
‍Behöver man kunna göra allt?

Glenn:
‍Ja, vi behöver ju kunna stötta alla use case.

Lukas:
‍Man får bygga mindre saker ovanpå de stora systemen.

Glenn:
‍Ja, det är ju ett sätt att hantera det. Istället för att du bygger utifrån ett system så bygger du utifrån en process och säger: vi har den här uppgiften som ska göras. Okej, vi låter systemet vara kvar i botten, men vi bygger en applikation vid sidan om som ska stötta just den här arbetsuppgiften. Det är egentligen det som no code- och low code-lösningar kommer från. Att man kan få ett drag and drop-gränssnitt för att bygga ihop en egen liten applikation där man kan göra en del i en process. Och då får man ju ett ändamålsspecifikt gränssnitt som är intuitivt, för det är byggt för att göra just den här uppgiften. Men du har fördelen av att du fortfarande har det här jättesystemet i botten som kan göra allting. Så för de användare som bara jobbar på den processen blir det intuitivt.

Mitra:
‍Men var går gränsen? Om vi tidigare pratar om att problemet är att den ska kunna göra allt, en generalist, till att vi nu pratar om att den ska klara alla use case. Men hur vet vi vilka som är alla use case som vi täcker in? Hur gör vi den avvägningen?

Lukas:
‍Det är väl där man borde fokusera först: de gånger då man vill att en viss användargrupp eller intressent ska göra en uppgift i systemet, men de gör det så pass sällan att de liksom aldrig kommer i gång med att hitta den tredje undermenyn som de ska in på för att hitta sin del av gränssnittet. Och där försöka sålla bort den navigationsskatt som blir. Halva uppgiften är att hitta till rätt plats att göra saken.

Mitra:
‍Just det. Så problemet är inte att den kan många saker. Problemet är att det tar tid att hitta just det jag skulle hitta, bland det här havet av allt den kan.

Glenn:
‍Det är inte ett problem i sig att du kan göra många saker. Problemet är att du blir överväldigad, så du förstår inte vad det är du ska göra när du kan göra allt samtidigt. Därför behöver vi ha kvar kapabiliteten av att kunna göra allt. Men alla användare behöver inte kunna göra allting. De som vi pratar om här som sällananvändare, som kanske bara är en del i en process, de behöver inte kunna hitta den sjunde menyn. De behöver bara kunna ändra två, tre fält på femtio av raderna i det här systemet.

Mitra:
‍Så då, när vi pratar om intuitiva gränssnitt här idag, då menar vi alltså snarare hur vi hjälper en specifik användare att snabbt hitta eller utföra det man tänker göra?

Glenn:
‍Nästan så. Jag tänker mer: hur kan vi begränsa så att man bara ser det man behöver? Få ner antalet knappar till de knappar du behöver, så att det blir lättare att göra det du ska.

Mitra:
Ja, det är ju en konsekvens så klart. Eller det blir ju en effekt av att vi skalar ner det.

Glenn:
‍Du tänkte lite längre än mig.

Mitra:
‍Nej, det vet jag inte. Men jag tror vi pratar om två sidor av samma mynt.

Kommer chatten att äta upp alla knappar?

Mitra:
‍Men kommer chatten att äta upp alla knappar då?

Lukas:
‍Inte alla knappar. Det finns ju definitivt scenarion där det har varit mycket lättare att bara skriva lite kort till en chatbot att, ja men, jag vill uppdatera detta på den här typen av artiklar, och att det händer någonting i bakgrunden magiskt och så blir det utfört. Men att försöka skriva det man vill utföra i en applikation, i en sådan miljö, då kan det ju istället bli att man lägger fem minuter på att skriva det man vill ha gjort, istället för att kunna trycka på de här tre knapparna som hade löst problemet. Så om man tittar till exempel på någon väderapp, SMHI. Där vill man inte chatta sig fram till vad vädret är i Göteborg idag.

Lukas:
‍Man vill ha en sökruta där man kan skriva Göteborg, och så får du solsken eller regn.

Mitra:
‍Som det brukar vara i Göteborg.

Glenn:
‍Och då får du inte en textmassa som svar i en chatt där det står att, ja men i Göteborg kommer det regna imorgon och igår var det lite bättre väder, det kommer blåsa 27 meter per sekund. Nej, du får ju ett dedikerat gränssnitt för att presentera just vädret. Du får fina symboler som visar en sol, så att du snabbt kan ta dig an informationen om att det är sol. Och du får symboler som visar hur mycket det ska blåsa. Du har tydliga tabeller. Du kan jättesnabbt ta dig an gränssnittet som är i SMHI-appen.

Mitra:
‍Är det ett problem som ni ser nu i takt med att AI tar fart? Att det är ett beteende som kommer fram, att chatten ska lösa mycket av användarvänligheten, att jag hittar den informationen eller den funktionen jag behöver ha. Är det någonting som ni ser börjar bli ett problem? Med tanke på att du nämnde här, Lukas, att det här hade gått mycket snabbare att bara klicka på de här tre knapparna istället.

Lukas:
‍Det är ju många plattformar och applikationer där vi ser att det byggs in utan att det riktigt finns någon anledning till det. För att AI:n ska in, den ska in och det ska funka. Den ska lösa alla problem. Och hur får man en AI att lösa alla problem? Jo, men skriv vad man vill göra i chatten, så funkar det.

Glenn:
‍Det är ju ett fantastiskt sätt att integrera med mjukvara, att bara kunna skriva precis hur du vill och så händer det. Det är ju en fantastisk kapabilitet som vi har idag. Men att faktiskt behöva skriva i en textruta vad man vill, det är inte det mest intuitiva. Du måste förstå vad du vill. Du måste kunna beskriva det på rätt sätt. Du måste kunna uttrycka det i ord. Det blir ofta ganska långsamt att hålla på och skriva sådana här texter.

Mitra:
‍Ibland så vet man ju inte vad man vill förrän man ser det. Jag ser din blå vattenflaska. Åh, det där, en sådan där skulle jag också vilja ha. Det visste jag inte innan.

Glenn:
‍Vi kan till och med ta det tillbaka hela vägen till början av datorn, de allra första datorerna. Innan vi fick de här, alltså Windows var ju en grej, att man fick fönster i sin dator. Ett gränssnitt där du kunde dra runt fönster och se ikoner och sånt. Innan det så hade vi ju ett terminalfönster. Det är ju precis samma sak som chattarna, att du behövde skriva varenda kommando. Text in, text ut, det var det enda som kommunicerades. Men vi lärde oss så småningom att det inte var det bästa sättet att interagera, och då började man bygga gränssnitt som visar användaren vad som sker istället. Visar var du kan klicka, istället för att du måste memorera varenda kommando.

Mitra:
‍Men är det fel att ha en chatt? Jag tänker på att vi har ju olika beteenden. Vi söker efter information på olika sätt beroende på vad det är. Ibland så kanske jag har svårt att formulera mig i en chatt, och då underlättar det att kunna se. Då får jag en idé om vad jag vill ha. Vid ett annat tillfälle är det lättare att förklara, för det är enklare för mig att förklara ungefär kontexten jag befinner mig i för att sedan få någon typ av hjälp. För att sedan switcha över och titta på en bild. Är det inte så att det egentligen inte finns några rätt och fel, utan snarare att det ska finnas flera olika sätt att göra på? Eller tycker ni att chatten helt borde begränsas mer?

Lukas:
‍Chatten har definitivt sin plats. För hur mycket man än gärna vill kunna förenkla saker, så finns det alltid någon typ av komplexitet längre bort. Så i de lägen där det kanske inte räcker med ett enkelt formulär, eller något tresidigt formulär där man ska fylla i vad man vill göra, då kanske man helt enkelt behöver sträcka sig till en chatt med en AI som har bättre koppling internt till systemet och kan utföra de djupare operationerna.

Glenn:
‍Ja, chatten har definitivt ett värde, men jag tror det är ett spektrum här. Jag ser inget som helst värde med att ha en chatbot i SMHI-appen. Där vill jag bara kunna se vädret. Men jag ser ett värde i att ha det i ett CRM-system, för den kan hjälpa mig att göra de där operationerna som jag sällan gör. Om jag ska ställa någon specifik query för att leta reda på alla som heter Agda och är födda 75. Jag kanske inte vet hur man gör det, men det kan jag be chatten göra. Då kan den göra det åt mig och den kan hjälpa mig komma bort ifrån alla de här knapparna. Jag tror att det finns något mellanting däremellan som vi missar. Allting är inte chatt och allting är inte SMHI, men det finns ett hav av möjligheter däremellan som man ofta missar.

Gränssnitt som genereras när uppgiften uppstår

Mitra:
‍Och vad är det för möjligheter som det här havet erbjuder?

Glenn:
‍Man försöker ju adressera det med de här no code- och low code-lösningarna och dedikerade gränssnitt för en specifik arbetsuppgift. Det är ju ett sätt att ta en uppgift i ett komplext system, sudda bort allt du inte behöver göra och bara visa det du faktiskt ska göra. Men vi ser hur AI-kodning håller på att äta upp no code- och low code-lösningarna. Det är så mycket snabbare att vibe-koda ihop en applikation än att sitta med drag and drop-alternativ för att bygga ditt gränssnitt. Så det skapas någon typ av ny möjlighet här.

Lukas:
‍Ja, det är jättebra för de processerna där vi tydligt definierat sedan innan att... Ja men artikelonboarding. Vi ska alltid fylla i den här typen av data och vi behöver alltid styra åt ett visst håll.

Mitra:
‍Så hur gör man det mer intuitivt? Hur gör vi gränssnitten mer intuitiva?

Lukas:
‍Vi behöver hitta bra sätt för att skala bort alla överflödiga bitar av gränssnitten. Antingen genom att bygga för specifika processer. Annars är det ju bättre att kunna hitta ett sätt för de här one off-use casen, där inköparen behöver in och småjustera priser på en enstaka artikel. Att hitta ett sätt att ge dem ett gränssnitt för specifikt den här uppgiften, och kanske även snäva ner det till exakt den artikel de är ute efter. Så man kan generera ett gränssnitt för det specifika scenario de har just nu.

Glenn:
‍Och att generera gränssnitt när en användare faktiskt har en uppgift, det är ju att ta vibe-kodningen, eller att låta en AI skapa en applikation åt dig, till sin spets. Istället för att betala ett utvecklingsteam i flera veckor för att skapa en applikation utifrån en process, så litar du helt och hållet på AI:n till att den kan skapa en applikation på en minut, så kan den lösa en uppgift. Det är ju dit vi är på väg. Det går snabbare och snabbare att skapa mjukvara.

Ett gränssnitt per användare, inte ett för alla

Mitra:
‍Menar ni att det ska finnas många olika typer av gränssnitt? Låt säga att det är ett bolag, olika användare, sällananvändare och superusers är där inne. Är det olika gränssnitt för de här?

Lukas:
‍Ja, det ser jag framför mig i alla fall. För power usern kommer inte vilja släppa sina gränssnitt där de har jobbat de senaste fem åren och liksom kan varenda knapp utan och innan. Vissa operationer kanske de hellre gör i ett lättare gränssnitt. Men det stora dagliga arbetet de gör kommer de gärna behålla i sitt stora och fina gränssnitt. Men det finns ju ingen bra anledning till att ge samma gränssnitt till inköparen som ska in och pilla på sitt pris, eller sortimentshanteraren som ska se till att det hamnar i rätt kategorier eller i kampanjer. Ge dem samma stora läskiga gränssnitt.

Mitra:
‍Så du menar att man inte kommer ifrån systemens gränssnitt. Det finns fortfarande de som kan varenda liten detalj som fortfarande vill vara i det gränssnittet. Att det kommer vi behöva behålla, men att vi lägger till fler möjligheter att kunna skapa nya typer av gränssnitt för andra användare. Att det är de två som spelar.

Lukas:
‍Ja, jag tror det. Behovet finns fortfarande att ha det stora generalistgränssnittet som kan göra allting. Dels innan man kommer på hur man vill specificera en process för att göra det enklare för de andra, men även för att kunna administrera systemet och utföra annat arbete som inte riktigt är lika tydligt definierat som det sällananvändarna brukar göra.

Glenn:
‍Det finns ju definitivt en plats för alla de här dimensionerna. Och som du är inne på, anledningen till att vi har bjudit in alla till det komplexa systemet, det är ju bara en budgetfråga. För det har varit för dyrt att skapa dedikerade applikationer för varje enskild process. Det mäktar man inte med. Man kan göra det med ett fåtal processer. Men det har definitivt varit för dyrt att skapa en applikation för varje enskild uppgift du gör i en organisation. Det har ju inte varit möjligt. Du kan inte lägga en halv miljon på att skapa en applikation för att uppdatera priset på en artikel. Och sen ska du göra samma insats för nästa artikel. Det går ju inte. Men nu när AI kommer in och skakar om världen, så kan vi ju göra det för en krona, och då kanske det är värt det. Då kan vi få en applikation för varje uppgift. Varje användare kan mötas av ett system som faktiskt förstår en.

Grundförutsättningarna: fri data och tydligt ägarskap

Mitra:
‍Men hur skulle processen se ut för ett bolag idag som tänker att ja, men vi vill börja jobba efter detta. Vi vill ta fram gränssnitt som är användarvänliga för även andra användare. Hur går man till väga?

Lukas:‍
Man får börja se över vad man har för processer idag. Man kanske även har fått frågan tidigare, eller flera gånger kanske, från olika delar av organisationen: men kan ni justera den här typen av data åt oss? Den typen av process är ju ett praktexempel på något man lätt kan bryta ut till något mindre. Och antingen bygger man en helt dedikerad applikation för den typen av process. Det beror ju lite på hur stort eller litet det är. Ska jag bara gå in och trycka godkänn på ett pris? Ja, men då behöver man kanske inte ha en helt dedikerad applikation. Då kanske det räcker med något lättare som går att generera automatiskt. Medan om man ska se över val av vilken leverantör vi ska ha på en artikel, och kunna jämföra vad vi har för olika priser från de olika leverantörerna och den typen av data, då kan det vara mer intressant att ha en helt standalone-applikation som är gjord specifikt för den processen.

Glenn:
‍Det här är ju helt rätt sätt att attackera problemet. Men jag tror att man måste backa bandet lite, till när man tittar på vilka de här underliggande systemen är. Ska vi ha SAP som ligger i grunden eller ska vi ha någonting annat? När man gör den utvärderingen så måste man titta på det utifrån vart gränssnitten är på väg. Vad kommer att vara ett intuitivt gränssnitt i framtiden? Om vi tror på den här filosofin om dedikerade applikationer och att generera gränssnitt, ja men då behöver vi ha grundsystemet så att det klarar av att möta upp det behovet. Att det har tydligt definierade API:er så att det går att interagera med datan på det sättet. Annars fastnar vi i de här stela systemen, för att datan blir fast där och vi inte kan jobba med den.

Mitra:
‍Vilka är de här? Du var inne på det, men vilka är grundförutsättningarna för att kunna jobba med de här intuitiva gränssnitten? Du nämnde API:er som en.

Glenn:
‍Det är ju att datan är fri, skulle jag vilja säga. Att det går att jobba med den, att det går att interagera med den. Att du kan skriva ett program som hämtar ut data och skriver tillbaka data. Normalt gör man det via ett API.

Mitra:
‍Finns det något annat som man behöver tänka på? Har vi detta?

Glenn:
‍Utöver det så är det ju viktigt att ha tydligt definierade ägandeskap av data. Det räcker inte att bara släppa datan fri och att alla system får lov att pilla på den. För alla ska inte få lov att pilla på den. Så vem äger egentligen en datapunkt?

Mitra:
‍Så ägandeskap, API:er som hjälper till att få ut datan, skicka data, ta emot data. Om de bitarna är på plats, då är vi alltså redo att börja titta på hur vi kan jobba med intuitiva gränssnitt.

Lukas:
‍Ja, där har vi ju grundpelarna, och sen får man titta på processerna utöver det och se var man kan lägga kraften för att förenkla.

Från proof of concept till produktion

Mitra:
‍Och de här gränssnitten, är det någonting som gör att jag behöver gå till olika plattformsleverantörer, eller är det någonting som jag kan arbeta med på en avdelning internt på bolaget? Hur mycket kan jag utveckla själv och hur mycket är jag beroende av en annan leverantör?

Lukas:
‍Det enda andra beroendet är väl i så fall tillgången till de här API:erna eller datapunkterna. Får man tillgång till dem och möjlighet att skriva och läsa, då kan man ju bygga vad man vill själv.

Glenn:
‍Och med dagens verktyg så kan ju nästan vem som helst vibe-koda ihop en applikation som löser ett problem. Och det ser vi att det poppar upp mer och mer. Folk som inte är programmerare skapar applikationer. Superspännande, för de sitter på problemet och vet hur man skulle göra detta på rätt sätt. De kanske inte har kompetensen att förvalta och drifta det rätt över tid. Där kan man behöva en stöttning. Men att ta fram en applikation, det kan ju i princip vem som helst göra.

Mitra:
‍Och de kanske behöver ha stöttning i just att leda det arbetet på ett sätt där man kan ställa de rätta frågorna och tänka ut hur man skulle kunna göra vissa saker. Det finns ju oftast tusen olika svar på en och samma sak egentligen. Och där kanske man vill ha mer hjärnkraft till att lösa problem på olika sätt.

Glenn:
‍Jag skulle vilja uppmana alla att åtminstone bygga en proof of concept själva. Behöver inte blanda in någon annan för att testa en idé. Sen att ta det ifrån ett koncept och en idé som liksom, ja men det här verkar rätt coolt, till att ha någonting som är i drift och i produktion, ja då kan det vara vettigt att ta lite stöttning. Men gör det första provtrycket själv. Minsta motståndets lag. Bara testa. Vi måste våga att fail fast (lyssna på Syntra Utbenat på temat). För det är ni där ute som sitter på problemen och förstår dem. Och om ni lyckas uttrycka det så att ni kan demonstrera att så här skulle man kunna jobba med det, då kan vi hjälpa er att ta det längre.

Mitra:
‍Jag tycker att man hör ändå att man är ute och testar. Man prövar. Det finns personer på avdelningarna. Bolagen har gått ut och uppmuntrat att nyttja AI, pröva. Men jag ser att gapet blir snarare sen, som du var inne på här Glenn, att ja, vi har prövat, men hur tar jag det till produktion? Hur skapar jag resultat? Hur bidrar jag med värde kopplat till affären på något sätt? Jag upplever att man testar just nu. Många bolag uppmuntrar det. Men just steget till att faktiskt rulla ut i produktion, till något fungerande som levererar ett värde, där är det lite utmaningar fortfarande?

Lukas:
‍Ja, och det beror ju väldigt mycket på hur varje enskild organisation sköter sin IT och hur de brukar ta den typen av applikationer i drift. Och det är inte alla organisationer som är vana vid det. Att ha en internt byggd applikation som man sätter upp och driftar.

Glenn:
‍Jag tror det finns väldigt få organisationer som är vana vid att få en applikation från Lovable och säga: "Den här behöver vi ha in i vår infrastruktur." Det kanske är några som har gjort det, men jag tror inte det är många som är vana vid den resan.

Lukas:
‍Nej, "vana" är kanske att ta i.

Mitra:
‍Vi får inte glömma att det här har ju gått rätt så snabbt, de här nya möjligheterna. Vi har inte hunnit komma in i det och kanske få vanan där. Men det känns på något sätt som att det är normalt nu, även fast man ännu inte har börjat anamma det själv.

Summering

Mitra:
‍Och om ni skulle skicka ut det här då, en sista reflektion till alla som lyssnar. Vi pratar om intuitiva gränssnitt. Vad vill ni att lyssnarna ska ta med sig?

Lukas:
‍Se över processer som i sin helhet är väldigt enkla, men som oftast görs av någon annan. Där man tar ut ett Excel-ark ur sitt system, skickar till någon annan avdelning som tar hand om det, för att sedan läsa in det i systemet igen. Börja där och titta vad man kan börja rycka i. Och få dem att definiera sitt behov där.

Mitra:
‍Bra exempel, Lukas. Verkligen. Enkelt att ta med sig. Glenn då, vad har du med dig?

Glenn:
‍Jag skulle vilja ta upp navigationsskatt. Vi pratade om det tidigare och jag tror inte vi riktigt definierade det. Men det är som att man får betala en skatt för att behöva navigera fram till där man ska utföra en uppgift. Det kan vara jättemånga klick för att komma fram till en arbetsuppgift. Fundera på hur många av era arbetsuppgifter där navigationsskatten är det större priset, där ni betalar mer tid och klick för att komma fram till uppgiften än att faktiskt göra själva uppgiften. Där har man antingen fel i sitt sätt att arbeta, eller fel gränssnitt, om det är jobbigare att klicka fram till det man ska göra än att göra det.

Mitra:
‍Ja, två väldigt konkreta och fyndiga exempel. Eller navigationsskatten är kanske mer fyndig. Och det här med Excel är ju ett oerhört praktiskt och tydligt och enkelt sätt att ta sig an detta, och vad man kan börja göra idag. Spännande avsnitt, intuitiva gränssnitt. Det är nog inte sista gången vi pratar om detta. Stort tack till er båda för att ni var med idag.

Glenn:
‍Tack så mycket. Tackar, tackar.

Mitra:
‍Jättehärligt, och väldigt härligt att ha dig här, Lukas. Vi hoppas att det blir fler tillfällen!

Glenn:
‍Det hoppas vi!

Mitra:
‍För den som vill lyssna på mer så får ni jättegärna ge er in i bibliotekets värld på vår hemsida och titta efter fler avsnitt som vi har, och se fram emot nästa som kommer.

Du har lyssnat på Syntra, en podd från Fiwe.