Dev Log 6: Learning Reflection - How will this prepare me for next semester?

Introduction

It's that time again. These dev logs have really helped me express and pin down my creative/design thinking processes that I've been using. A lot of what I've been learning and refining has come from my lesson material at Sheridan College. But I've also been using my own personal methodologies that have come from my experiences. Reflecting on what I learn is the name of the game for these dev logs. They're not tracking my progress in a project, but rather they are tracking what I've been learning from each project. When it comes down to designs and finding the right solution, it's often best to pull it back to as many layers as possible to establish the big picture and root cause of the problem. So, my big takeaway from this semester is to be able to rapidly learn and structure methods to overcome challenges. I consider this a skill that can be trained.

Oh gosh, what have I done?

Here's the part where I explain what it means to Rapidly Learn and Structure Methods. Through my past dev logs I've explored new tasks that I've had little to no prior experience with. Each of these tasks were completed through realizing and achieving a metric of success. It was then up to me and the material I had on hand to get to that metric of success. I constructed a system to format and produce a report to analyze a complex issue in Canada's healthcare system [1]. I assembled the components of that report into a game concept and proposal to pitch to my professor and peers [2]. I went into great detail analyzing what it took to create a beat map for a board game and came back with a methodology that would go on to capture exactly what we were looking for [3]. I used design pillars and user-centered design principles to mold contributions to our game's design to fit the needs of our intended audience [4]. Finally, I analyzed and constructed what it took to start and maintain a development cycle from pre-production onward through the use of scheduling and task breakdown methods [5].

All of these proved to be effective by helping me achieve the metric of success I was looking for. Putting in the extra work to step back to snag the big picture in each of these scenarios helped move the developmental process immensely. 

Defining RLSM

Let's visualize the steps of RLSM:

1. Understand what it takes to complete the task.
2. Understand what you already have or know to complete the task with.
3. Define your metric of success.
   1. This one is a little more complicated, but like the others it's very dependent on what your task is. In school, we often have rubrics to look at for this kind of thing. But going beyond a rubric to achieve a personally assigned level of success is ideal as well. You can create a pillar to structure your methodology around, like a theme, genre, or format for the solution. i.e. making the subject of your report appear scary or horrifying for the reader without telling them it's scary.
4. Fill in the blanks.
   1. You existing knowledge or resources might be lacking for your challenge. This is completely normal, and in fact, it should be expected. A big part to overcoming a challenge comes from learning something new about it, or your own process. Partaking in additional research, asking peers/mentors how they would handle it, or even finding similar challenges that have been overcome before is a great way of finding new elements to incorporate into your method, or even replace your methodology entirely.
5. Cut out the fluff.
1. At this stage, you should have accumulated a long list of steps to take on the challenge, but some of these steps might be vague, they might be redundant, or they might not adhere to one or all of your metrics of success. This is where we eliminate insecurities, vague steps, and unnecessary portions. Restating everything clearly and concisely refines the work you just put in to make this method, turning it into something that appears professional and effective.
2. Part of restating everything clearly and concisely comes from the way you're digesting your own method. It might make a lot of sense to you, because you just made it, but you need to understand how it's being stated to someone who just walked in with no knowledge of what you're trying to achieve. Restructuring it in this way will allow this method to continue to serve you after any amount of time passing between work periods. You'll thank yourself later. Turning it into a diagram or a short list of steps might be the most effective.
6. Put it to work!
   1. The best way of to test your new method is to run through the steps and see if it actually works. You'll be able to critically analyze each step and see what works and what doesn't. Perhaps your fluff cutting hasn't cut out enough, perhaps it cut out too much. Only this trial through process will proof it for your own needs. Then all that remains is to achieve those metrics of success you are aiming for. Go back to step 1 and try again. You have a brand new method to start with on step 2 and you can proceed as normal with new insight on what you need for your particular challenge or project.

Conclusion

It's important to analyze your knowledge and what you have access to before starting any task or project. Piecing these elements together to construct your own methodology is vital for particular projects to find what functions best for you and defines your goals beyond what is just stated for you to achieve. In a lot of cases, you have other restrictions to account for and this agile method of making methods, you can tackle just about any task effectively. This is what I've taken away from my work this semester, and I'm going to be using this whole process moving forward to help create new structures and methods for myself, and my future teams.

Dev Logs referenced:

1. Dev Log 1: Researching & Report Writing
2. Dev Log 2: Project Proposal
3. Dev Log 3: Beat Mapping
4. Dev Log 4: User Centered Design
5. Dev Log 5: Scheduling My Work