Image credit: Fabrizio Verrecchia
Wednesday 14 October.
In this evening’s webinar – about an hour and a half’s time – the theme for our first rapid ideation session will be announced. Now seems like a good time to share some thoughts.
Most of the designs in my portfolio are what I’d call single-view artefacts. High fidelity mock ups of landing pages, social media posts, and the like. I think this will be a good opportunity to consider an entire user journey. I want to focus on how my artefact would be interacted with.
My biggest challenge is likely going to be effectively following an ideation strategy. As I have mentioned in other posts, I am currently working to overcome a habit of fixating on my first good idea and becoming blind to other opportunities.
In an article on OpenPracticeLibrary, it is said that the goal of the Crazy 8s methodology is to “push beyond your first idea, frequently the least innovative, and to generate a wide variety of solutions to your challenge” (Becker, 2019). This stood out to me, on account of my tunnel vision vice. As an excerise, I’m going to default to rejecting my first idea, no matter how good I think it is.
And that’s going be scary for me – it’ll go against my gut reaction. I am a firm believer, however, in the baptism of fire.
Wednesday 14th October (later).
The theme for the challenge was announced. An image of a wooden boat with wings, and the phrase ‘basic arithmetik’:
Staying true to my pre-reveal plan, I’m going to reject my first idea in pursuit of innovation. My first idea drew on the ship being some kind of merchant or hauler. Looking at the card closely, it seems that the ship is stacked with colourful boxes. The phrase generated on the phone could allude to a simple bin-packing algorithm.
What if I prototyped a stock management/ERP tool for an aeroboat courier and imports service?
I like this idea but, as I promised to myself, I won’t be turning it into my final artefact.
It’s getting late again, so I won’t be ideating tonight. I do have enough time to strategise for tomorrow though. I’ve settled on three ideation methods, ranging in familiarity, comfort level, and expected value.
Method #1: Mind Mapping (Cleverism, 2019).
This first method is most definitely one that I am familiar with. I have been drawing mind maps for longer than I can remember. Throughout my school years, mind maps were always my go-to for lesson notes and revision.
My concern is that by being so familiar with mind mapping, the method might leave me too far within my comfort zone to produce anything nuanced. It won’t exactly leave me half a second from death. Sorry, Doctor NakaMats.
Method #2: Opposite Thinking (Board of Innovation).
I expect this method to be the most valuable. Hopefully, forcing myself to consider opposing perspectives will muscle me out of my tunnel vision.
Though I’ve never used opposite thinking specifically, I did work through similar flip-chart flows in focus groups during my teaching days. The outcomes were (usually) positive. I’m marking this one as middle-of-the-road familiarity and comfort.
Method #3: Bodystorming (This is Service Design Doing).
The grand finale. I’m going to try something totally alien. Way out of my comfort zone. No expectations.
Being the wildcard that this method is, I’m not even sure how I would approach bodystorming with the springboard material. I suppose I’ll come up with a way of pretending I’m on a flying boat and go from there.
Thursday 15th October.
I made it through two out of my three ideation methods this evening. In retrospect, I shouldn’t have considered this exercise as an opportunity to review three strategies. My mapping in method one undoubtedly influenced my thinking in method two. Inadvertantly, my mindmap became a valuable theme bank, ready for application in Opposite Thinking.
Friday 16th October.
I decided to sleep on my list of software ideas from ideation phase two. Today, over the space of a few hours, I worked the list down and decided on an idea to prototype.
I’ll be designing a safeguarding system for commercial boats, to streamline Coast Guard response. For the sake of focusing on the prototyping /experimentation aspect of this challenge, I will be designing the artefact for an alternate reality where radio systems don’t exist. Instead, I’m working with the assumption that the Coast Guard need a solution that uses 5G to locate vessels in distress.
Saturday 17th October (early hours).
Bodystorming may have it’s uses in some scenarios. In this instance, it was difficult to discern any clear-cut methodology.
I think bodystorming would be best suited to instances where existing, flawed process are in place, to be examined through roleplay. I can certainly see it being a useful workshop tool, were I working with a client to better understand their industry and unpick their software requirements. As the idea I was exploring was still very much abstract (more stream of thought than software idea), there was nothing to ‘act out’.
What I did do was have a phone call with a close friend, also with experience in bespoke software development. We each took on the role of Coast Guard (CG) and Skipper in distress and discussed what we would need from the app for it to be viable. After sharing some thoughts, we swapped roles for varied perspectives.
Were this a real-life project, I imagine it would span several codebases. Dual native apps on the skipper side, and a multi-tenanted web-app to cater for every coast guard station using the system. Already I can see opportunities for integrations with Google Maps and the distance API, Twilio to automate check-in calls in 5G deadzones, maybe even What3Words to better direct rescue teams. I need to be careful with the scope of this idea if I intend to deliver something by week 5.
For the sake of the design Jam, I’m going to solely focus on the skipper side. Starting with a post-it wireframe, I’d like to paper prototype how this app would notify skippers when they move out of a 5G coverage zone and map their location against the CGs search zone.
The search zone will account for the boats’ average speed, weather conditions and their predicted distance from journey checkpoints.
The interface will also use a traffic-light system, to indicate how quickly or easily CG would reach the skipper, with rolling notifications for when the boat moves to a different coloured zone. I’ll also include a means of requesting CG attendance (i.e. sending out a distress signal).
Tomorrow, I’ll use an imagining of William S. Burroughs’ cut-up method (BBC, 2015) on a few screenshots of safeguarding and GPS-based apps. For now, I need to get some sleep.
Saturday 17th October (afternoon).
I took a stack of printed screenshots to the cutting board today. I was worried that if I jumped straight into wireframing I would end up trying to recreate the wheel. Using the cut-up method helped me form the general structure of my prototype without straying too far from UX conventions. The screenshots that I used were from mobile apps with GPS functionality, with the exception of one image of a 5G coverage map of the UK.
Dusting off and setting up my printer was an ordeal, but I feel the exercise fast-tracked the wireframing process and saved some time in the long-run.
Saturday 17th October (later).
I made a rough wireflow this evening (Haven’t graduated from the whiteboard and post-its just yet). My bodystorming session came in handy here. I was able to walk through the user journey I had formed, and use my bodystorm notes as a checklist of user requirements.
Revisiting my cut-up session, I should have taken more time to consider whether the components I had pieced together were appropriate for the context of the app. I had used a menu design from the ‘Windy’ app. The menu icons where stacked vertically from the bottom right corner of the screen. Being left-handed, the layout was convenient for me to use, as my thumb rested directly over it.
For righties, the menu is much more difficult to reach. With the added context of being on a potentially sinking boat, having hard-to-reach, fiddly buttons seems like a bad idea. In my digitised wireframe, I’ll opt for a more traditional hamburger menu in the top left corner.
List of figures
fig. 1. The theme material for Rapid Ideation session 1 (RI1). Revealed in Week 4’s Webinar.
fig. 2. Mind map exploring the RI1 theme material
fig. 3. opposite thinking session on the RI1 theme material
fig. 4. Notes taken during the bodystorm session on the RI1 theme material.
References
BBC News. 2015. ‘What is the cut-up method?’. Available at: https://www.bbc.co.uk/news/magazine-33254672 [accessed 22/12/2020].
BECKER, J. 2019. ‘Crazy 8s A fast sketching exercise to generate solution ideas’. Open Practice Library. Available at: https://openpracticelibrary.com/practice/crazy-8s [accessed 22/12/2020].
Board of Innovation. ‘Opposite Thinking’. Available at: https://www.boardofinnovation.com/tools/opposite-thinking [accessed 22/12/2020].
Google. 2020. ‘Geo-location APIs | Google Maps Platform | Google Cloud’ Available at: https://cloud.google.com/maps-platform [accessed 22/12/2020].
LUENENDONK, M. 2019. ‘Techniques for Idea Generation: Mind Maps’. Cleverism. Available at: https://www.cleverism.com/techniques-idea-generation-mind-maps [accessed 22/12/2020].
This is Service Design Doing. ‘#TiSDD Method: Bodystorming’ Available at: https://www.thisisservicedesigndoing.com/methods/bodystorming [accessed 22/12/2020].
Twilio. 2020. ‘Twilio – Communication APIs for SMS, Voice, Video and Authentication’. Available at: https://www.twilio.com [accessed 22/12/2020].
What3Words. 2020 ‘Get started with the what3words API | What3Words’. Available at: https://developer.what3words.com/public-api [accessed 22/12/2020].
Windy. 2020. ‘Windy: Map Forecast API – Home’. Available at: https://api.windy.com/map-forecast [accessed 22/12/2020].
Skoobin Design 