Vi liker å si at vi gir kundene det de trenger, ikke bare det de vil ha. Men, noen ganger er jobben vår å bygge akkurat det kunden vil ha. Som når vi har kunder som har en teknologisk ekspertise og så tech-kyndige ansatte som kjenner alle aspekter i den nåværende løsningen, som i Twingly-caset.

Likevel, det er alltid et problem som kan løses

Twinglys egne tekniske spesialister hadde allerede kartlagt i detalj de funksjonelle krav og behov. Og vår oppgave? Å skape en bedre og mer moderne versjon av noe som allerede fungerer - og gjøre det verdt det.

Hvordan gjør vi det? Ved å bygge noe som dekker alle de funksjonelle kravene som den gamle løsningen hadde, med noen ekstra funksjonaliteter, samtidig som vi brukerne en ny og moderne opplevelse. Alt mens vi holder kostnadene nede.

Prosjektet har gått helt uten problemer. Kommunikasjonen med prosjektlederen har vært smidig, og leveringen skjedde i tråd med avtalt tidsplan. Vi er veldig fornøyd, og dette vil være en stor forbedring for produktet vårt!

Pontus Edenberg
CEO Twingly

Generell prosjektbeskrivelse

Twingly behandler/indekserer sosiale data fra blogger, forum, nyheter og andre kilder fra hele verden, og lar brukerne få tilgang til dataene gjennom deres APIer (Application Programming Interface). Innocode fikk i oppgave å hjelpe brukerne, og potensielle brukere, med å prøve ut dataene uten å måtte sende direkte APIene (og skrive kode). Derfor laget vi et nytt dashbord for Twinglys API, der hovedfunksjonen er et brukervennlig sett med filtre der selv en ikke-utvikler kan bygge sine spørringer eller forhåndsvise resultatene for hvert API.

Twingly dashboard

Tech stack

For Twingly brukte vi Ruby on Rails web-rammeverket, PostgreSQL som database for backend, og ReactJS og Material UI for frontend. Dette er en veldig grunnleggende stack og verktøy som vi bruker for prosjekter som ligner på Twingly.

Design

Design thinking, agile, business architecture

I den første fasen av arbeidet med Twingly-prosjektet identifiserte vi brukerproblemer og behov. Vi analyserte også forretningskrav og spesifikasjoner. Basert på dette utviklet vi informasjonsarkitekturen til produktet og definerte brukerroller. Vi utviklet også scenarier for samspillet mellom brukerroller og produktet.

Som neste steg valgte vi Google Material UI-rammeverket og satte opp en rask prototype basert på dette. Hver iterasjon av prototypen ble godkjent av klienten i henhold til forretningskrav og brukerbehov. Vi gjennomførte også flere raske brukervennlighetstester av prototypen for å sikre brukervennligheten.

Neste steg var å sikre web-tilgjengeligheten til produktet i samsvar med en internasjonal standard for Web Content Accessibility Guidelines (WCAG). Som et resultat leverte vi et oppdatert produktdesign og verktøy for å bygge spørringer, sammen med en klikkbar prototype med høy presisjon i Figma basert på Material UI-front-end-rammeverket.

Samarbeid på tvers

Det fineste med Twingly-caset er samarbeidet mellom to teknisk kyndige selskaper. Og resultatet? En bedre og mer moderne versjon av Twingly. Alt var verdt det!

Lyst til å lære mer?

Fra bloggen

Se alle nyheter
  • Startup-feilene som styrer deg mot stupet

    Veien mot en vellykket startup er overstrødd med snublesteiner, men likevel er det altså noen som lykkes. Etter mer enn ti år som utviklingspartner for en rekke vellykkede startups, har vi merket oss noen feilsteg som øker sjansen for å se prosjektet som et rykende vrak i virkelighetens digitale grøftekant. Her er vår guide til deg som vil mislykkes rask og effektivt.