12in12: Reports from the Field
This is it. 12 months, 12 side projects. The Side Project Project is complete. From a newsletter to stop motion animation, an origami dinosaur army, or a text adventure game starring an undead Pharaoh, it’s been a wild year. To cap it off, July’s side project went full circle to what I love about design in the first place: creating interactive stories.
The Project: Reports from the Field
You never truly escape coursework. Even though I was working full time for a year and barely stepped foot inside the building, I am still technically attending university so had to complete a presentation and report among other things. My placement report is designed to reflect on a year working at Puppet, the lessons learnt, and challenges overcome.
The design and medium of the report turned into an interesting one because some of the material is for unreleased work so I had to get creative to meet the requirements of both the tutors and the company. In the end, the solution was a password protected website (so alas, can’t share it here) which I turned into inspiration for the design as well. Incorporating the confidential nature into the art direction, the paper is styled as a ‘top secret’ field report complete with hover-to-reveal redacted text and scattered ‘surveillance shots’. Because university reports can do with a bit of fun.
The Checklist
- Wrote (and rewrote) my placement report.
- Developed the story in a new style and tone for a company blog post.
- Leveraged my Dev Bones development starter kit to get my report website up and running faster.
- Reflected on these crazy last 12 months where I’ve learned so much and seen how much there is still to learn.
The Undone
- I learned about .htaccess and how to password protect a website but, alas, part of that meant learning the workarounds and difficulty in customising a sign in screen rather then htaccess which uses the browser defaults. As such, my dreams of a ‘top secret’ log in screen had to die to make room for higher priority work.
This report, my placement presentation last month, the intern blog, and this very #12in12 challenge all revolved around reflecting on the lessons I’ve learned on placement. It’s made me appreciate how the same content can be presented in so many different ways (presentation, report, blog post) depending on your goals, art direction, and audience. Each can learn lessons from another.
The blog post, reflecting as an intern at Puppet, was written last and felt the most refined of all the versions, drawing upon much of what I learned from writing this series. However, while taking the lessons from the others it was tailored completely differently and contained barely a glimpse at the side projects as that was not the point. The biggest underlying lessons of the Side Project Project, seeing how learnings from diverse areas can be cross-fertilised and applied, was itself being applied in new contexts. And perhaps that is the greatest lesson of all from this challenge. Not to mention a fitting end to 12 months of crazy side projects.
Highlights of the Month
On the Side:
- I must admit I’m not completely satisfied with the design of my placement report but it hidden in that struggle was the surprising gratification of applying the product principles I’d learned over the year of work and side projects to prioritise, cut, and compromise to deliver the best I could on a tight deadline.
At Work:
- Amazing workshop with the whole team together for two sessions looking at the product as a customer and as a competitor. Nice to see everyone not only identifying similar issues but also converging on where to go in the future.
- Release!!!
Lessons Learnt:
The product is what customers experience
Learning on the job:
The code is not the product. JIRA is not the product. The design is not the product. We put value into the product and see its component parts but not necessarily the product whole. The customer gets value out and only sees the surface. This was the perspective shift that formed the foundation of the two day release workshop and was a great reminder and eye opener before digging into the product.
Applying on the side:
The idea for my report was to be a ‘top secret’ dossier style evoking redacted government documents and every spy or hacker movie. However while I knew this and planned many details (which ultimately I did not have time to get to) accordingly, the person viewing it does not. After iterating on the style and getting feedback I had to shift gears from my original approach to create a design that evoked the desired feeling with only the parts that were there. If more could be added great, but if not it needs to still work, not just point to bits that didn’t make it to implementation.
How you frame the problem is EVERYTHING
Learning on the job:
Solve for an error and you’ll design an error message. But maybe it shouldn’t be an error message at all? I did this and it wasn’t until another designer began looking at it that we realised this could actually be a much more helpful state. It reminded me to always question the fundamental assumptions, especially when you’ve fallen down the rabbit hole of this error design vs that error design, are picking up an old design, or are handed off work.
Likewise, don’t just understand what engineering is asking, understand why. What is the priority, does this actually matter to the user, is there another problem here, etc?
Applying on the side:
In the case of the placement report, it is technically very similar content as my 12in12 series in terms of being a reflection of the past year and lessons I’ve learnt. Yet in reality, the two have completely different focuses (placement vs side projects), styles (report vs casual blog), and audiences. Even though I had lots of content to work with, I first had to sit down and frame what I was trying to do with it to see where to go. Speaking of preexisting content…
Keep a record
Learning on the side:
In university we keep research blogs cataloguing work and discoveries for coursework. This introduction to recording work, especially publicly, inspired me to keep a weekly blog of my first internship with daily learnings to help other people like me starting out in their first industry opportunity. This blog chronicling my #12in12 challenge continues the tradition and was a huge source for my report content. Not only were some of the major lessons already recorded here, it helped keep my writing pencil (well, keyboard) sharp-ish.
Applying on the job:
Beyond these posts, I also keep a folder for super rough daily bullet points to record what I do at work and lessons learnt (from which main of these are drawn). You don’t have to share it but whatever you do, I highly recommend some form of note taking or recording. Visual, written, whatever works for you. But it’s a great resource for everything from daily standups, end of year reports, or trying to find that article you remember reading once a couple months ago.
Bits & Bobs
- People aren’t there to use your product, they are there to solve a problem and achieve something.
- The participant is the expert, not the researcher. Instead of making customer empathising with you (is this design easier to use?), empathise with the customer (what do you think of this design?)
- There’s a difference between individually being aware of problems and acknowledging those issues as a group
- The ‘anti-problem’ statement (coming up with the worst/opposite of the ‘happy path’ for the user) is a great brainstorming tool.
- Before jumping on solutions, questions, critiques, etc. understand the purpose.
- Establish context. What is the problem being solved? Why are we doing this? How did we get here?
- Comment resolutions as you go. Keep track of which tickets have not been resolved.
- Priorities are just as important in a side project. Know what has the most impact vs effort to achieve what you want.
Next Time
Believe it or not, that’s 12 months and 12 side projects complete. In fact, next month it’s back to university! But before that, a recap of the last year of madness. The challenge may be over, but the side projects never truly end.
