Het ontwikkelen van mijn product kan natuurlijk niet verder als er geen bewijs is dat het levensvatbaar is binnen de doelgroep en de organisatie binnen mijn scope. Daarom wil ik door middel van een Proof of Concept aantonen dat mijn idee daadwerkelijk poten heeft om op te staan. Eigenlijk zijn de Usability Tests al een (groot) onderdeel van het POC. Hier heb ik al aangetoond dat de gebruiksvriendelijkheid en wenselijkheid levensvatbaar zijn binnen de doelgroep. Aanvullend wil ik graag kijken wat ervoor nodig is om het product te realiseren, beginnend met de succescriteria. Daarna ben ik van plan om met een full-stack developer te kijken wat het qua development gaat kosten. Verder kijk ik terug naar het Programma van Eisen om te kijken of ik een Minimum Viable Product (MVP) heb kunnen realiseren en als laatste wil ik natuurlijk een oordeel horen van de bedrijfseigenaar, ofwel mijn opdrachtgever.
Aan de hand van de laatste versie van mijn design challenge heb ik hieronder de (belangrijkste) succescriteria genoteerd. Hier reflecteer ik op aan de hand van mijn onderzoek en resultaten.
Het product moet flexibel te gebruiken zijn
De grootste eis met betrekking tot flexibiliteit is dat het concept zowel op kantoor als thuis goed te gebruiken is. Doordat het concept de vorm heeft aangenomen van een digitale applicatie, is dat geslaagd. De ultieme vorm van flexibiliteit komt pas wanneer er een app aan het concept gekoppeld wordt. Dit heb ik in de user stories opgenomen in de derde release. Het is niet belangrijk voor het Minimum Viable Product (MVP), maar geeft de jong professionals wel de vrijheid om on-the-go en via meerdere digitale apparaten hun afspraken in te plannen en te beheren.
Het product moet overzicht op alle afspraken geven
Dit heb ik kunnen realiseren voor middel van de verschillende vormen overzicht. Als eerste is er het overzicht van jouw eigen afspraken. Dit is vormgegeven in een (werk)week format, maandag tot en met vrijdag. Daarnaast zijn de afspraken die hierin staan visueel gescheiden op basis van het type. Op het type afspraak kan ook nog eens gefilterd worden.
Het tweede overzicht zijn de afspraken per team. Hier zullen voornamelijk terugkerende afspraken in komen te staan. Voor het SEO-team zijn dat bijvoorbeeld wekelijkse spar sessies en voor het web team de twee-wekelijkse projecten voortgang.
Het derde overzicht zijn de vergaderruimtes. Hier kan per ruimte bekeken worden wat voor afspraken er gepland staan. Dit is wederom vormgegeven in een (werk)week format en de afspraken zijn net zoals in de persoonlijke planning visueel gescheiden op basis van het type.
Als laatste kun je als gebruiker de dagplanning van je collega’s bekijken. Doordat alle aparte overzichten een eigen doel hebben, vind ik dat deze eis is behaald.
Het product moet ervoor zorgen dat jong professionals minder tijd kwijt zijn met het inplannen van afspraken en het beheren van hun planning(en)
Een jonge professional is met het gebruik van mijn concept in ieder geval minder tijd kwijt met het beheren van zijn afspraken. Dit kan ik zo stellig beweren, omdat overzicht één van de belangrijkste uitgangspunten is voor het concept. Hier boven heb ik beschreven op wat voor manieren er overzicht wordt gecreëerd voor de gebruiker.
Het aanmaken van een nieuwe afspraak kan door middel van twee flows. De eerste flow is eigenlijk de standaard flow. De gebruiker loopt door een formulier wat versimpeld is door middel van progressive disclosure en plant een afspraak in. De tweede flow maakt het mogelijk dat een klant zelf een afspraak kan inplannen. Een gebruiker kan zijn agenda delen. Hierdoor ziet een klant (in een aparte omgeving) welke data en tijden er beschikbaar zijn. Dit scheelt tijd, omdat er geen mailconversatie aan vooraf gaat waar constant data en tijden gestuurd worden waarop niemand beschikbaar is.
Doordat het concept veel automatiseert, wordt ook het inplannen van afspraken eenvoudiger en sneller voor een gebruiker. Hierdoor is dit criterium ook behaald. De uitgebreide specificaties van de back-end processen en automatiseringen zijn te lezen bij Hi-Fi prototype > back-end processen.