Omdesign Adobes filtype Ikon System Sprog

I teamet Adobe Design Brand opretter vi branding til alle vores desktop-, mobil- og webprodukter. Et brandet element kan være alt fra de to bogstaver produktlogoer, du ser på din dock, til splashskærmen og ikoner inden for brugeroplevelsen af ​​selve produktet.

En ofte overset men meget synlig funktion er filtypeikonet. En filtype er et navn, der gives til en bestemt filtype, som en applikation kan oprette, f.eks. DOC til en Word-fil. Ikonet for filtype er det ikon, der er tildelt filtypen, og hvad der vises på din skærm, når du gemmer eller åbner den aktuelle fil.

Med den nyeste udgivelse af Creative Cloud dette efterår vil brugerne se, at alle vores filtypeikoner har et friskt, nyt look! I denne artikel vil jeg undersøge tankegangen og processen bag vores seneste redesign af Adobes filtypesymbolssystem og dele indsigt om de udfordringer, vi står overfor med at udvikle et brand-system på tværs af en enorm familieprodukt.

Identificering af problemet

Mange kunder er måske ikke klar over, at Adobe har mere end 100 produkter og tjenester på tværs af tre skyer: Creative Cloud, Document Cloud og Experience Cloud.

Dette betyder, at en lille ændring i designsystemet kan skabe hundreder af ændringer overalt.

Når det kommer til filtypeikoner, overvejer folk ofte kun de primære filtyper af et program, som:

  • .PSD til Photoshop,
  • .AI til Illustrator eller
  • .INDD til InDesign

De fleste af vores produkter kan imidlertid også importere og eksportere en række sekundære filtyper (for eksempel har Photoshop alene over 120 forskellige filtypeikoner kortlagt i sit register).

For at optimere til forskellige operativsystemkrav skal vores filtypesymboler også manuelt pixelknipses i 10 forskellige størrelser og derefter leveres som et sæt rasteriserede. PNG'er, der pakkes sammen i .ICNS (Mac) og .ICO (Windows) filer.

Når vi indgår i antallet af størrelser og formater for hvert ikon for filtype, ser vi på over 7.000 aktiver, der skal ændres og administreres med hver udgivelsescyklus.

I takt med, at Creative Cloud's produktlinje er vokset i de sidste fire år, blev det klart, at den krævede indsats for at oprette og vedligeholde disse filtypeikoner i den eksisterende arbejdsgang ikke længere kunne skaleres.

Trin 1: Revision og undersøg

Inden vi kunne begynde at redesigne systemet, måtte vi undersøge, hvad vi i øjeblikket bruger i vores produkter. Vi nåede til hvert produktteam for at hjælpe os med at gennemføre en revision af alle deres filtypeikoner.

Uoverensstemmelser var overalt, og de var sandsynligvis et resultat af to faktorer:

  1. Forskellige teams, der ejer hver produktfamilie og ikke længere tilpasser sig designet, og
  2. Når nye produkter og filtyper kommer online, oprettes individuelle ikoner som engangsdesign.

Med de oplysninger, der blev indsamlet fra vores revision, opbyggede vi et fugleperspektiv af den eksisterende filtypearkitektur.

Først organiserede vi filtypeikonerne efter produktfamilien og krydshenviste dem for at se, hvilke sekundære filtyper der blev delt mellem flere applikationer, så vi kunne fjerne duplikatikoner. Ved at gøre dette kunne vi skære antallet af sekundære filtypeikoner ned til 65%.

Et uddrag af vores gamle filtypearkitektur organiseret af produktfamilien.

Dernæst kategoriserede vi filtyperne efter funktion, f.eks. "Billede", "Lyd", "Kode" og "3D." Typisk vil et filtypeikon have en metafor, der taler til dens vigtigste funktionalitet (f.eks. En. HTML-filtype bruger parentesmetaforen til at formidle, at dens funktionalitet er relateret til kode eller kodning).

Et uddrag af vores gamle filtypearkitektur organiseret efter funktionalitet.

Vi bemærkede, at nogle filtyper brugte flere versioner af den samme metafor, mens andre havde tilpassede metaforer, der kunne erstattes med et mere generisk ikon. Vi begyndte at oprette brede paraplygrupper af filtyper for at tildele en enkelt metafor til hele familien. Dermed kunne vi reducere antallet af filtypemetaforer i vores bibliotek med mere end halvdelen.

Et snapshot af nogle af de gamle metaforer af sekundær filtype.

Trin 2: Skitse og design

Når vi havde et omfattende overblik over det gamle system, begyndte vi at etablere de grundlæggende organisationsprincipper for det nye:

  1. Kun primære filtyper får produktlogoets farveforening. For eksempel ville .PSD være blå og .AI være orange.
  2. Opret en neutral palet til sekundære filtyper, der understøttes af flere applikationer. For eksempel vil Photoshop og Illustrator bruge det samme .PNG-filtypeikon i stedet for at hver have deres egen unikke version af ikonet gennem mærkefarveforening.
  3. Opret et hovedbibliotek med filtypemetaforer for at holde ikoner ensartede og undgå at tilpasse aktiver til kantsager.
En fordeling af komponenterne i det gamle filtypeikon.

Vi begyndte at tegne med denne nye ramme i tankerne.

Et snapshot af tidlige processkitser.

En af de vigtigste drivere bag redesignet var at forenkle og fjerne så mange elementer på filtypeikonet uden at miste dens betydning. Vi faldt tagget og flyttede filtypemimet til bunden af ​​ikonet. Vi fjernede også sidekrøllen for at flade designet og skabe et mere moderne visuelt sprog.

Udviklingen af ​​Adobes filtypeikon.

En anden vigtig driver var tilpasning til Spectrum - Adobes nye UI-designsprog - som i øjeblikket rulles ud i alle vores produkter. Mod denne indsats rundede vi hjørnerne af vores ikoner for filtype og begyndte at opbygge et bibliotek, der enten brugte eksisterende metaforer fra Spectrum-databasen eller skabte nye, der var på linje med deres illustrationstil.

Et snapshot af Adobes Spectrum Icon-database.

Endelig inkorporerede vi den klare farveoversigt i filtypeikonet for at binde ind i den eksisterende branding af vores produktlogoer. Denne ændring skabte ikke kun et mere sammenhængende visuelt system, men de nye ikoner blev bedre i mørke grænseflader, hvorimod vores gamle ikoner forsvandt i baggrunden.

En undersøgelse i farvekontrast på mørkt UI.

Trin 3: Iterere og afslutt

Efter at vi besluttede en designretning, testede vi de nye filtypeikoner i sammenhæng. Under den indledende revision undersøgte vi alle de områder, hvor filtypeikoner vises i forskellige operativsystemer og inden for vores egne produkter. Vi kiggede også på hver sammenhæng, hvor ikonerne blev vist i forskellige størrelser og opløsninger.

På både Mac- og Windows-desktopskærme var vi nødt til at tage højde for ikonerne, der vises i Liste versus gittervisninger i forskellige skalafaktorer (16px er den mindste størrelse helt op til 512px som den største). Der var også spørgsmålet om lys kontra mørkt brugergrænseflade, f.eks. I "Seneste genstande" eller "Spotlight Search" på Mac-skrivebordet. Derefter undersøgte vi, hvor vores filtypeikoner vises i vores egne produkter, som f.eks. I aktiveringspanelet, mediebrowser-dialogen og velkomstskærmen, når du først startede et program.

Som man kan forestille sig, førte denne proces os hurtigt ned ad et kaninhul af alle de obskure og glemte hjørner af vores system, hvor filtypeikoner bor. Stadig var det en værdifuld øvelse. Vi bliver nødt til at pakke vores hoveder mere om opgaven.

Et uddrag af de forskellige kontekster, som vores filtypeikoner vises i.

Det sidste trin var at se på filtypeikonerne implementeret i brugergrænsefladen for vores web- og mobiltjenester, f.eks. Adobe Acrobat og Creative Cloud Libraries. Da disse tjenester også blev administreret af forskellige designteams, var vi nødt til at koordinere med en masse mennesker om vores plan om at gennemgå filtypesystemet.

Vi er stolte af det endelige resultat, fordi det nye designsprog er klarere, mere konsistent og repræsenterer den næste udvikling af Adobes visuelle brandsystem.
Adobes nye filtype-ikondesignsystem.

Trin 4: Design en ny arbejdsgang

Vi oprettede en ny arbejdsgang til produktion, der brugte scripting-funktionalitet i Illustrator til at komponere og eksportere .PNG-filerne med et tryk på en knap. Denne nye skabelon sparede os dusinvis af timers smertefuldt langsomt og manuelt arbejde.

Vi havde også brug for en bedre måde at samle disse rasteriserede. PNG'er til .ICNS (Mac) og .ICO (Windows) filer. Tidligere brugte vi IconBuilder-plug-in fra IconFactory med vores fyrværkerisk skabeloner. Men med den nye arbejdsgang ønskede vi en mere fleksibel løsning, der kunne imødekomme vores behov: primært muligheden for at trække og slippe ethvert sæt af. PNG-filer og få applikationen automatisk til at udføre både .ICO- og .ICNS-filer i de rigtige størrelser.

Efter at have søgt efter en tredjepartskompiler, besluttede vi, at det var bedre at samarbejde med vores ingeniører om at oprette en intern app, tilpasset til vores behov. De skabte et fantastisk værktøj, som vi kærligt kaldte Captain Icon, som er den kompilator, vi brugte til at pakke alle vores nye ikoner for filtype. (Mens Captain Icon stadig er i intern beta, håber vores ingeniører at dele det på GitHub i den nærmeste fremtid, så det kan være tilgængeligt for vores udviklerfællesskab at bruge!)

Adobes interne .ICO og .ICNS compiler.

Trin 5: Implementering

Vi er stadig i denne fase og vil sandsynligvis være i lang tid. Hver gang vi sender en Creative Cloud-udgivelse, gennemgår vi en proces, der involverer produktledere og ingeniører på tværs af mange hold, og sørger for, at designet gennemføres overalt.

Implementering er ofte en kedelig proces med at kommunikere frem og tilbage med teams i hundreder af e-mail-tråde, installere flere test build-versioner for at kontrollere aktiver, logge og fejlsøge uundgåelige bugs og styre flere frigivelsesfrister.

Vores produkter er også bygget på forskellige kodebaser, hvilket betyder, at hold kan implementere de samme aktiver forskelligt og finde problemer, der er unikke for hver platform. Kvalitetssikring og håndhævelse af brandretningslinjer er sandsynligvis en af ​​de mindst sjove opgaver for vores team, men det er en vigtig del af vedligeholdelsen af ​​et udviklende designsystem.

Adobes nye ikoner for filtype lever i operativsystemet.

Små ændringer kan gøre en stor forskel

I vores team bruger vi ofte metaforen fra bonsaitræet til at beskrive det arbejde, vi udfører.

At udvikle et brand design-system, der indeholder hundreder af produkter, er afhængig af en million små, trinvise ændringer undervejs - vi snip en gren her og der og guider træet til at vokse i vores ønskede retning over tid.

Selvom det er let at gå tabt i detaljerne, bærer alt, hvad vi lærer i processen, os videre til næste iteration og den næste efter det.