När vi tänker på våra dagliga interaktioner med teknik, blir "sökning" synonymt med "surfing." Sökning har blivit allestädes närvarande med internet—nästan varje "ansluten" åtgärd vi kan utföra börjar med någon form av en sökning. Detta innebär två saker: för det första, att som konsumenter av teknik har vi kommit att förvänta oss sökupplevelser utan problem; och för det andra, att de företag som erbjuder oss dessa möjligheter att söka har en hel del data om hur vi gör det.
På Guru ser vi ständigt på dessa data för att fortsätta förbättra vår sökprestanda—och ofta överraskar vad vi hittar oss. Och även om vi slutligen tror att bästa sökningen är ingen sökning alls, vet vi att optimering av sökning fortfarande kommer att hjälpa våra kunder att hitta den kunskap de behöver.
Söker efter ett svar
I våra senaste insatser för att förbättra vår sökprestanda tänkte vi på flera sätt vi kunde kategorisera en framgångsrik eller misslyckad sökning. Var det sessionens längd, visade kort, totalt antal klick, antal frågor? Det fanns många sätt vi kunde ha kategoriserat sökningar som “bra” eller “dåliga,” men vi beslutade slutligen att utvärdera de åtgärder som inträffade efter att en användare skrev i den välbekanta översta rutan och klickade på enter.
Här kommer vårt datateam in för att belysa vår nyfikenhet. Efter att ha arbetat med dem för att bestämma det bästa sättet att utvärdera våra användardata, byggde de ett solkartdiagram av alla åtgärder som användare vidtog efter deras första fråga. Efter att ha tillbringat ungefär 5 minuter med att beundra deras imponerande arbete och göra meningsfull visualisering av datan framför oss, var vi redo att dyka in och börja utvärdera vilka vägar vi gillade, vilka vi inte gjorde, och vilka vi skulle behöva undersöka vidare för att ha en fast åsikt.
Varför ta en datadriven metod för problemlösning?
Att ta en datadriven metod för stora problem ger den unika möjligheten att välja en mycket specifik smärtpunkter, försöka åtgärda den, och rimligt kvantifiera resultatet av ditt försök. Till exempel, om vårt team helt enkelt lade ut för att “göra sökningen bättre,” skulle det finnas många möjliga aktiviteter för oss att göra. Vi skulle kunna försöka öka hastigheten i vilken resultat kom upp, undersöka justering av vår algoritm, eller titta på att föreslå resultat till kunder på nya sätt. Och alla dessa aktiviteter skulle vara värt att sträva efter och sannolikt förbättra sökningen på något sätt—men att ta en datadriven metod inriktad på att flytta nålen på ett specifikt resultat vinner varje gång. Varför? Låt oss överväga båda metoderna.
Säg att vi gick med den generella, låt-oss-försöka-allt-vi-någonsin-tänkt-på-på-en-gång-metoden för att förbättra sökningen. Vi skulle förmodligen ha många ingenjörer, dataforskare, produktchefer och andra kollegor fokuserade på individuella uppgifter, som arbetar mot en specifik förbättring för vilken de var helt eller delvis ansvariga. De skulle sannolikt slutföra dessa projekt i dramatiskt olika takter baserat på komplexitet, och sedan gå vidare till nästa sak. Enkelt nog. Men när det var dags för vårt team att reflektera över den ursprungliga uppgiften—att förbättra sökningen—skulle det bli mycket svårt att utvärdera vår framgång. För även om varje mått vi använde för att bedöma framgång rörde sig i rätt riktning, hur skulle vi någonsin veta vilka projekt som orsakade förbättringen? Eller, om våra mått hade rört sig i fel riktning, hur skulle vi veta vilka projekt vi skulle dra tillbaka på?
Varför välja ett smalt fokus för utvecklingen?
Genom att ta en mer fokuserad, lösa-ett-problem-i-taget-metod kan vi bättre skydda oss mot dessa typer av utmaningar. Till exempel, när det gäller sökning, skulle en mer fokuserad metod innebära att istället för att sätta ut för att "göra sökningen bättre", skulle vi sätta ut för att förbättra en specifik väg på vårt solkartdiagram som vi bestämt var oönskad. Till exempel, skulle vi kunna välja att titta på användare som söker igen omedelbart efter sin första sökning, utan att någonsin visa ett kort. Därifrån kan vi överväga alla anledningar till varför detta kan hända—visar den önskade kortet inte upp i sökresultaten? Är det för långt ner på sidan? Insåg användaren att de sökte efter fel nyckelord och bestämde sig för att försöka igen? Därifrån kan vi överväga många vägar för att lösa detta mönster, och designa våra nästa uppgifter därefter. Denna typ av problem-baserad planering håller hela vårt team fokuserat på att snabbt lösa mindre utmaningar som ett team, och gör att vi kan utvärdera om vi har gjort vår önskade inverkan snabbt och effektivt.
Eftersom sökning är en kärnkomponent i vilket kunskapshanteringsverktyg som helst som Guru, vet vi att det alltid kommer att vara ett primärt fokus för oss. Att ta en datadriven metod gör det möjligt för oss att säkerställa att vi är eftertänksamma och avsiktliga i hur vi närmar oss att lösa varje del av pusslet.
När vi tänker på våra dagliga interaktioner med teknik, blir "sökning" synonymt med "surfing." Sökning har blivit allestädes närvarande med internet—nästan varje "ansluten" åtgärd vi kan utföra börjar med någon form av en sökning. Detta innebär två saker: för det första, att som konsumenter av teknik har vi kommit att förvänta oss sökupplevelser utan problem; och för det andra, att de företag som erbjuder oss dessa möjligheter att söka har en hel del data om hur vi gör det.
På Guru ser vi ständigt på dessa data för att fortsätta förbättra vår sökprestanda—och ofta överraskar vad vi hittar oss. Och även om vi slutligen tror att bästa sökningen är ingen sökning alls, vet vi att optimering av sökning fortfarande kommer att hjälpa våra kunder att hitta den kunskap de behöver.
Söker efter ett svar
I våra senaste insatser för att förbättra vår sökprestanda tänkte vi på flera sätt vi kunde kategorisera en framgångsrik eller misslyckad sökning. Var det sessionens längd, visade kort, totalt antal klick, antal frågor? Det fanns många sätt vi kunde ha kategoriserat sökningar som “bra” eller “dåliga,” men vi beslutade slutligen att utvärdera de åtgärder som inträffade efter att en användare skrev i den välbekanta översta rutan och klickade på enter.
Här kommer vårt datateam in för att belysa vår nyfikenhet. Efter att ha arbetat med dem för att bestämma det bästa sättet att utvärdera våra användardata, byggde de ett solkartdiagram av alla åtgärder som användare vidtog efter deras första fråga. Efter att ha tillbringat ungefär 5 minuter med att beundra deras imponerande arbete och göra meningsfull visualisering av datan framför oss, var vi redo att dyka in och börja utvärdera vilka vägar vi gillade, vilka vi inte gjorde, och vilka vi skulle behöva undersöka vidare för att ha en fast åsikt.
Varför ta en datadriven metod för problemlösning?
Att ta en datadriven metod för stora problem ger den unika möjligheten att välja en mycket specifik smärtpunkter, försöka åtgärda den, och rimligt kvantifiera resultatet av ditt försök. Till exempel, om vårt team helt enkelt lade ut för att “göra sökningen bättre,” skulle det finnas många möjliga aktiviteter för oss att göra. Vi skulle kunna försöka öka hastigheten i vilken resultat kom upp, undersöka justering av vår algoritm, eller titta på att föreslå resultat till kunder på nya sätt. Och alla dessa aktiviteter skulle vara värt att sträva efter och sannolikt förbättra sökningen på något sätt—men att ta en datadriven metod inriktad på att flytta nålen på ett specifikt resultat vinner varje gång. Varför? Låt oss överväga båda metoderna.
Säg att vi gick med den generella, låt-oss-försöka-allt-vi-någonsin-tänkt-på-på-en-gång-metoden för att förbättra sökningen. Vi skulle förmodligen ha många ingenjörer, dataforskare, produktchefer och andra kollegor fokuserade på individuella uppgifter, som arbetar mot en specifik förbättring för vilken de var helt eller delvis ansvariga. De skulle sannolikt slutföra dessa projekt i dramatiskt olika takter baserat på komplexitet, och sedan gå vidare till nästa sak. Enkelt nog. Men när det var dags för vårt team att reflektera över den ursprungliga uppgiften—att förbättra sökningen—skulle det bli mycket svårt att utvärdera vår framgång. För även om varje mått vi använde för att bedöma framgång rörde sig i rätt riktning, hur skulle vi någonsin veta vilka projekt som orsakade förbättringen? Eller, om våra mått hade rört sig i fel riktning, hur skulle vi veta vilka projekt vi skulle dra tillbaka på?
Varför välja ett smalt fokus för utvecklingen?
Genom att ta en mer fokuserad, lösa-ett-problem-i-taget-metod kan vi bättre skydda oss mot dessa typer av utmaningar. Till exempel, när det gäller sökning, skulle en mer fokuserad metod innebära att istället för att sätta ut för att "göra sökningen bättre", skulle vi sätta ut för att förbättra en specifik väg på vårt solkartdiagram som vi bestämt var oönskad. Till exempel, skulle vi kunna välja att titta på användare som söker igen omedelbart efter sin första sökning, utan att någonsin visa ett kort. Därifrån kan vi överväga alla anledningar till varför detta kan hända—visar den önskade kortet inte upp i sökresultaten? Är det för långt ner på sidan? Insåg användaren att de sökte efter fel nyckelord och bestämde sig för att försöka igen? Därifrån kan vi överväga många vägar för att lösa detta mönster, och designa våra nästa uppgifter därefter. Denna typ av problem-baserad planering håller hela vårt team fokuserat på att snabbt lösa mindre utmaningar som ett team, och gör att vi kan utvärdera om vi har gjort vår önskade inverkan snabbt och effektivt.
Eftersom sökning är en kärnkomponent i vilket kunskapshanteringsverktyg som helst som Guru, vet vi att det alltid kommer att vara ett primärt fokus för oss. Att ta en datadriven metod gör det möjligt för oss att säkerställa att vi är eftertänksamma och avsiktliga i hur vi närmar oss att lösa varje del av pusslet.
Upplev kraften i Guru-plattformen förstahands - ta vår interaktiva produktturné