Vergaderen

Vergaderen… het is standaard in een organisatie, en in de business wereld. Iedereen vergadert toch? En als je iemand iets wilt vragen, of je hebt iets nodig van een collega, dan plan je toch een vergadering?

meetingitis

An excessive propensity to hold unnecessary meetings.

Hoe vergroot je dan de effectiviteit en productiviteit van vergaderingen? Heb je telkens nood aan een vergadering? Hier bewuster over zijn, kan je al een grote stap vooruit helpen en de situatie verbeteren!

De effectiviteit en productiviteit van een vergadering verhoog je door

  • een goede voorbereiding
  • de vergadering faciliteren
  • een goede follow-up

Voorbereiding van de vergadering

4 P’s van een vergadering

Vooraleer een zaal te boeken en mensen uit te nodigen, denk na of de vergadering nodig is!

Een alternatief is op mensen toe stappen voor een conversatie wanneer die in de buurt zijn en die je kan/mag storen (eerst vragen natuurlijk)! Denk voor het plannen van een vergadering aan de 4 P’s (4 P’s als geheugensteuntje) – dit is voor een vergadering die je wilt organiseren.

  • Persons/Participants: wie zal er de vergadering organiseren/faciliteren/leiden en wie zijn de personen die actief kunnen bijdragen en die je vervolgens zal uitnodigen?
  • Purpose: wat is het doel van de vergadering? Zijn de beweegredenen of motivatie duidelijk die het bijeenbrengen van personen in een vergadering verantwoorden?
  • Process: welke facilitatie processen zal je toepassen voor de vergadering, in functie van het doel? Er bestaan verschillende facilitatie technieken, die je kan gebruiken in eender welke vergadering. Het is interessant om meer interactie en dynamiek te brengen in een vergadering, buiten de standaard presentaties (1 persoon bepaalt het verloop) of brainstorming (iedereen bepaalt het verloop).
  • Product: Wat is het “product”, de output van de vergadering? Wat willen we bereiken? Dit hangt uiteraard vast met het doel van de vergadering en bepaalt ook wat de output (“deliverable”) zal zijn.

    Agenda van een vergadering

    De agenda van een vergadering opmaken is deel van de voorbereiding. Maak een agenda die duidelijk en uitnodigend is!

    Maak duidelijk:

    • Wie wat zal faciliteren
    • Wie notities zal nemen tijdens de vergadering (hoeft niet steeds de organisator te zijn!)
    • Wie een follow-up zal doen (kan per agendapunt)

    Voor elk agendapunt kan je beschrijven:

    • De motivatie (noodzaak) om te bespreken
    • De verwachtte uitkomst
    • Wie verantwoordelijk is
    • Eventuele voorbereiding
    • Tijd verwacht te spenderen
    • Het proces

    Bij “proces” is het nuttig om een onderscheid te maken tussen “bespreking” en “beslissing“. Wanneer het niet duidelijk is in een vergadering wat de verwachtte output is (en daarmee bijhorend proces om daar te raken), is dit vaak een oorzaak van frustratie:

    • Deelnemers die denken dat er een beslissing nodig is, raken geërgerd omdat de andere deelnemers enkel verwachten te “bespreken”.
    • Deelnemers die denken dat het enkel een bespreking betreft, raken geërgerd omdat de andere deelnemers op een beslissing aansturen.

    Tip: indien je merkt dat de deelnemers niet op voorhand de agenda bekijken (m.a.w. blindelings de vergaderuitnodiging accepteren) kan je werken met een agenda die uitnodigt d.m.v. het stellen van vragen in de agenda. De vragen zijn een trigger om na denken over de verwachting van de vergadering en eventuele voorbereiding.

    Een vergadering faciliteren

    De facilitator is de “gardener” en “guard” van de vergadering; een facilitator hoef niet noodzakelijk inhoudelijk bezig te zijn. Een facilitator zorgt ervoor dat:

    • elke persoon gelijkwaardig kan deelnemen
    • zorgt voor ruimte en tijd voor elke agendapunt en houdt de timing per agendapunt in het oog
    • faciliteert het bijhorend proces per agendapunt (is het een bespreking/verduidelijking? hebben we een beslissing nodig? wat is het actiepunt? wie doet wat wanneer?)
    • faciliteert een evaluatie van de vergadering op het einde (en zorgt ervoor dat dit kan gebeuren, door hier tijd voor te voorzien, of paar minuten voor officiële einde van het vergadertijdsslot een evaluatie te faciliteren)

    Facilitatie technieken

    Ronde

    In een vergadering, ga rond in een cirkel zodat elke deelnemer de kans krijgt op zijn/haar beurt te spreken.
    Het faciliteren in een cirkel zorgt ervoor dat elke deelnemers als gelijkwaardig beschouwd wordt, en ondersteunt effectieve dialoog.

    Als facilitator, kan je kiezen om elke ronde met een andere persoon te beginnen, om variatie te brengen in wie er als eerste en wie er als laatste spreekt.

    Check in

    In een check-in rondje krijgt iedereen de kans om kort te benoemen wat er leeft, om zo vollediger aanwezig te kunnen zijn. Dit helpt ook om gedachten te ordenen en met meer focus aan een vergadering te beginnen!

    Check-in betekent dat je (heel) kort met de groep deelt wat er momenteel gebeurt met jezelf, hoe je aanwezig bent, daarbij jouw gedachten, gevoelens, afleidingen en noden kenbaar maakt.

    Als facilitator, verplicht nooit iemand! Een deelnemer kan een check-in overslaan. Dit kan bij start van de vergadering gebeuren, of bij een 1 on 1 voorafgaandelijk.

    Evaluatie

    Zorg voor een korte evaluatie op het einde van elke vergadering. Het doel is om feedback te verzamelen hoe de vergadering verlopen is en punten voor verbetering te delen.

    Korte evaluatie

    • fist-of-five”, elke deelnemer geeft gelijktijdig aan wat je vond van de vergadering (van 1: heel slecht, tot 1: heel goed) meer/minder
    • starten/stoppen/houden
    • positief/kritisch/suggestie voor verbeteringen

    Langere evaluatie (voor een workshop, sessie, …)

    Retrospectief formats om te evalueren:

    • Effectiviteit en format
    • Facilitatie en voorbereiding
    • Emotionele toon
    • Appreciaties en prestaties (Ik vond goed…)
    • Wilde ideeën en radicale suggesties (Wat indien…)

    Facilitatie technieken

    Bron voor facilitatie technieken (kleine en grote groepen)

    Facilitatie technieken maken vergaderingen interactief en dynamisch, voorbeelden van technieken:

    Kanban

    Voor recurrente vergadering is een backlog en een kanban aangewezen, enerzijds om de lijst van items continue te prioriteren (backlog) en

    anderzijds om een visueel overzicht te behouden (kanban).

    Governance backlog

    Gebruik naast de product backlog (werk te doen voor ontwikkeling van het product) ook een aparte backlog voor beslissingen (“governance”). Governance is het voortdurend beslissen over wat er nodig is om doelen te bereiken en binnen welke grenzen dat werk hoort plaats te vinden. Te bespreken, te beslissen items kan je op een governance backlog plaatsen.

    Op organisatie niveau is het ook handig om organisatie brede items zichtbaar te houden op een (goverance) backlog.

    Getting out of the deliverables business

    Once upon a time, there was a marketing guy, with great ideas for a new software application.

    He hired a business analyst, who described all those ideas in formal fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created detailed the User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to a functional specification, and trying to figure out how to connect it to existing infrastructure and systems.

    Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect visual designs for each and every screen of the application. Given the functional specification, a technical analyst created a technical specification and application design trying to capture all the given information, in a deliverable that would make sense as input for development. Sometime later, a copywriter was given the assignment to write on-screen text labels and copy, based on the wireframes. And even some times later, a tester was given the assignment to understand the requirements and write test scenarios.

    Development was about to get started!

    Sometime later, during development, some concerns rose about the User Interface of the application and a usability engineer reviewed the User Interface specification to give some advices and remarks.

    So, what do we observe?

    • The work goes sequential
    • Individuals doing their own thing, producing output: deliverables, documents!
    • Time passes by
    • Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation

    Let’s retrospect.

    Silo teams

    The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?

    Focus on outputs, not outcome. People are appreciated for their output: mainly documents and the quality of those documents.

    Those documents are written by an individual, or a group of individuals of the same expertise – documents are passed on (with or without explanation). Output of one phase, is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each individual needs to re-interpreter the work of the previous. No real sense of ownership.

    It’s a very time-consuming process. From inception to actual start of development, it can take months – depending upon the size of the project.

    Assumptions, lots of assumptions! Hypotheses based on those assumptions. A requirement spoken by the guy from marketing – as great as it might be – remains an assumption until proven by the market: feedback from real end-users: the customer.

    There is little to no opportunity to react and correct the design of the new software application, when new insights or market conditions come up meanwhile developing.

    Probably the whole process is overseen and controlled by a commanding officer.

    Where’s our marketing person? Out of sight

    A chain is only as strong as it weakest link.

    Teams used to a sequential process have become accustomed to handoffs between specialists. Each team passes off their work to the next team. Each of these handoffs includes overhead in the form of meetings, documents to review and approve, waiting time, etc. Anything which does not directly contribute to the goal of the project: creating software – is waste.

    Let’s reconsider.

    Once upon a time, there was a marketing guy, with a great idea for a new software application.

    A team was gathered with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team together made this set of skills, not an individual for each required expertise. Together with the marketing guy, the team formulated the business goal and desired business outcome of the new application.

    The team focused on the outcomes that would address the main customer need of our application. In a lightweight manner, the idea was conceptualized: the team formulated some hypotheses: valuable features that they considered as a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next the team draw some UI sketches on paper. The team set out a test by linking together the UI sketches to an “interactive” prototype for internal validation. Taking into account the received feedback, the team refined that small set of features to the level of user story with the main acceptance criteria.

    The team decided to prototype directly in HTML/CSS as this was the preference by the web developers. The team organized a user test with some of the key customers and external (non-customer) people. From these tests and the earlier defined metrics, they concluded and prioritized a number of improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed upon decisions), the prototype was improved and a next set of functionality was discussed.

    Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with real back-end data.

    Over the course of time, the team improved the product with feedback of customers, they included new insights, they dropped a few – previously considered “must-have” – features, and they integrated a new online service that appeared to be a good fit to the solution.

    So, what do we observe?

    The focus is on creating working software, that’s what we care for!

    Documents do no solve user’s problems, working software does.

    The focus are the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs and in that problem space possible solutions (hypothesises) to address those user needs are presented and challenged.

    Feature development is prioritized. There’s no all-inclusive upfront analysis, there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges or rather there’s a sufficient design up front.

    We eat the elephant in small chunks, but we prioritize the chunks.

    The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.

    Instead of an open-loop system, the project is organized as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.

    Lean UX

    What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are documented and are self-explanatory in terms of logic.

    Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery in an iterative and incremental way.

    Yes, there are exciting times ahead!

    More info on Lean UX? Read the book by Jeff Gothelf.

    the Sketchnote Handbook by Mike Rohde

    Sketchnoting, het visualiseren van informatie – tips & tricks, referenties, workshop

    Sketchnoting is het visualiseren van informatie, het maken van aantekeningen, van een verhaal, terwijl men luistert naar een spreker, of terwijl men een tekst leest.

    Sketchnoting is een krachtige vorm van expressie, op een heel persoonlijke manier – en laat toe om informatie te verwerken – visueel in plaats van louter tekstueel.

    Sketchnoting is niet gelijk aan “tekenen”. De bedoeling is net dat sketchnoting voor iedereen toegankelijk en mogelijk is – zonder dat men een aanleg of opleiding voor tekenen nodig heeft.

    Sketchnoting is visualisatie van informatie, het maken van notities. Heel nuttig tijdens vergaderingen, sessies, maar ook fun om te zien of te doen tijdens een event zoals een conferentie.

    Visualisatie van informatie en vooruitgang is ook essentieel in teamwork, projecten (“informatie radiators” in agile).

    Als je je wat wilt inwerken in sketchnoting, hierbij een paar tips en referenties.

    Hieronder ook enkele foto’s van mijn try-out tijdens een sketchnoting workshop.

    Materiaal

    Zorg dat je een papier en pen bij de hand hebt. Voor een eerste probeersel volstaat dat, maar als je wat vooruit wilt gaan, kan je best een notaboekje en enkele specifieke pennen/stiften aanschaffen.

    Sketchnote try-out

    Sketchnote try-out

    Oefen (offline)

    Het is interessant om te sketchen tijdens het luisteren naar een audio/video opname (tip: kies een of andere boeiende TED talk, niet te lang). Probeer de essentie en de verhaallijn te sketchen en niet op te gaan in alle details.

    Sketchnote try-out

    Sketchnote try-out

    Bibliotheek

    Probeer verschillende ‘algemene’ objecten te sketchen zodat je iets van een persoonlijke ‘bibliotheek’ aanlegt van veel gebruikte objecten, iconen, etc. Bijvoorbeeld: standaard vormen, algemene objecten, iconen, pijlen (connectors), scheidingslijnen, letters (verschillende stijlen, verschillende groottes), tekstballonnen, emoties, actoren (mini-mensjes), …

    Geavanceerder: voeg schaduw toe aan objecten, meer detail, preciezer en logischer gebruik van kleuren, let op consistentie in schrijfstijl (in eenzelfde sketch).

    Oefen (live)

    Tijdens een presentatie, sessie, oefen je sketching.

    Voorbereiding: maak jezelf vertrouwd met het onderwerp, de titel, de spreker, de locatie, datum/tijd > dit kan je al op voorhand sketchen: het canvas.

    • Aandachtig luisteren
    • Behoud het overzicht
    • Focus op de essentie, focus op ‘quotes’ – maak gebruik van ‘rustpauzes’ of ‘connector’ passages in een voordracht om delen in je sketch te vervolledigen (bv. Wanneer de spreker een fait divers vertelt).

    Boek “The Sketchnote Handbook”

    De referentie m.b.t. sketchnoting (Mike Rohde).

    the Sketchnote Handbook by Mike Rohde

    the Sketchnote Handbook by Mike Rohde

    http://rohdesign.com/books/

    Sketchnoting!

    • Focus met je volledig brein (directe informatie verwerking: input van informatie > output in de vorm van een sketch) > stimuleert de concentratie
    • Creatie van een visuele map
    • Zen (voor sommige mensen, bij mij persoonlijk was er een zekere agitatie om het resultaat niet volgens mijn zin was… maar ook je kan je emoties kwijt!)
    • Dynamisch!
    • Leuk!

    Andere boeken:

    Sketchnote handboeken

    Sketchnote handboeken

    Enkele resources, online is er nog veel meer te vinden – en vooral deel zelf je sketches online!

    Smashing Magazine: How To Get Started With Sketchnotes

    UX mastery: Sketchnoting 101: How To Create Awesome Visual Notes

    A Showcase of Sketchnotes

    Mijn ervaring komt van een workshop sketchnoting met Mara Callaert (@MaraCallaert) visuality.be, de foto’s zijn genomen tijdens deze workshop (bij Namahn, 21/02/2015).

    Axure tips to create wireframes, prototypes, and user interface specifications

    Axure RP is a wireframing, prototyping, and specification software tool aimed at web and desktop applications.

    This article descrbies some tips to productively use Axure.

    Common Axure library (and use of masters)

    It’s interesting to provide an Axure file containing a repository of commonly used layouts, elements, flows, default dialogs. Make the Axure file available to the team via your document/filesharing tool. Authors of wireframes can use these elements to compose their wireframes / prototype.

    Axure master elements

    Axure master elements

    You can define the items in the Axure file as a master element. Choose the appropriate drop behaviour for each master:

    • Place Anywhere:
      The elements defined in the master are fixed, but a user can place the master anywhere on a page
    • Lock to Master Location:
      The elements defined in the master are fixed and the location of the master on each page is fixed
    • Break Away:
      The user can change the elements defined in the master and the user can place the master anywhere on a page
    Axure master drop behaviour

    Axure master drop behaviour

    The granularity of the content of the master will determine the drop behaviour:

    • You can define a master per UI element
    • You can define a master for a group (e.g. a page layout, heading, body, footer, etc.)

    Recommendations:

    • When defining a separate master for each individual UI element you can set the drop behaviour to “place anywhere
    • When defining a master for a group of UI elements, such as a page/screen layout, heading, footer, you can set the drop behaviour to “lock to master location” – as these elements typically have a pre-defined location (make sure the location is correct in the master with respect to the page).
    • Note when user should be able to change the content (e.g. the text label), you should set the drop behaviour to “break away” (otherwise users are not able to customize it). Of course, users must apply some discipline to not alter the composition and the positioning of the individual elements in the master.

    Axure Team projects (+ versioning control)

    In case you have a team collaborating and working simultaneously on same Axure file, it’s recommended to use a concurrent versioning control system. In case you don’t have this available you can choose for a versioning control of the Axure files on a file/document management system.

    Versioning of Axure files

    Versioning of your Axure files can be achieved using any common document management tool (e.g. SharePoint). In this way different versions of the file are kept – take care this concerns a version of the whole Axure file – meaning when you want to revert back to an earlier version of a specific element or page, you will need to manually collate old and new.

    Note regarding management of Axure files on SharePoint. We have noticed you need to manually check-out your RP file before you can open the file directly from SharePoint in Axure. Avoid keeping and working on a local copy! When done with the modifications manually check-in the file.

    Sharepoint check-out

    Sharepoint check-out

    Keeping track of changes in Axure files

    It’s always interesting to have an overview of the changes in the wireframes available in the Axure file itself. This overview can be part of the Axure Word export.

    There are 2 approaches:

    1. In the beginning of the Axure file add a page with a table detailing each update. Set the width of the table to more or less match the width of a default text document. Break the table at the row where you want the table to continue on the next page. Fill the table with useful info, e.g.:
    • Date of update
    • Description of changes; referring to the wireframes names/titles
    • Author of update
    • Review/approval of update
    Axure table change log

    Axure table change log

    Advantage: an overview of all changes – disadvantage: the reader needs to locate each updated wireframe in the document.

    1. At the level of each wireframe, add a page note to describe any changes done on the wireframe. You can create a custom page note field “Change log”, this will appear as a separate subsection for each wireframe in the Axure Word export.

    5 page note - add change log  5 page notes - change log

    — Axure page change log

    Advantage: the changes are described on the level of the wireframe – disadvantage: reader needs to scan the full document to find all updates

    You can combine both approaches; and use a common identifier to trace the changes; e.g. the date of change with an additional ID. In this way, the reader has an overview of all changes in the general table and a wireframe-specific trace of the change per wireframe. Of course, authors of wireframes will need to exercise some discipline to consistently describe the changes.

    Annotating wireframes

    The objective is to correctly, consistently and concisely make notes on the wireframes.

    We most commonly annotate all the on-screen elements and the user actions.

    Sometimes it’s also required to additionally annotate:

    • On-screen text labels (in a specific language)
    • Analytic tags

    Page note

    Write a short a note for each page: a short descriptive text explaining the essence, the user story, etc.

    Page style

    Set the default page style. A practice is to avoid any visual design elements in wireframes. Set the font to a neutral font and font style (not bold, not italic) and set the page color to black & white.

    Axure page style

    Axure page style

    Axure default page style

    Axure default page style

    Customize fields

    Axure customize fields

    Axure customize fields

    Define custom widget notes fields (and group these in a set if applicable) as required. Remove fields you will not use. (click on “Customize” in widget interactions and notes)

    Consistent shape names

    Axure shape names

    Axure shape names

    Define consistent shape names; agree upon some convention, e.g.

    • Button_
    • Title_
    • Subtitle_
    • Headline_
    • Copy_
    • Link_
    • Checkbox_
    • Radiobutton_
    • Module_

    Define user interactions

    Axure widget interactions

    Axure widget interactions

    When creating an interactive prototype, you are defining the interactions using the widget interactions given in Axure (OnClick, etc.)

    In case the output format of the pre-defined interactions is not sufficiently explanatory, write a user action description in the field “description” or in a custom-added field “user interaction

    Annotate elements once

    No duplication of the same annotations on multiple pages: annotate elements only once in a logical order. Elements defined in a master should be annotated in the master.

    Annotate different states

    When applicable define different states using dynamic panels; or simply describe the different states in the page.

    Renumber all footnotes on each page

    Axure renumber all footnotes

    Axure renumber all footnotes

    This option ensures a top-down incremental footnote numbering. Apply this option whenever necessary (e.g. before exporting). This option needs to be applied per page.

    Widget property: Auto fit width and height

    Axure widget properties and styles

    Axure widget properties and styles

    In the pane “Widget properties and Style”, enable the option “Auto Fit Width” and “Auto Fit Height”. Otherwise when not fitting the width and height to the element, you will get unnecessary floating footnote numbers – as illustrated below.

    Axure floating footnote number

    Axure floating footnote number

    In case of text label or paragraph spanning multiple lines, you obviously cannot set it to auto fitting the width.

    Axure text without autofitting width

    Axure text without autofitting width

    Screen-size responsive

    Axure (since v7.0) has the possibility to define the layout of the page/screen for different screen sizes. In case of responsive design (web or app); always use this feature!

    Axure adaptive views

    Axure adaptive views

    The advantages include consistency of annotations, forced to adhere to responsive principles, automatic export of different screen sizes.

    Define the adaptive views – apply the mobile (phone) first principle:

    • Take portrait phone as the base
    • Define additional views such as tablet landscape and tablet portrait – set these views to inherit from base or otherwise as fitting your needs
    Axure responsive landscape tablet

    Axure responsive landscape tablet

    Axure responsive portrait phone

    Axure responsive portrait phone

    Axure responsive portrait tablet

    Axure responsive portrait tablet

    Axure Word export

    • Pages: select page or “Generate all pages”
    • Adaptive views: select views or “Generate screenshot for all views
    • Widget tables: select fields to be part of the table. Add new tables if you want to list separate tables containing specific fields

      Axure widget tables

      Axure widget tables

    • Define your own Word template, just ensure [[INSERT AXURE SPEC]] is defined in the body of the Word template

      Axure new Word template

      Axure new Word template

    • Set to user built-in Word styles to have numbered chapter headings
    Axure word export

    Axure word export

     

    Thanks to Antoine Wagon @awagon6 to share some great Axure tips & tricks.