På denne siden
Et diagram over tog kan gjøre et bytte lett å se ved å rette ut linjene og gi stasjonene jevn avstand. Det kan også få to stopp til å se langt fra hverandre ut når det bare er en kort spasertur mellom dem. Den samme forenklingen som hjelper en reisende å velge tog, kan villede en som vil gå.
En historie om et diagram for kollektivtransport spør hva som skjedde da et skjematisk bilde ble brukt til flere oppgaver enn å velge rute. New York Transit Museums beskrivelse bekrefter at kartet fra 1972 rettet ut rutene og fjernet det meste av topografien. Historien minner oss om at et bilde kan være bra for én oppgave og likevel trenge en annen visning for en annen. Den nøyaktige historien om planlagte tillegg trengs ikke for lærdommen.
Definer ruten leseren prøver å finne
Hvert diagram fjerner informasjon. En skisse av systemarkitektur utelater tid. Et diagram over arbeidsflyt utelater dataverdier. Et kart over retningen på synkroniseringer kan utelate hvem som kan godkjenne en skriving. Å fjerne noe er ofte grunnen til at bildet kan leses. Problemet begynner når det fjernede forholdet betyr noe for leserens valg.
Se for deg et tenkt diagram over synkronisering fra butikk til e-postsystem med to bokser og én pil: Butikk → E-postplattform. Det hjelper med spørsmålet «Hvilket system sender kundeposten?» Det kan ikke svare på om samtykke følger posten, hvordan duplikater håndteres, eller om et kjøp avlyser en planlagt melding. Bildet er ikke feil. Det er ufullstendig for disse beslutningene.
Før du tegner, skriv leserens spørsmål i én setning.
- Stasjon Astartforbundet
- Bytteskift linjeforbundet
- Stasjon Bmål
«Hvor kommer dette feltet fra?» trenger en oversikt over opprinnelse. «Hva skjer hvis kilden er nede?» trenger tid og feiltilstander. «Hvem får starte en kampanje?» trenger tillatelser. Én side kan ha flere visninger, men én visning bør ikke late som den er best for alle oppgaver.
| Visning | Forholdet den bevarer | Vanlig forvrengning |
|---|---|---|
| Skjematisk rutekart | Forbindelser og bytter | Fysisk avstand og retning |
| Diagram over dataflyt | Kilder, mottakere og retning | Tid og myndighet |
| Sekvensdiagram | Rekkefølge på kall og svar | Langvarig tilstand og menneskelig arbeid |
| Matrise over tillatelser | Tillatte identiteter og handlinger | Brukerens vei gjennom systemet |
Dette er prinsipielle eksempler, ikke vurderinger av bestemte produkter eller kart.
Vis utelatelsen der kartet brukes
En merknad om «ikke i målestokk» kan hjelpe en reisende å forstå et skjematisk kart. For et synkroniseringsdiagram kan bildeteksten si «viser normal retning på data; se veien ved feil og tabellen over tillatelser for skriving». Det er mer nyttig enn et generelt forbehold fordi det navngir beslutningen som mangler.
Den andre visningen bør velges ut fra konsekvensen. Hvis diagrammet brukes i en sikkerhetsgjennomgang, er tillatelser ikke valgfri bakgrunn. Hvis det brukes til å undersøke gamle poster, betyr tidsstempler og tilstand ved nye forsøk mer enn hvor boksene står. Hvis det brukes til å planlegge en ny integrasjon, kan felteierskap og veien for retting avgjøre løsningen.
Derfor kan visuell ryddighet være en felle. En pil som ikke krysser andre piler, ser ren ut, men kan skjule en vei tilbake. Like bokser antyder likt ansvar selv når ett system eier fasiten og et annet bare holder en kopi som kan kastes. Utformingen bør vise denne forskjellen når den betyr noe i drift.
Gi neste visning der den trengs
Ett diagram kan tjene flere lesere hvis det tilbyr neste visning der en beslutning trenger den. Begynn med visningen som svarer på det umiddelbare spørsmålet, og gi en lenke eller et valg til visningen som trengs videre. Hold merkelappene like, slik at leseren vet at «kunde» i flyten er det samme objektet i tabellen over tillatelser.
En nyttig gjennomgang ber noen som ikke kjenner systemet, ta to beslutninger. Først bruker de diagrammet til det det ble laget for. Så får de et spørsmål som avhenger av noe diagrammet utelater. Hvis leseren selvsikkert trekker en feil slutning, trenger utelatelsen en merkelapp eller en annen visning. Hvis de vet hvor de skal se videre, gjør forenklingen jobben sin.
Guiden til dataeierskap dekker valgene bak integrasjonen. Et kart over disse valgene bør hjelpe leseren til riktig neste steg, ikke bare se ut som en komplett arkitektur.
Et diagram kan bære sin egen test. Legg én vanlig post og ett unntak på siden, og be leseren følge begge. Hvis unntaket forsvinner ved en pil uten forklaring, skjuler diagrammet en beslutning. En versjon for ledere kan utelate feltnavn, men bør fortsatt vise hvem som har ansvar for å håndtere en feil. En versjon for utviklere kan vise skjemaer og nye forsøk, men utelate interne forhandlinger. Spørsmålet er om hver utelatelse fortsatt lar leseren gjøre oppgaven. Når en ny leser må gjette, legg til det manglende forholdet eller pek til den andre visningen, i stedet for å fylle hver ledige centimeter med bokser.
Et kart lykkes når det utelater ting med omtanke. Det feiler når det som mangler, er det leseren kom for å avgjøre.
Ofte Stilte Spørsmål
Hva gjør et forenklet diagram ærlig?
Det viser hvilken oppgave det er laget for, og hvilke forhold det bevarer, samtidig som viktige utelatelser gjøres synlige. Det bør ikke gi inntrykk av at plassering, avstand eller fullstendighet gjengir virkeligheten nøyaktig når det ikke er tilfelle.
Når trenger et diagram en visning ved siden av?
Når leseren må ta en beslutning ut fra noe diagrammet bevisst har fjernet, som fysisk avstand, tilgangskontroll, forsinkelse eller veien ved feil.
Hvordan bør et team gjennomgå et systemkart?
Be en leser gjøre den tiltenkte oppgaven med kartet. Test så en annen oppgave som avhenger av utelatte detaljer. Endre kartet eller lenk til en annen visning der utelatelsen ville villede.