Hvis du er en webprofessor, er det en god sjanse for at du har funnet deg selv å bruke minst en gang på feilproblemer. Kanskje du ble bedt om å implementere en ubrukelig funksjon. Kanskje du har endt med å bruke for mye tid på noe fordi det var vanskelig, heller enn viktig.

I denne artikkelen skal vi definere feilproblemer som de som ikke vil hjelpe virksomheten eller kunden, samtidig som de sparer tid og penger i prosessen. Vi undersøker hvorfor dette skjer, og finner bestemte måter å unngå det på.

Utgave 1: Imponere feil mennesker

Et vanlig problem oppstår når webprofessorer oppfordres til å imponere sine kunder, deres ledere, deres organisasjon eller en prisutdeling, i stedet for de faktiske brukerne av deres nettsteder. Resultatet er ofte et nettsted som spenner selskapet, men forvirrer kundene. Et vanlig symptom på dette problemet er når et nettsted har komplekse visuelle effekter, men brukerne må kjempe for å finne den grunnleggende informasjonen de leter etter.

Dette problemet kan skje for en rekke grunner, inkludert press, feiljusterte insentiver, vedlegg til en ide eller mangel på kommunikasjon.

Ledere kan bidra til å unngå feiljusterte insentiver ved å sette en tone på: Ikke prøv å blendre meg; bare gjøre våre kunders liv enklere.

Løsningen er å holde fokus på brukeren. Enten du lager et nettsted eller betaler for en, betyr det alltid å spørre hvordan beslutninger vil påvirke brukeren. Er alt på nettstedet klart? Kan folk finne det de leter etter? Går noen av dine valg på kundens måte?

Hvis du fortsatt har problemer med å få kundene eller organisasjonen din til å lytte, sørg for at du viser forretningsverdien av kommentarene dine. For eksempel, "Hvis vi tar ut den store filen, lastes siden raskere, noe som betyr at flere mennesker vil holde seg på det, og fortjenesten vil gå opp med $ X." Hvis det ikke virker, kan det være en større organisatorisk problem som ikke blir løst med spørsmål om brukeropplevelsen. Ledere kan bidra til å unngå feiljusterte insentiver ved å sørge for å sette en tone på: Ikke prøv å blendre meg; bare gjøre våre kunders liv enklere.

Utgave 2: Chasing en dømt løsning i stedet for å fikse det virkelige problemet

Noen ganger vil webutviklere arbeide over en løsning som er tidkrevende, dyr eller fundamentalt feil når noe enkelt ville ha jobbet mye bedre.

For eksempel, la oss si at klienten ber om sidesøkfunksjonalitet. Det er lett å dykke inn i detaljer. Hvor vil de søkefeltet? Hva er fristen? Hvordan vil de at resultatsiden skal se ut? Hva skal URL-strukturen være?

Spørsmålet ingen spurte var "Hvorfor?"

I denne helt hypotetiske historien behøvde klienten ikke å søke i det hele tatt. De var ikke en stor forhandler eller et referansested, og det virkelige problemet var at kundene ikke kunne finne det de lette etter. Noen få enkle tilpasninger til navigasjonen på hjemmesiden ville ha løst problemet, men i stedet endte selskapet med å bygge et nettstedssøk som til slutt ikke løste kundenes forvirring.

Hvordan unngår du dette?

Den beste tilnærmingen er å fortsette å spørre om de underliggende problemene i stedet for å bli for dypt inn i ideen om en løsning. For eksempel, i stedet for å dykke i å bygge et nettstedssøk, spør hvorfor det trengs. Hvis du fortsatt spør hvorfor, vil du til slutt avdekke det virkelige problemet, noe som vil være noe som "Kunder kan ikke finne det de leter etter."

Hvis alle forstår de sanne problemene og målene, vil du ende opp med løsninger som er mindre kostbare, mindre tidkrevende og mer effektive.

Utgave 3: Tilbringe tid etter vanskeligheter i stedet for betydning

Hvis du har vært involvert i et webprosjekt, har du kanskje opplevd en situasjon hvor for mye tid ble brukt på noe som ikke var veldig viktig. Vanskelige ting kan ta lengre tid, men vanskeligheter er ofte ikke korrelert med betydning.

For eksempel så jeg en gang i en situasjon hvor mye tid var nesten brukt på en kompleks, knapt synlig bakgrunns animasjon som i beste fall var ubrukelig og distraherende i verste fall. Denne animasjonen skulle også bli begravet på bunnen av siden.

Den distraherende animasjonen var det var fordi noen i selskapet ... ønsket å føle seg blendet

Det ville vært enkelt å bruke mye tid på denne bakgrunnsfunksjonen for bunntekst mens du forsømte de viktige delene av siden. Heldigvis avslørte et møte at den virkelige grunnen til at den distraherende animasjonen var der var fordi noen i selskapet, i siste øyeblikk, ønsket å føle seg blendet. Da det ble klart at dette var et forfengeprosjekt og ikke noe som ville hjelpe brukerne, ble animasjonen de-prioritert.

Hvordan unngår du å bruke for mye tid på vanskelige, men ubetydelige ting?

  1. Før du starter et nettsted, sørg for at du forstår de viktigste målene. At forståelsen kan bidra til å forhindre deg i å gå for dypt inn i en seksjon eller funksjon som ikke gir en betydelig fordel. Hvis du trenger å spørre noen, gjør det også!
  2. Hvis du finner deg selv for mye tid på noe som ikke er viktig, gå tilbake og revurdere prioriteringene. Trenger selskapet virkelig denne funksjonen? Vil det hjelpe brukerne? Er det en akseptabel snarvei som vil ha samme effekt? Spørsmål som disse kan frigjøre mer tid, slik at du kan jobbe med ting som betyr noe. Det er best for virksomheten, brukerne og deg.

Utgave 4: Har ikke nok informasjon til å ta de riktige avgjørelsene

Som utvikler eller designer, kan du kanskje ikke høre alle forretningsmessige grunner for en bestemt beslutning. Som kunde eller leder kan du kanskje ikke høre all teknisk eller brukeropplevelsesinformasjon du trenger for å foreta en dømmekall. Manglende informasjon kan føre til beslutninger som kaster bort tid, penger og kundeoppmerksomhet.

En måte å løse mangel på informasjon på er å være vokal (på en vennlig måte) når du ser et problem.

For eksempel, hvis et bestemt tiltak vil ødelegge brukeropplevelsen på en måte som hindrer folk i å kjøpe, vil du kanskje nevne det. Ofte finner du at alle var for fokuserte på noe annet for å se problemet. Hvis du er en klient eller en leder, er det godt å la alle få vite forretningsgrunner for ulike beslutninger, slik at alle involverte kan produsere de beste løsningene.

Utgave 5: La ideer mutere fra person til person

Det er et barnespill som heter Telefon, eller hviske ned Lane, hvor alle står i en linje. Når man begynner i den ene enden, hvisker hver person en melding til den neste, med sikte på å bevare den opprinnelige meldingen. På slutten er meldingen ofte drastisk forskjellig.

Dette scenariet er morsomt som et spill, men det er ikke så morsomt når dette skjer i profesjonell kommunikasjon. Det er altfor vanlig for en god ide å gå gjennom flere lag av misforståelser, til den versjonen som blir kommunisert til sentrale interessenter, høres latterlig ut.

Det er altfor vanlig for en god ide å gå gjennom flere lag av misforståelser, til den versjonen som blir kommunisert ... høres latterlig ut

Noen ganger resulterer dette scenariet i et helt webprosjekt basert på en misforstått versjon av den opprinnelige ideen. For å være klar, sier jeg ikke det er dårlig når ideene endres. Jeg sier det er et problem når ideer endres på grunn av misforståelser i stedet for tilsiktet tilbakemelding og vekst.

Her er noen forslag til hvordan du kan unngå muterende ideer:

  1. Distill meldingen til sin enkleste form. Fokuser på hovedintensjonen, og fjern så mange utrolige detaljer som mulig; folk har nok til å tenke på allerede.
  2. Når det er nødvendig, formidle en ide direkte til de som trenger å høre den. For å være tydelig betyr dette ikke at du bør CC hele kontoret, eller alarmer administrerende direktør med hver bortkommen tanke. Det betyr ganske enkelt at hvis du har noe viktig å si, ikke bare tilfeldig nevne det til personen ved siden av deg og håper det kommer rundt.
  3. Sett meldingen din skriftlig når det er mulig. På den måten har du mer tid til å tenke på det, og det er en klar oversikt som alle kan henvise til om nødvendig.

Konklusjon

Webprofessorer kan ende opp med å løse de gale problemene av en rekke årsaker, hvorav mange ikke er helt i deres kontroll. Mens forslagene i denne artikkelen ikke løser alt, håper jeg at de vil gi deg et rammeverk for å nærme seg de tingene du jobber med. Så lenge du fokuserer på brukeren, unngå å bli misledt av overflateløsninger, og kommuniserer åpent, har du et mye bedre bilde av å løse de rette problemene.