Når Design møder Engineering hos Traveloka

Dette er ikke en almindelig kærlighedshistorie.

Bemærk: Dette er kun en af ​​interaktionerne mellem design og teknik. Jeg taler fra et lille spektrum af alle interaktionerne mellem Design og Engineering i Traveloka. Og dette er min historie.

Som tiden går, har Traveloka eksisteret i 6 år. På denne rejse indrømmer vi, at vi har en masse visuelle bugs, der har været der i et stykke tid, som forskellige orange nuancer til knapper eller inkonsekvent margen mellem kortene.

Designteam startede indsatsen for at standardisere vores visuelle sprog ved at bygge vores eget designkit for at forhindre nye visuelle afvigelser, der afviger fra vores standard. Vi prøvede, men på en eller anden måde løst dette problem aldrig. Selv efter at vi har vores eget designkit, ser vi stadig de visuelle uoverensstemmelser på vores produkter.

På den anden side er vores ingeniører nødt til at arbejde mere effektivt. De foretrækker at bygge lignende komponenter fra bunden af ​​i stedet for at se op for at finde den samme komponent til genbrug. Fordi søgning efter disse komponenter er en friktion i deres aktuelle arbejdsgang.

I alle disse tider forsøgte designteamet og ingeniørteamet at løse deres eget problem uden at kommunikere med hinanden. Det stillede spørgsmålet om muligheden for, at design og teknik samarbejder for at løse det problem, som vi begge støder på hver dag. Hvem vidste, at design og teknik kan gå hånd i hånd og skabe kærlighed i processen?

Hvornår mødtes de først?

Forhandlingerne startede i begyndelsen af ​​2018, da ingeniørteamet gjorde noget research på React Native og React Native Web (React Native er en ramme for at opbygge mobile apps ved hjælp af JavaScript). Da denne undersøgelse startede, blev Web UI-udviklere fra designteam involveret.

Under processen havde ingeniørteamet ideen om at bruge React Native som base til udvikling af tværplatforme. Dette inkluderer udviklingen af ​​mobilweb, som Web UI-udvikler kan involvere for at oprette komponenter på det.

Da dette initiativ begyndte, var vi så begejstrede for at lære React Native og få det bedste ud af det, da vi kan gøre en mere markant indflydelse og skabe komponenter til alle tilgængelige platforme fra en enkelt kodekilde. Og det er her vi først lærer hinanden at kende.

Hvordan kærligheden voksede?

Vi mødte hinanden et par gange derefter, men intet gnistrede i vores hjerte. Men så dukker gnisten op, når vi har denne praktikant. Det hele startede så simpelt som et internt projekt.

Denne praktikant er en React Native engineer og har til opgave at bygge noget, der kan glatte samarbejdet mellem Design og Engineering. Han begyndte at bygge et komponentbibliotek, nogle mindblæsende skisseplugins til designere og undersøge andre samarbejdsmuligheder mellem Design og Engineering.

Bortset fra det havde Designteamet også initiativet til at lave en kodebaseret enkelt kilde til sandhed (SSOT) til designtokener og komponenter. Disse to bevægelser inspirerede os til at samarbejde om denne mission. Det er her, kærlighed gnister, og vi tror, ​​at vi løber ind i en lysere fremtid sammen.

Hvor kærligheden førte os?

Efter flere gange at have dateret (læs: møde) er vi endelig enige om at tage vores forhold til det næste niveau. Det var ikke let at gå på, men vi troede, at dette er den rigtige for os. At forstå hinanden er den vigtige nøgle til et godt forhold, ikke? Og det var hvad vi gjorde, da vi besluttede at samarbejde.

Vi startede med at forstå, hvordan hinanden fungerer. Og efter disse nætter fulde af mareridt og veje fulde af forhindringer er vi endelig på vej mod det bedre samarbejde. Her er vores forpligtelser til at opnå det bedre samarbejde mellem Design og Engineering:

1. Kodebaseret designsystem.

Samarbejdet mellem design og teknik har været ret udfordrende. Broen mellem design og kode er ikke stærk nok, og det gjorde, at arbejdet blev hårdt mellem os.

Derefter fik vi ideen om at oprette et kodebaseret designsystem. Vi lægger vores designtoken i JavaScript, som er den nemmeste måde for ingeniør at bruge, men alligevel stadig enkel nok til at designeren kan styre.

Vi samarbejder om at opbygge vores egne håndlavede komponenter, der opfylder Design's og Engineering's standard. Disse komponenter vil blive brugt på alle platforme for at skabe sammenhæng i vores design.

2. Skit plugins.

Disse Sketch-plugins fungerer som broen mellem design og koder. På designsiden gør dette samarbejdet lettere, fordi designere ikke behøver at generere de samme komponenter igen og igen. Dette vil også hjælpe designer med at opbygge deres brugergrænseflade baseret på de standardiserede komponenter.

På ingeniørsiden oversætter dette plugin brugergrænsefladen til koder, der let kan implementeres af ingeniøren. Dette reducerer ingeniørens arbejdstid, fordi de ikke behøver at kigge efter eksisterende komponenter fra det forrige design.

3. Design linter og integreret visuel test.

Efter at have arbejdet med brugergrænsefladen og koden, er det næste trin at sikre sig, at begge er standardiserede. Det var her designlinter og integreret visuel test deltog. Vi undersøger i øjeblikket muligheden for at udvikle designlinter og integreret visuel test til at fungere som et sikkerhedsnet til både vores brugergrænseflade og koder. Fra designsiden vil designlinter opmuntre UI Designer til at bruge standardiserede komponenter. I mellemtiden fra den tekniske side vil visuel test reducere muligheden for visuelle afvigelser, når produktet frigives. Dette vil gøre livet for både designer og ingeniør lettere i fremtiden.

4. Design systemdokumentation.

Når du samarbejder med forskellige hold, er det rart at have en retningslinje, som du begge kan henvise til. Designsystemdokumentation fungerer som designbibelen, der er tilgængelig for alle interessenter, herunder produktledere, ingeniør og mededesignere. Dette er vigtigt for at sikre, at alle er på det samme bord, hvorfor der træffes en designbeslutning. Dette vil også hjælpe med at undgå enhver design uenighed mellem teamet, fordi ethvert design er omhyggeligt lavet med omhyggelig overvejelse.

Illustration af Ralistu Hayu Pratiwi

Med alle disse babytrin tror vi, at vi kan skabe bedre fremtidig samarbejde og integration mellem hinanden. Samarbejdet åbner også muligheder for at skabe bedre produkter.

I sidste ende er design af et produkt ikke bare, hvordan man får det til at se smukt og interessant ud. Der er også masser af tekniske anstrengelser for at gøre design fungerer fejlfrit. Dette illustrerer vigtigheden af ​​samarbejde mellem design og teknik; da vi ikke kan leve uden hinanden i at opbygge et godt produkt. Som Steve Jobs sagde,

”Design er ikke kun, hvordan det ser ud og føles. Design er sådan det fungerer. ”