Hacking the Design Jam
Hack Days are a great opportunity to get away from the office and more specifically for Developers to scratch the itch of a nagging problem, or novel concept they’ve been playing with but just haven’t had time to execute.
The problem with this is if you’re not a Developer you need to come up with something else. Typically this would mean either dusting off the coding skills and all the setup on your machine that goes with this or being a Designer loosely attached to the team responsible for doing the odd bit of design and getting the end of day presentation together.
This year for the Seven West Media Hack Day the non-developers on the team wanted to avoid this so we had a go at hacking the Design Jam process together.
What is a Design Jam?
A Design Jam is basically a Google Venture’s Design Sprint, compressed down into one day. You have all the same components, a clear problem you want to solve, some research, ideation, design and testing.
When I’ve done these previously at Isobar Australia we normally get the customers in the room. This means less upfront research, and more confidence in your solutions (as you’re co-designing them with customers), and importantly no need to test during the day. The agenda generally goes something like this at takes 4–5 hours;
- Walk in each other’s shoes — You do some storyboarding to establish the current customer experience
- Rapid Ideation — The Customers and Designers come up with as many possible solutions as possible
- Prioritise & Vote — Choose the best solution as voted on by the team
- Prototype — Create your new solution in whatever medium you see fit (Lego, Pen and Paper, Cardboard whatever)
- Present — Each group in the Design Jam share’s their findings.
Given the time and financial constraints (as in, we have no budget for customer incentives) of a Hackday we “hacked” an alternate format. This was a bit more work but it was interesting to see what we could do with no customers in the room.
Our Hack Day Design Jam
Before I get into the details there is one important thing we need before starting a Design Jam: A simple contained problem which we can make an attempt at solving in a day.
This is done using a How Might We statement which guides us throughout the day. It could be anything, for us we simply listed out a bunch of bullet points on things which we wished we could fix.
- Make “long form” content discoverable
- Can we find out how articles are measured; how users engage with articles; what do they do next: browse more articles or go to the homepage.
- Can we do eyetracking of someone going through the west site?
- What does the future platform of a digital multi-media business?
- Taking a step back and seeing if there’s a better way than just “add it to the homepage”. How can we get people to consume all this content in a user friendly way without overwhelming them and our team. Maybe the traditional website isn’t cut our for something like this anymore?
We then boiled this down into a statement:
How might we provide a user centered home page experience which is engaging, simple to use & surfaces high value content?
So with our problem set here’s how we went about running our Design Jam on a Hack Day.
Setting up the Team
There’s 3 roles you need to fill for this kind of Design Jam
We just had one team of 5 people. But you could scale it to 4–6 people and it not get too chaotic. If you have more people it’s best to split into multiple teams of 4–6
Facilitator — Time keeper, and ensures we stay on track and don’t get lost down rabbit holes. Only one of these per Design Jam.
Decider — The person who unblocks us when we can’t figure out the best way to move forward. It’s not about making the right decision, just a decision so we can move forward. You need one of these per team.
Designers — This is everyone, including the Deciders. If you’ve got one team the Facilitator can and should design too. Designers do the research and the work to make it happen.
Preparation
Day Before — Interview guide & Recruitment — Mapping out the tasks we want people to complete on the website based on the problem statement.
For us this included a simple 5-second test in Figma to gather first impressions and confirm some hunches, followed by 4 tasks we asked the users to execute on the website based on Navigation, Readability, Value and Personalisation.
We then got in touch with our relatives (mostly over 60s as this was our focus demographic) and booked 5 of them in to do a test the night before the Design Jam, and on the day of the Design Jam to test our solution.
Night Before — Usability Test — We interviewed our relatives on the current The West Homepage. Thanks to our parents, grand-parents and spouses for all your help! Each person running a test wrote down notes for us to go over the night before
The Hack Day
9am Findings Synthesis — Each researcher read back their findings and quotes from the test the night before, while the team noted down Gain and Pain points captured for each of the users on post its. These were then grouped into themes for us to tackle during the day.
10am Ideation — We used the simple Newsflash template to come up with as many potential solutions as possible. I love this template as it’s simple (just write a headline, simple illustraion and a couple of lines explainnig your idea), doesn’t require any fance templates (just a blank A4) and cheap. You can quickly scrawl out an idea and move onto the next one.
We then did an old school remix with all the ideas in the middle of the table and amended or added to each other’s ideas
1045am Prioritisation and Voting- We prioritised all of our ideas on a matrix in terms of Value (in relation to our problem statement) vs Cost of Delay (what’s the opportunity cost of not doing this). The team then voted on their 5 favourite ideas
11am Deciding on a Direction — Based on the votes and priorities we pulled out the ideas which all represented a pretty strong theme in our thinking and had the most votes. These also turned out to be the most high value (as in, top right of our prioritisation matrix), ideas to work on
1130am Wireframing — We individually developed wireframe concepts based on our chosen direction. Once our Wireframes were completed we presented them back to the team. Everyone took a marker and put a dot on the elements they liked the most from each other’s designs.
12pm Cutup — We then took our favourite ideas and concepts based on how we voted, cut them up scissors to, create our Frankenstein’s Monster final Design to prototype.
1230pm Lunch — This is important
1pm Prototyping & User Interview Prep — Using Figma the team took the chosen solution and started moving pixels in the Figma. This was a massive plus as the non-designers in the team could easily contribute without having to know how to use the tool. Things like adding in content or just basic alignment of elements.
At the same time a team member modified the user test script from the night before, to ensure it aligned to our new design direction, and fixed any short fallings the test from the night before had.
This is the prototype we came up with, it has lots of problems but it’s just enough of a concept for us to see if we’d made any improvements
330pm User Testing — The team split up and called their users to test the new design and collect feedback.
4pm Findings — Finally we put together a deck to show off our findings and quotes from the users. Based on the test we made some good progress. Our CSAT (Customer Satisfaction) scores for Navigation went from 7.4 to 9.5 and Readability went from 7.8 to 10.
What we Learned
Design Jams are chaotic, messy and should feel a little uncomfortable. We altered our direction and agenda a few times throughout the day to get the best outcome.
Getting the ‘Goldilocks Zone’ of preparation was hard but I think we got pretty close. There was temptation to prepare for everything, and try and come up with a direction before the day. It’s important to avoid this so you start the idea with an open mind willing to try anything out.
If you feel like you haven’t prepared enough, you’ve probably prepared enough for a Design Jam.
It’d be easier with customers in the room. It was fun doing the usability testing, and I’d actually try it again, but the traditional customer in the room Design Jam seems to run faster, and there’s less bootstrapping required around running 2 usability tests in the space of 24 hours.
Having a tool like Figma with some design elements ready to roll from something like a Design system helps out a lot when it comes to prototyping. But it’s not required.
If you don’t have customers in the room, doing the test the night before is essential. It means you can keep less accurate notes doing the usability test and during the day you’ll easily be able to recall the conversations you had from the night before.
Final Thoughts
Have fun. This is the most important thing!
Would I do this again on a Hack Day? Hell yeah!
