Finding the best way to reflect
For me personally, reflection is a stage embedded in my normal workflow, though I never specifically look at it and be aware that I am doing it. For many, reflection is natural in either positive or negative situations and valuable conclusions are drawn from them to get forward almost autonomously. However, the way in which we do it might very well not be known to you, because people reflect in different ways. A few bright minds did figure out there are specific methods in which we look at what we do and make decisions.
The general idea of reflecting, is to look at the facts (what have you done?) but also analyze it and ask questions such as ‘Why’ and ‘How’ you did it. Doing so for both mental stages of the project or decision (ideation, execution) allows to improve on things that could have gone better. The way in which we best ask these questions and analyze our work, differs. During a recent Reflective Practice class, we have taken a look at three of the most prominent methods.
Kolb’s Experiential Learning Cycle (Kolb, 1984)
This method primarily relies on interpreting possible solutions for what is analyzed in your work. Following Kolb’s Cycle, I analyzed one of my latest development projects.
Concrete Experience: The UX Wireframe (new product) was/is hard to navigate.
Underlying issue:
- The only navigation available issues through the starting page, which has all pages listed. There is a way to navigate using the arrows on the keyboard, but it is not clear to the user is exists.
Experience:
- The client presentation went okay, but was open for improvement for future calls.
Concept Interpretation:
- The navigation needs to be clearer, and more intuitive.
- Making the page navigation in the artboards actually function, like a real menu on a site.
- Adding a note on the start screen about keyboard navigation.
- Explaining both during the call with the client.
QOL (Quality of Life) Implementation:
- Above ideas will be rolled out across all future UX Wireframes.

Model of reflection (Boud et al 1985, Johns 1995)
Note: pronounced as ‘Bauwd’ (high)
This method primarily relies on returning and describing the experience in detail and noticing what happened exactly. Following Boud’s Model, I analyzed one of my latest team projects.
Concrete Experience: A work project (August Homes), together with Javasloth Studios.
Set tasks:
- I developed the website, she (Alla, from Javasloth) designed the brand identity.
Experience:
- It went very well, we were not obstructing each other, rather complementing each others work.
Area for improvement:
- We need to be aware of the territory though, since she already starts showing web mockups as part of the brand identities’ real-world representations of products. Those do not align with my design, which was made later in the process.
Future application:
- We are doing more projects together in the future, and are already working on a few.

Gibbs’ Reflective Cycle (Gibbs 1988)
This method primarily relies on dissecting each step of the process individually. Following Gibbs’ Model, I analyzed one of my latest commercial projects.
Description:
- During the go-live of a project, I got a call from the Project Manager who told me we forgot a crucial step (redirecting old links) to publish the site.
Feelings:
- Confused, as I was never asked to do this before for their other projects, nor is it mentioned in the checklist we use for preparing to publish.
- Stressed, to get it all ready in time for the client to check.
Evaluation:
- This was not okay, it should have been known earlier. Though, I am thankful that the project manager noticed this stopper before going live.
Analysis:
- The Project Manager should have checked this earlier and should have noticed that this is not part of the go-live checklist, well ahead of planning the go-live.
- I should have been more pro-active in knowing redirections are needed in order to publish the site without issues
Conclusion:
- The Project Manager and I will both look at how to prevent it in the future. In this case, I need to make more time during go-live to catch up with these issues as they appear to publish with success. Hiccups are expected, but I need to face them where needed.
Action Plan:
- Schedule more time during go-live, and be less distracted by other projects
- Be available for calls with the Project Managers whenever needed during this period
- Be proactive
- Check the go-live checklist for any other similar thing, as of yet not noted as task

So, which one to use?
There is no real answer to this question, other than what works best for you as an individual. One of the main stages of reflecting in any method is acknowledging discomfort and looking at yourself critically. This can be hard. In some situations or projects, a specific method might work out better over another method you love using. Reflection is an important skill we should all be mastering, in the way we see fit and get value out.
My personal preference is towards Kolb’s Experiential Learning Cycle. The other methods either miss the big picture or duplicate steps which can prove redundant for most projects. The structure and terminology of Kolb’s Cycle is clear and concise, and allows to get to the core of your case without too many steps nor too many detours.