Figma prototype – ForeningsMatch

https://www.figma.com/file/59dViqwB7fXthj3RMYhTFY/Prototype?node-id=1%3A3 

Kort opsummering

Vores problem/problemstilling er fortsat: Mænd har svære ved at komme i gang og få en aktiv livsstil, hvilket leder til sundhedsmæssige problemer senere i livet (en mere detaljeret beskrivelse af mænds sundhed kan findes i rapporten fra: Forum for Mænds Sundhed 2016).

Vores vision er fortsat: Hold raske mænd (50-65 år), raske ved at få flere med i sportsforeninger, og dermed give flere mænd en aktiv og sundere livsstil.

Beskrivelse af vores prototype

Artefaktet er et plug-in/program som skal gøre det lettere at starte i en sportsforening. Det virker som et banner i toppen af sportsforeningernes hjemmeside, som linker videre til vores webprogram. På banneret kører mulige matches i karrusel.

Helt konkret så skal vores program gøre det let og hurtigt for voksne/ældre mænd med motivation til at starte i en forening med andre ligesindede (hvis nødvendigt) og give dig en personlig kontakt i form af en ildsjæl (allerede medlem af sportsforeningen), der kan hjælpe dig sportsligt og socialt med at komme godt igang. Ved at udfylde nogle parametre finder vores service den ildsjæl eller makker som passer bedst til dig. På den måde løser vi en række problemer, som vi har snakket med vores brugere om.

Problemer ForeningsMatch løser

– Med vores program ved man, at man starter med en på samme niveau og skal derfor ikke være nervøs for, om man er for dårlig til at være med i en given forening – Det gøres lettere komme ind i foreningerne og fordi der er færre usikkerheder, så bliver det mere trygt at starte. Når man har en makker, så trækker man lidt hinanden, fordi man er forpligtet overfor hinanden.  – Hvis man selv har motivationen, så gør vores program det meget simpelt at omsætte motivation til handling, fordi man kan komme direkte i kontakt med folk, som har samme motivation – Der er fleksibilitet, fordi man kan finde personer, som vil træne på præcis samme tidspunkt som dig. Ved at gøre det lettere og mere trygt at komme ind, så skulle der gerne starte flere folk i foreningerne. – Foreningerne har problemer med at få nye medlemmer og dette kan være en løsning – Ved at også få en slags mentor og/eller en fast makker i foreningen, håber vi på, at det kan mindske problemet med, at folk hopper tidligt fra. Hvis de kommer godt ind og starter med en anden, så bliver de der måske længere

Problemer ForeningsMatch ikke løser

– Trækker ikke rigtig folk med, som ikke selv har en motivation. Det er ikke sikkert der kommer en person som trækker dig til sporten.  – Gør ikke noget ved det problem, at det i foreninger ofte kan komme til at handle lidt meget om formaliteter og lidt mindre om sport. Derfor kommer vi heller ikke til at adressere muligheden for at finde sammen med mindre fællesskaber, selvom det er et tydeligt mangel og godt at have med. – Man bliver en del af en forening hvormed fleksibiliteten bliver mindre, men interviewperson har sagt: (Hvis man vil, så har man tid….). I og med man skal vælge hvornår man vil træne via kalenderen, prøve vi så godt som muligt at imødekomme denne udfordring.

Sortering af problemer, ideer og løsninger

Billede 2 – Idéer og problemer sammenhæng

Link til den: https://docs.google.com/document/d/1_1uad6eSG89RFS7G00UW_1gsSY-ok5IIK-xXLS9Squo/edit?usp=sharing

Gennem vores feltarbejde, interviews og brugerworkshop fik vi samlet en masse viden. I vores sortering af problemer fik vi italesat de udfordringer vi er stødt på og fik en forståelse for de samlede udfordring der kan være ved at starte i forening. Ifølge Schön (1992) sker der gennem naming og framing en form for “worldmaking”. Når vi italesætter de problemer, som vi er stødt på og har fundet frem til, får vi skabt en indgangsvinkel på foreningsverden. Gennem denne proces reframer vi også hele tiden vores forståelse, da ny viden og information giver nye perspektiver, som skal inkorporeres i vores forståelse af problemet. 

I vores “sortering af problemer”, skabte vi et “katalog” over de essentielle problemer og udfordringer som brugere står overfor når de skal starte i en sportsforening. Processen med at name og frame hjalp os derfor med at få et samlet overblik over udfordringerne, så vi havde nemmere ved at finde en indgangsvinkel og kondensere idéerne yderligere, for at nå frem til den idé som bedst løser flest af de problemer vores brugere har tilkendegivet. Målet var ikke at samle så mange løsninger som muligt i et koncept, men udvælge de problemer vi så som de største og blive nødt til at fravælge andre, så vi kunne udarbejde en simpel og brugervenlig prototype.

På denne måde står vi også tilbage med en unik sammensætning af problemer som kræver en unik måde at gribe det an. Vi kan altså ikke bare anvende teorier og teknikker som vi tidligere har lært, men skal arbejde os ud over dem og anvende dem på ny.

Mock-ups/Scenarier

Disse mock-ups/scenarier kan ses i deres fulde version via følgende link: https://drive.google.com/file/d/1DxJ9X7Deammmkj5xLPaXYbKHytyASde7/view?usp=sharing

Med denne sortering af problemer og løsninger lavede vi fire forskellige mock-ups/scenarier (bare mock-ups fremover), da vi havde fået meget forskelligt input fra vores feltarbejde, interviews og brugerworkshop omkring hvad et eventuelt produkt skal kunne for at løse vores vision. Fælles for disse mock-ups var, at de havde et formål om at få flere mænd med i sportsforeninger. Disse mock-ups varierede på materiale, funktionalitet og interaktivitet, for at finde frem til det bedste overordnet koncept og de delkomponenter i koncepterne som fungerede godt via feedback fra vores brugere. 

Vi har blandet mock-ups og scenarier fordi vi skulle tilpasser os den begrænsning der består i, at vi ikke kunne være fysisk til stede med vores brugere. Derfor besluttede vi, at vi måtte begrænse hvor meget mulighed for “hands-on” vores brugere kunne have og i stedet visualisere den konkrete brugssituation for dem, så de kunne forstå konceptet i brug. Målet med disse mock-ups blev derfor at gøre dem forståelige og få bekræftet hvad der fungerede i vores koncepter, men på den bekostning at brugerne ikke ville få meget mulighed for at modulere og interagere med produktet, hvilket ellers fremmer brugerinddragelse til mere end bare en refleksion (Ehn & Kyng, 1991, s.172). Eftersom de ikke kunne opleve vores artefakt, skrev vi en narrativ handling ind i vores mock-ups. Vores intention med dette var at gøre det lettere at forstå hvordan vores artefakt skulle bruges i en kontekst. 

Feedback på Mock-ups

Sammen med et feedback skema sendte vi vores mock-ups ud til vores brugere. Vi bad dem her om at udfylde hvad de kunne lide, og hvad de ikke brød sig om, ved hver af vores idéer. Ud over dette, bad vi dem også om at rangere de fire idéer, så vi på en meget overskuelig måde kunne se, hvilke de bedst kunne lide. Til sidst var der plads til, at de kunne komme med ekstra kommentarer. Fordi vores mock-ups bare var tegninger, så var det let for brugerne at kritisere vores design, uden at de følte, vi havde spildt vores tid. Vi brugte dem derfor mest som et evalueringsredskab jf. Ehn og Kyng 1991 (Ehn og Kyng 1991, s. 192)

I vores evalueringsproces var det muligt at få testet forskellige aspekter af vores koncepter. De havde nogle fælles elementer, men var varierende i omfang. Derfor fik vi feedback på, om det skulle være en app, en hjemmeside eller et fysisk artefakt, hvor stor en rolle ildsjælene skulle spille, om de overhovedet skulle være med og hvilken vinkel vi skulle have på foreningernes rolle.    

Det vi fik ud af feedbacken var for det første at produktet skulle være en del af en hjemmeside (banner), som var en ny måde at manifestere vores koncept på. Dette løste vores problem med at brugerne ikke ville have en app eller det fysisk alternativ, en interaktiv tavle, som vi havde i vores mock-ups; “Jeg tror tavlen hurtigt vil blive glemt”, “Hader apps”. For det andet fik vi bekræftet, at det med at matche folk var en nøglefunktion og at det skulle både være ildsjæle og makkere, fordi det hjælper med at dække de forskellige individuelle behov som de nye-medlemmer måtte have, for at blive aktiveret; “Rigtig god ide, alle foreninger kan sagtens blandt deres medlemmer finde ildsjæle, der gerne vil være kontaktperson til nye medlemmer.”, “Jeg kan godt lide, at den tager udgangspunkt i et individuelt problem/ønske/behov”, “At man vælger folk til“. For det tredje, så var brugerne også glade for at udfylde parametre, fordi de kunne gøre ansøgningen til deres “egen” og derved tage et informeret valg når de skulle vælge at matche med en, fordi det ikke blot var overfladisk information; “Profil med masser af information, så profilerne bliver detaljeret og man undgår at tale forbi hinanden” “Køn, niveau, tidsrum”.

Link til hele feedbacken: https://docs.google.com/document/d/1clUDdGdS_k58DrdZBWlHYoapA-ARpHKR4N3kJyxp5GM/edit?usp=sharing

Skitsering af ForeningsMatch

For at få en idé om hvordan konceptet, som helhed, skulle fungere/se ud lavede vi en hurtig skitse af ForeningsMatch, hvor vi blev enige om, at vi ville fokusere på funktionaliteten fra det potentielle nye medlems perspektiv i forhold til hvordan de matcher og interagere med folk i programmet. Målet med skitsering var at eksternalisere vores ideer, således, at vi kunne se hvordan produktet ville fungere skridt for skridt. Denne skitse gjorde det lettere at arbejde med prototypen, da vi derved alle havde en fælles idé at tage udgangspunkt i. 

Prototyping

Efter skitseringen af vores prototype, havde vi nu et overblik over hvilke funktioner vi skulle lave til vores produkt i Figma. I vores arbejde med at skabe en prototype fulgte vi prototypings fire trin fra Floyd (1984) artiklen “A systematic look at prototyping”; Functional selection, construction, evaluation og further use. Det er her vigtigt at pointere, at vi gennem processen arbejdede med function selection og construction parallelt. I denne opgave har vi derfor valgt at samle de to, for at give et mere præcist  indblik i de tanker, som lå til grund for vores valg. Vores formål med prototypen var evaluering og at få den rettet efter feedback fra evaluering. Derfor var evaulation og further use stadig opdelte trin i vores opgave, da de også var det i vores arbejde.  

Når man skal bygge en prototype, så skal man være bevidst om ens materialer og hvor mange aspekter af ens design idé, som ens prototype udfylder. Vi så på de hensyn, som lim et al. beskriver om manifestationen af ens design (Lim et al., 2008, s. 3). Fokuset i denne prototype var at vise brugerne en overfladisk gennemgang af vores program, men med et yderligere fokus på at illustrere den sociale interaktion mellem det nye medlem og en ildsjæl. Målet for prototypen var derfor at teste interaktiviteten, derfor var scopet (Lim et al., 2008, s.3), på de dele hvor interaktionen foregår. Efter vi havde fået styr på scopet for vores prototype, valgte vi at Figma ville være en passende måde at manifestere vores prototype, da dette program er godt til let og hurtigt at simulere hvordan et program vil fungere hele vejen igennem, samt at vise den sociale interaktion, de steder det skete.

Efter at have udtænkt manifestationen af vores prototype, udvalgte vi hvilke filtrerings dimensioner (Lim et al., 2008) som vi var interesserede i vores prototype. Grunden til at filtrere nogle dimensioner fra, når vi arbejder med protype kan forstås via Det fundamentale prototype princip; “the purpose of designing a prototype is to find the manifestation that, in its simplest form, will filter the qualities in which the designer is interested without distorting the understanding of the whole” (Lim et al., 2008, s.10), som argumentere for at ens prototype skal være så simpel som mulig og kun indeholde de dimensioner, der er nødvendige for at forstå helheden af programmet. Derfor valgte vi at fokusere på tre nedenstående parametre, da disse er centrale for at teste brugernes anvendelse af programmet, i forhold til at de synes at det er let og forståeligt at anvende i praksis. Vi vil nemlig argumentere for at et funktionelt system, som kan behandle data, ikke er vigtigt at prototype, da det var selve udseendet og interaktiviteten, vi var interesserede i at teste med prototypen, dette gjorde det også lettere for os at tilpasse/udvikle videre på den i forhold til brugernes feedback. I det følgende vil vi præsentere hvorfor vi netop har valgt Appearance, Interactivity og Spatial Structure som vores filtreringsdimensioner:

• Appearance: Da vi arbejdede med en aldersgrupper på 50+, så havde vi fokus på, at vores design skulle være simpelt og stort. I vores feltarbejde og tidligere interviews havde vi oplevet, at de generelt bedre kunne lide at bruge ipads og computere end deres telefon, da skærmen var større. Vi udarbejdede derfor et design med store knapper og delte processen op i flere trin, så det var let at skabe sig et overblik over, hvad der skete på hver enkelt side. Vi holdte os ligeledes til de samme farver hele vejen igennem og byggede matchsiden op som en valgtest, som vi kender fra medierne i valgperioder og læner os dermed op af noget genkendeligt. 

Billede  11 – Ildsjæl/makker side

• Interactivity: Da vi gerne ville vise interaktiviteten i programmet og hvad det kunne, har vi valgt at putte dette som et centralt parametre. Dette skyldes i høj grad at vi vil sikre os at vores målgruppe kunne forstå at anvende programmet og derved interagere med det og dets funktioner, således at de kunne anvende programmets centrale funktioner. Endvidere ville vi også gøre det interaktiv, så vi kunne putte et særligt fokus på den sociale interaktion, vi havde forestillet os ville foregå i programmet, selvom selve funktionen ikke var udviklet i prototypen (altså intet bagvedliggende system, der kan håndtere match, chatbeskeder osv.).

• Spatial Structure: Vi ønskede at lave et simpel interface, da aldersgruppe er 50+. Derfor har vi forsøgt at efterleve Normans (2013) princip om god mapping, for at gøre det let at vide og forstå sammenhængen mellem når man trykker/holder musen over noget og den effekt det har (Norman 2013, s.21-22). Dette kan bl.a. ses i “boksen vælg mig” og ikonet  “pie chart med spørgsmålstegn”. Her har vi gjort det let ved hjælp af tydelige signifiers (Norman 2013, s.19). Denne filtreringsdimension er vigtigt, for at brugerne ikke bliver forvirret over interfacet når de tester prototypen, hvilket kan forstyrrer forståelsen. 

Function selection og construction:

I processen med at udvælge funktioner lagde vi os tæt op af den feedback vi havde fået på vores koncepter. Vores prototype indeholdt både horisontale og vertikale nedslag.  

Horisontalt: Vores prototype indeholder alle de trin,  vi har tænkt at programmet skal indeholde. Vi er dog ikke gået i dybden med dem alle, fx er der ingen interaktivitet ved “kalenderen” og dagene er allerede valgt på forhånd. Grunden til at vi har valgt at vise alle trinene er, at vi vil give en “holistisk” fornemmelse af prototypen, så det er nemmere for eventuelle brugere eller klienter at forstå prototypen i sin helhed. Dette var også tilfældet i vores designproces med brugerne, da visualiseringen af alle skridt i vores service, gjorde det nemmere for brugerne at forstå vores ideer og give brugbar feedback. I modsætning til de mock-ups vi sendte ud, havde brugerne i evaluering af prototypen en større tendens til at kommer med “kritik” som tog udgangspunkt i meget konkrete dele af vores prototype (se afsnit: evaluering af prototype). Dette kunne skyldes, at de her havde mulighed for at se hvert enkelt step visualiseret i forhold til mock-ups hvor ideerne blev præsenteret på en mere “overfladisk” måde, hvor ikke alle trin var med. 

Vertikalt: I vores prototype havde vi også enkelte eksempler på funktioner, hvor vi var gået mere i dybden, med det formål at illustrere den sociale kommunikation og  interaktion som vores program fordre. Dette ses blandt andet på siden, hvor man skal vælge en ildsjæl/makker. Her har vi arbejdet mere i dybden ved at skabe personaerne for bedre at illustrere de typer af mennesker, vi har mødt og som ville anvende programmet som en ildsjæl/makker. Endvidere har vi også lavet et vertikalt nedslag i brugeroverfladen for det “nye-medlem”, hvor vi viser den sociale interaktion mellem det “nye-medlem” og ildsjælen for igen at vise tanken bag en ildsjæls måde at hjælpe det nye medlem ved at skrive til dem og arrangere ting i kalenderen. I vertikale nedslag bliver funktionerne vist i deres endelige form. De er, som de skal være i det færdige produkt (Floyd, 1984, s.4). I vores vertikale nedslag er fokus på den sociale interaktion mellem bruger og ildsjæl. Vi vil dog gerne pointere at vores vertikale funktioner ikke fungere som de ville gøre i et færdigt produkt, da der er mange små ting i “vælg makker/ildsjæl”- og “brugeroverfalde”-siden som ikke kan interageres med. Dette skyldes at vi i nogle tilfælde har valgt ikke at give en knap nogen funktion for at illustrere at der er en funktion, men som ikke er blevet lavet. Et eksempel på det er i “vælg ildsjæl/makker” siden, hvor pilen viser at der er flere ildsjæle, men man har ikke mulighed for at trykke på den, da vi ikke synes det ville give mere til prototypen at man havde mulighed for faktisk at se flere, og at brugerne vil kunne forstå at der er mere end blot disse tre, ved at vise en pil og at det er side 1 ud af 4 de ser. Denne måde at prototype på, synes vi stemmer overens med det Lim et al. (2008), nævner i forhold til det økonomiske princip “the best prototype is one that, in the simplest and most efficient way, makes the possibilities and limitations of a design idea visible and measurable.” (Lim et al., 2008, s.3), hvor vi ikke synes at arbejde mere på disse funktioner ville vise mere af vores prototype i forhold til den tid det ville tage at implementere funktionen.

Evaluering af prototype

Vores prototype er selvfølgelig bygget op omkring kommentarer og viden fra vores brugere, men med en “færdig” Figma prototype ville vi nu vise og afprøve ForeningsMatch med dem, så de kunne give os feedback, som vi efterfølgende kunne tilpasse os. Selvom vores prototype er baseret på indsigter fra vores brugere, kan det være, de havde forestillet sig et andet produkt end det vi havde

Billede 13 – udklip af feedback

Vi har skrevet noget af feedbacken i billede 13, hvor det kan ses at vores to brugere gav os en masse feedback, men de var dog en smule delt nogle steder i forhold til hvad de synes omkring funktionerne i ForeningsMatch.

Evalueringen foregik med en bruger ad gangen. Vi gennemgik vores prototype og de gav feedback undervejs. De fik også selv mulighed for at klikke rundt i vores prototype og dermed prøve den, så de lettere ville opdage, hvis nogle af funktionerne ikke gav mening for dem. Vi optog evalueringen i lyd og video og gennemgik den efterfølgende for at notere ris og ros, så vi kunne få deres forslag implementeret i vores løsning. Vi tog ikke alle forslag med, da vi i sidste ende må stole på os selv som designere og dermed vælge og vrage blandt de forslag de kom med. For eksempel har vi valgt at gå både med makker og ildsjæl (som vi også har beskrevet tidligere), selvom en af vores brugere sagde at ildsjæle var “no go” og mente fokus mere skulle være på makkere. Dog havde nogle af vores andre brugerne været meget positivt indstillet overfor netop ildsjælene, så vi valgte at beholde disse. Dette er et godt eksempel på hvorfor Schön (1987, s.3) mener at problemerne kan betegnes som messy indeterminate situations, da der ikke er en “rigtig” eller “sand” løsning, i og med ikke alle brugere ser ens på situationen. 

Billede 14 – Evaluering med ikke-foreningsmedlem

I vores evaluering kan vi også snakke delvist om at brugerne har fået en oplevelse af at bruge programmet og ikke blot en demonstration af funktioner, fordi de har haft mulighed for at interagere med programmet og se den interaktion, som foregår på siden. At skabe denne oplevelse når brugerne evaluerer prototyper er noget der ifølge Buchenau & Suri (2000) er vigtigt, fordi brugerne kan opleve og afprøve en prototype, frem for at få den demonstreret, hvilket gør brugere mere subjektive i deres evaluering af protypen (Buchenau & Suri, 2000, s.424). Det er netop disse subjektive tanker vi ønsker at indfange i vores evaluering med brugerne, fordi vi kan forstå hvordan produktet anvendes og opleves af brugerne i deres brugskontekst (Buchenau & Suri, 2000, s.424-425). I forhold til om vi er lykkedes med at skabe denne oplevelse, så har vi på den ene side ladet brugerne sidde med prototypen og afprøve den, hvor de har kunnet fortælle os hvad de synes i brugssituationen, fordi vi har siddet lige ved siden af og kunne snakke med dem omkring deres oplevelse af programmet. Men på den anden side så har prototypen været meget begrænset i forhold til hvilke funktioner der fungerede, så deres gennemgang af prototypen blev også delvis kontrolleret af at de ikke havde mulighed for at trykke på så mange ting, hvilket vi tænker må have taget dem “ud af oplevelsen” og få prototypen til at fremstår mere som en demonstration, hvilket også blev forstærket af at vi sad ved siden af brugeren mens de afprøvede den. 

Further use: Videreudvikling af prototype

Billede 15 – Ny side “introduktion”

Overordnet var de rigtig positive overfor Foreningsmatch, men de efterspurgte en mere dybdegående introduktion. For at afhjælpe problemer tilføjede vi en side når brugeren klikker på reklamebanneret på foreningens hjemmeside. Her præsenteres du for en skriftlig forklaring af hvad ForeningsMatch kan hjælpe dig med og hvordan du skal gøre. Resultatet ses til højre: 

Ydermere efterspurgte vores brugere en meget større og mere tydelig  “vælg person”-knap, hvilket vi kun kunne give dem ret i. I tillæg til denne ville de også have et tydeligere procenttal og større foreningslogo. Herunder ses et før og efter billede (16) af den omtalte funktion, hvor øverst er før og efter er nederst:

Billede 16 – Forbedring af vælg ildsjæl/makker funktion

Ifølge Donald Norman, er “visibility” et simpelt, men meget nyttigt princip om at jo mere synligt et element er, desto nemmere er det for brugeren at se og forstå funktionen. Det modsatte er tilfældet hvis elementerne er gemt, da brugeren nemt vil overse funktionen. I ovenstående eksempel har vi forstørret foreningernes logo, fremhævet og forstørret de procenttal som viser hvor enig vores bruger er med ildsjælen, samt forbedret “vælg”-funktionen så den fordre (afforder) en handling og muligheden for interaktion. På den måde stemmer vores prototype mere overens med Normans principper og vil sandsynligvis forbedre brugsoplevelsen (Norman, 2013).

Også på siden med parametre har vi efter evalueringen har vi tilføjet nogle efterspurgte parametre og med små ikoner gjort det muligt at få uddybende information om hver parameter. I billede 17 ses før billede øverest, efter billede nederest:

Billede 17 – Forbedring af parametersiden

Gennemgående har vi forsøgt at arbejde hen imod Donald Normans begreb om “consistency”, ved at holde vores design i samme farver og bruge knapper kendt fra andre interfaces – på nettet såvel som apps. Ved at være konsistent med vores brug af elementer, kan vi opnå en mere simpel og intuitiv brugeroplevelse (Norman, 2013).
En anden ting vi også har lagt ind nederst i parametre siden er at brugerne har mulighed for at trykke på om de søger en Ildsjæl, makker eller begge, som et parametre i søgningen. Som vi nævnte tidligere i evalueringen så havde vi en bruger der klart mente at ildsjæle ikke vil fungere fordi det ikke var nok til at få folk i gang og at der ikke fandtes nok ildsjæle til at hjælpe de nye-medlemmer, og derfor var det for ham match funktionen med makkere det vigtigste i vores produkt, som kan læses i følgende citater fra evalueringen med ikke-forenings brugeren; “det der med ildsjæle det er ikke vejen indtil klubben. (…) jeg tror at bestyrelsen vil (hjælpe som ildsjæle), men resten de vil have jo færre jo bedre” (05:30, evaluering med ikke foreningsmedlem), “man skal jo ikke matche med en ildsjæl” (15:00, evaluering med ikke foreningsmedlem), “når to folk har matchet, så har i gjort det i skulle” (18:50, evaluering med ikke foreningsmedlem). Men på trods af den her feedback, så har vi taget et valg som designeren, fortsatte med at have begge funktioner. Vi mener klart at funktionen med at matche folk med makkere er vigtigt, men vi synes ikke den kan erstatte og udfylder det samme behov som at matche med en ildsjæl, som netop er den her introducerende figur for det nye-medlem, og som løser det store problem med at folk falder hurtigt fra fordi de ikke får en god start, som gør at de ønsker at fortsætte. Derfor synes vi ikke det skader at man har muligheden for at søge efter en makker, ildsjæl eller begge i det samme program, selvom der er delte meningen omkring, hvordan man får nye medlemmer til at starte, da vi kan hjælpe så mange som muligt ved at appellere til begge målgrupper og de forskellige behov de måtte have for at starte i en forening i.