Optimal Roadshow — Michelle Park

Last Thursday I went to Optimal Workshop's first roadshow. First for me; first for them.

It was held at a new venue on The Viaduct called GridAkl. A fit for purpose venue that worked very well for the people who attended - I was about to estimate the number of people who attended but I'm terrible at that sort of thing. I'm still going to attempt it: 200 people? 250?

Who knows. The thing that matters is that plenty of people attended Optimal's first roadshow workshop.

Optimal put on a good show: had a bar, they had build-your-own-tacos, they had Lego as a prize for the those who played the icebreaker game, they had nice notebooks, a separate area for the talks, good talks, a cameraman to record the talks, microphones. It was very well run event. Money well spent by them and by me.

Customer centred, digital transformation: What does that even mean when you apply it to a website?

Emma Pittar, Nathan McIntosh & Marla Loubser

First talk of the evening was by Emma Pittar and friends talking about the project she worked on while at her previous gig Design Arts Network. The project was to develop capacity within Auckland Council to stand up and run its own Digital Transformation Team. Nathan McIntosh, one of the co-presenters from the Council described the situation as "We needed to be taught to fish."

As we learned, the plan was to develop a cross-disciplinary team within the Council, with a customer-centric/mobile-first attitude to rewrite the ~3,000 pages of content on the current website and deploy it to a new responsive designed set of templates.

Emma gave us a big overview of their plan, then talked us through in more detail about their Investigation and Planning stages. After explaining how that worked, she had us all pair up and do an exercise to demonstrate the process.

We were each given an example briefing pack for improving the user experience of obtaining a food truck license with the Auckland Council's website. The pack contained a couple of user personas, a current state and future state, list of pain points and user needs.

Armed with our briefing pack and a partner each, we strapped on our mobile first mentality and furiously designed out solutions. So yeh, we had to work a bit for our tacos and Emma did more showing than telling us about the process which is always annoying in a talk (for me) and always recommended if you want people to understand what you're talking about.

She finished her talk with saying "In the end, we taught them to fish."

It was a good talk with excellent slide deck and good interaction. It was also very interesting to see how they approached the task and their own 'flavour' of Agile in a business.

My takeaways included:

Digital transformation isn't easy but completely necessary
Transformation runs way beyond deploying a new website
Building capacity within a business is essential
Communication and collaboration is absolutely key
Mobile firsts, user centric, accessibility is critical
PDFs MUST DIE!

The Wide, The Deep, and the Lean

Dave O'Brien

Dave O'Brian talk was about evidence-based design; how focusing on one solution to a problem too early in the process can leave good work behind on the 'cutting room floor'. He talked about going wide, going deep, going lean.

Wide

Gather as many solutions as possible because you don't know enough to know if you have the best design or solution yet. Plus you're not "all that, and a bag of chips" so look wide for people too, not just the "designers" for a solution. Talk to call centre peeps, consider everyone's solution, go wide and then test rough prototypes to narrow the field.

Deep

With a more nuanced number of solutions on offer, it's time to go deep and investigate which solutions are best. Here, says Dave, you iterate. You test and try again and you throw out the solutions that don't work that aren't good, that fail to solve your problem. When you've discounted those ideas and your down to a small handful, you go lean.

Lean

What is the cheapest, easiest, quickest way to prove that your solution is the right solution? Figure an hypothesis then test it. For example, do people really need help when they're on your website? why not add a button to no-where in the shape of a "help" button and see how many people click on it. If 6% of your users click the button then do you really need to provide help that way? if 96% of people click on it then you have your answer.

Anyway that was interesting and entertaining too. I have since used this method to help begin solving a problem I have at home - domestically speaking, this way of thinking about problems is completely transferable. My takeways included: