Teaching Product Teams to Fish for Themselves – March 2023 Wrap

For our March session of Product Anonymous, we were fortunate to be joined by Amir Ansari, Global Head of Product Design at Iress, to share some of his experiences with raising design maturity and capability in his organisations, and it may not be how you would initially think.

Appreciation of Product Design

Over recent years, many more companies have started to appreciate the value of product and design. And as an industry, we’ve seen a bit of an explosion in growth. Many companies have bolstered their design teams, and transformed the way they work. 

  • Atlassian grew 1600% or 16x in 4 years (6 to 106 designers)
  • Coles grew 550% or 5.5x in 1 year (10 to 65 designers)

But how many designers are enough?

Is it even about the number of designers? Or more about the ratio of designers to developers?

So what’s the best path for designing and building better products? Is it to hire a bunch more designers, and get the ratio down? Some implications of this approach may be your increase in overhead, and the need to change your operating model, which is not necessarily a terrible thing. However, surely there’s a more scalable way to grow.

In fact, according to a Nielsen Norman Group article, the typical ratio alone does not ensure greater organisational impact, better designs, or more usable products.

The Challenge – How might we Improve Design Maturity…

When we talk about Design Maturity, we’re talking about:

  • Product Design
  • Innovation
  • Human Centred Design
  • User Experience
  • UI design
  • Visual Design
  • Service Design

Back to that designer to developer ratio. For Iress, the ratio is 1:35. Or 1 designer working across 5 squads. That’s 14 design practitioners, grown over 20 years, covering 120 products. When it comes to design, Iress still falls short of a minimum acceptable amount of practitioners.  

An assessment against NNgroup’s stages of UX maturity would be between 1 and 2, with obvious aspiration to move towards a 6.

So therein lies the challenge – how might we improve the design maturity, without unrealistically increasing UX headcount.

Guiding Principles

As the old adage goes, If you give somebody a fish, you feed them for a day. But if you teach somebody to fish, you feed them for a lifetime. 

The same goes for design – to increase design maturity, don’t just rush to increase design headcount.

Over the past 15 years, one of Amir’s fundamental principles has been to democratise the craft of design – to teach and empower everybody within the organisation to practise design, from customer research, to experimentation, validation and much more.

Ensure everybody has the confidence and is empowered to talk about design. Talk about the product. Talk about the customer. Talk about the end user.

Designers are facilitators of the design process. Not owners of the design. 

Everybody else in the room, from Business Analysts, Quality Assurance, Engineers, Product Owner and Product Managers all have a perspective and opinions too. Use the right toolkits to validate those opinions.

“Do the best you can until you know better. Then, when you know better, do better.”

Maya Angelou – American Philosopher

Nobody can be an expert straight away. Mastery comes with practice. So continue to practise and build that muscle.

Don’t start by putting slide decks together to pitch for why design should be more valued, or why you hire more designers. Rather, get out there with the clients, and start doing design work, and showing value. Use that newly created value as the enticement to invest more in design.

Strategies

Educate, coach, train anyone who shows interest, and promote DIY. 

When Amir first started at Iress, there were only 6 designers to support 700 engineers. Way too many to try to teach every single engineer about design practices. So one of the first things they did was to document their playbook, starting with some of their most common human-centred design activities that were relevant to Iress. And without jargon, so that non-designers could understand and follow too.

A typical Playbook Topic skeleton could include:

  • What is it?
  • Why should you do it?
  • When should you do it?
  • How to do it?
  • Resources and templates
  • Skill level required
  • Typical duration

This way Business Analysts, Product Managers and others could read the content, reach out for guidance, and give the activity a go.

Following the activity, the design team would debrief them – how did it go? What worked, what didn’t? Try this next time. Essentially, helping team members add another tool to their toolkit.

The design team also tracks the playbook engagement. Who is visiting, and from which disciplines? Which topics are being used? Are some topics being neglected? Do they need to run campaigns or refreshers to get people to re-engage?

Create champions

It’s important to reduce the friction for non-designers to get involved, learn and talk about the design craft. At Iress, they introduced communities, and have created over 25 design-specific slack channels, some around design-related themes (eg, the Iress Design System), others based on region (eg, for Melbourne Product Design Team, or the UX Research Enthusiasts UK channels).

Also, after running design activities, Amir’s team gathers feedback and measures the sentiment of non-designer participants about the process. Was it valuable? Could something be done better? Would you come again? Build interest and iterate the process so that people want to return.

Bake into existing processes

When you’re trying to change the way people work, there is always going to be resistance. Everybody is already overworked. Reduce the barriers. Break up the processes and the craft, and insert smaller portions into existing processes.

Product design principles – agreed and followed

The Design Team (or one of their principals) created a design charter, or a set of principles, that the team could easily and quickly refer to, so regardless of where they were in the design or build cycle, they could check that they were on track. Have they removed their biases? Did they understand what success would look like? And can it be measured? 

Make it a team sport

Design is a team sport. We all work for product companies. We are all responsible for delivering value to the customer through the products we build.

Create demand in product design and UX. 

Show value from the UX craft, so that more people want to join in and share the same

Beware, some of the Traps

The Dunning Kruger Effect

After you’ve coached somebody, and they’ve read a bit of material from your playbook, and even run an activity, there’s a danger that they overestimate their ability. There is a chance that they start to erode the craft of design. 

Constant education and reinforcement is required. 

  • Did you know you only need 5 users for meaningful research? But did you also know you should have asked the user this, and you should do that. 
  • Did you know if you run a design sprint, you need to prepare x, y and z?

If you build it they will come

You cannot assume that just because you’ve taught a group of people once, that they will continue. Everybody has their own work to do, and their own agendas. Again, constant education and reinforcement.

Thank you

Thank you so much to Amir for sharing his insights; our volunteers – Gwen, Nosh, Sakthee and Steve; and our event host – SEEK.

Further reading and resources

Some resources mentioned during the session include:

Reece’s Secret Sauce to Product Success – October 2022 Wrap

How well do you really know your customers?

Do you have to reference a user testing report to try to understand their needs?

When you are designing and building solutions, how easy is it to test your assumptions?

Do you need to kick off a testing with a 3-4 week lead time, to recruit, book and run sessions?

Could there be another way?

The folk at reecetech thought so. 

Immersion, Immersion, Immersion – Branch Time

Starting from their grad program, and soon proliferating throughout the rest of their teams, new Reece employees are given an induction like no other. They are sent to one of the 644 Australian branches to immerse themselves in the business.

It’s back to apprentice mode, as you get first hand experience of the customer sites. The 7am morning rush, helping setup customers, picking and packing orders which come in from all areas (overnight orders, phone, app and in-person), receiving stock, organising deliveries,  reporting back when things don’t go quite right. And seeing Reece’s customer obsession service standard for yourself.

Not just for research purposes, or standing on the sidelines taking notes. But by working side by side with the branch staff, serving customers. 

Everyone has done Branch Time. 

Even the CEO.

How long can vary for different areas, depending on their needs. But the standard stint for a Product Manager is around 6 weeks.

The Pros and… More Pros

But sending every new hire to Branch Time is a serious commitment – in both time and dollars. 

So what’s the upside?

Firstly, accelerating your understanding of the business, and building a strong foundation to make decisions in the future. This is not always tangible or measurable by reporting, but what better way to fast-track your decision making capability?

Also, forming connections and relationships with the branches, and understanding the mayhem of retail. You even get direct experience with using Reece’s internal systems, such as TRS. You always have access to feedback, as you’re constantly in contact with branches. 

And, of course, establishing deep empathy with your customers, the majority who are tradies. Understanding and becoming intimate with their customer problems, so you can ensure the right solutions are developed to deliver the right outcomes. Knowing their world also enables you to contribute and create meaningful OKRs (targets). 

But it doesn’t stop there: 

  • Branch managers and staff also benefit from building relationships with somebody in head office.
  • After Branch Time, you have ongoing access to the branch network, to continue to foster relationships, to interview or to validate ideas and concepts with staff or customers. 
  • New team members also go through the same Branch Time experience, so there is a shared understanding and common ground established.

Thank you

Thank you again to Cameron Rogers and Nikki Pecora from reecetech for sharing, to our volunteers (Nosh Darbari, Yau Hui Min, Steve Bauer) and to our lovely hosts Lexicon and A Cloud Guru.

Working with user research

Back in March, we discussed different types of user research and focused in on diary studies. In May, we’re talking about how work with those insights to build products and some of the challenges you may face.

We have 2 amazing speakers on Thursday May 25th with first hand experience.Through a case study and reflection, they’ll show what it’s like to run user research and let the results drive the product & features.

RSVP now

Using Experience Sampling for Rapid Insights into User Needs

In this case study, George Cockerill will share how using the Experience Sampling method gave rich insights into user needs for the feature ideation of a brand new mobile app at Deakin University.

As part of the research activities to inform the development of a smart assistant app for students, Experience Sampling quickly gave the product team useful and relevant data to help understand student needs, behaviours and pain-points in multiple contexts over time.

George will talk share his experience of planning, executing and analysing the results from an experience sampling study. With practical advice on how to run the study, tools and techniques, the key points you need to know and things to watch out for.

Why is Marathon Running Important when Introducing User Research?

During the last decade, user research has been a key component of the product development process. Within the games industry there has been a significant effort that focuses on introducing and integrating user research as part of a ‘player first’ culture. Numerous challenges exist when doing so -especially when working with teams who have not been exposed to user research previously.

Kostas Kazakos will reflect on these challenges via his personal journey as a marathon runner and guided by Donald Schon’s reflective practitioner’s approach

He will also introduce DECEMA – a frame of reference whose aim is to help UX practitioners when introducing user research to development teams and organizations.

Our Speakers

George Cockerill is a Senior UX Designer at Deakin University, a Lead UX Instructor at General Assembly, an organiser of the UX Melbourne Book Club and can be found on Twitter at @GeorgeCockerill.

Kostas Kazakos is a User Experience Researcher with a qualitative mind and a quantitative heart. He currently manages the user/player research at Firemonkeys (an Electronic Arts studio located in Melbourne). For the last 10 years, Kostas has been handling primitive research problems in the mobile space and turning them into actionable design insights by employing a palette of qualitative and quantitative methods. He is an advocate of experience-centred design and passionate about answering the ‘why’ behind the ‘what’.

RSVP now!

Our Hosts

We’d like to thank Seek for being our hosts this month!
seek

February Wrap-up: Rogue UX

Duncan Macneil thinks UX needs a new approach which immediately puts the focus on the UI, functionality & user experience – and that new approach is absolute fidelity.

Prototype Fidelity

Traditional vs Rogue UX

Traditional vs Rogue UX

Duncan believes you will:

  • save money as it will iron out the bugs & solves problems before developers are brought into the process. For every $1 invested here you save $3 or 5 or 10. Removing a guess is removing development
  • save time by decreasing the back & forth between developers & others in understanding all the requirements
  • save time by encouraging stakeholders to make decisions right then instead of sometime later plus puts focus on the core business decisions
  • be able to generate a buzz amongst the stakeholders as they have something immediately to play with & show off to others (which leads to funding!)
  • bridge the artificial gap between design & development

In conversations with developers, Duncan has asked how long it took to build X and if he were to delete the code, how long would it take to rebuild it – six months vs 1 month since during the rebuild the person knows exactly what they need to do and what problems/solutions were needed.

Since the prototype looks so real, no one in the room is thinking ‘I’ll sort that out later’. It adds a level of fear & panic in stakeholders that they bring up issues right away.

Show your stakeholders the simplest user case & once they leave get into the nitty gritty detailed cases with the people that really care.

If at all possible, hook the prototype up to real live APIs. This is incredibly useful when someone asks about a particular edge case and when running various user scenarios.

How can you do this?

Duncan believes in starting with low fi (paper or balsamiq) then going right to absolute fidelity.

Use your low fi to sketch and make the big changes.

He recommends using a beginning to end process – UI layer from beginning to end, then data from beginning to end. Focus on the UI, data and business rules. Typical functionality around login, backup, reporting do not need to be included (unless of course you’re building a reporting product).

Make it as real as possible! Know the current search is taking 3 seconds to return? Build a delay into your html.

What do you say when stakeholders think the prototype is a finished product ready to launch tomorrow? Talk about the backend items that are needed – security, backup, databases and other technical aspects that need to be built.

What tools are needed?

Having some knowledge of HTML5, Bootstrap, Javascript and Jquery is enough.

Code you need to know

Code you need to know

Duncan also recommended using Balsamiq and Pinegrow web editor.

3 learnings

3 learnings


If you are interested in continuing the conversation, join Duncan’s list at http://uxrogu.es/ or check his site.

Thanks Thoughtworks for hosting us!

Thanks to Fiona Knight & Richard Burke for helping pull together this summary!

Rogue UX – Absolute Fidelity is the way to go

Is the (current) sacred cow that we start with low fidelity so we can iterate quicker, get more customer feedback and manage stakeholders better?

Or is that just a waste of time and energy that produces low value feedback?

For our first session of the year, Duncan Macneil will talk about his experiences in pushing absolute fidelity from day one. How are UX tools like Azure impacting feedback? Why is high fidelity better? What happens when stakeholders think you’ve already built the thing? And OMG… What will the lean people say? He’ll share both the wins & the losses with this rogue ux concept.

We’re leaving lots of time for discussion on this one 😉

RSVP now!

Location TBC

FYI, if your company is interested in hosting a Product Anon session this year, please get in touch with myself or Liz.

Duncan Macneil is the founder of Cartesian Creative, a whole-of-service consulting firm where art & science collide via human factors and technology. He is also an ambassador for IBM Bluemix.

February wrap: Product Managers are from Pluto* and UXers are from Uranus

There are a lot of similarities between Product Managers and UXers in how we think and the work we do but we also see things differently.

A fabulous panel of UX and Product Manager pairs spoke about how they work together collaboratively at their organisations. A lot of common themes came out of the talks, but also the individual styles and cultures of each of the companies presenting showed how important the set up can be to the individual experience.

This event could not have happened without the fabulous support of the product management team from Aconex and the lovely facilitation by Kirsten Mann (Director Customer Experience / UX and Online Support) to keep our speakers to time and inject wiseness and humour at the appropriate moments!

*The ‘object’ formerly known as the Planet

Our panel was made up of:

Aconex / Mark + David

David and Mark kicked off the panel and used a few props to get their point across. David mentioned that he had once heard a great quote from Peter Merholz that stated “good UX is indistinguishable from excellent product mgmt”. That certainly brought some questions to mind as to what the reason is for defining and separating the roles, so David and Mark proceeded to use their hoola hoops to show us the differences (and the intention was to show the overlaps but the window space didn’t support that!)

image1

Mark called out a whole bunch of tasks that are usually sitting in the PM circle – product strategy, market fit, competitor analysis and we can go on… and David listed out traditional UX tasks such as design, customer journey maps and more. Then the guys proceeded to swap their tasks from one circle to the other – because for them it sometimes just depends on time and need as to who does it. Not title or law.

Mark pointed out that since joining Aconex and getting the opportunity to work with David he has been really pleased to find he doesn’t need to do so-called UX tasks anymore. He had previously done them, as he didn’t really have someone else who did. So now he is really enjoying not having to do it and being able to rely on such fabulous quality work that David produces.

SEEK / Nicole + Vedran

Nicole and Vedran organised their thoughts into four key ares:

  1. Involve the UX-er early
  2. Always start with the user journey
  3. User testing is not just the UX-ers responsibility
  4. Product managers can design too (queue audience laughter for this one!)

image5

Nicole shared with us that the Seek had only recently (1-2 years ago) begun to adjust their approach to include UX more closely in their product design and process. Seek had for a very long time been a strategic driven organisation and as a result saw the UX and design part as an later part of product design. Once the UX was being involved in the conversation early, including the strategy discussions, product have found it is a much easier and quicker ideation process because everyone understands the direction. Now it is just debating the nuances of button design (radio is best!) rather than the product purpose.

The call out about getting more of the team who will build the product involved in the user testing was well received by the audience. Perhaps in the opposite twist of the above observations, a lot can be lost in translation. If the UX-er is the only person who can provide a perspective on the customer need a lot of internal debate persists about what the customer problem is, instead of an argument about how best to solve the problem. The latter type of discussion obviously being a much preferred outcome as everyone is now contributing to the best product rather than which is opinion is more valuable.

Vedran spoke to the last point about product managers being able to design – i don’t know who was laughing more out of the audience, PM or UX – but Vedran’s point was that everyone should be able to contribute to the design process. It should not necessarily remain only the domain of the UX team/person as anyone can throw in a light bulb moment to the problem. If the first three steps have all been followed then the whole team is engaged, empathising and understanding the problem and thus all can contribute.

MYOB / Russell + Scott

The guys from MYOB took things in a slightly different direction from our first two speakers – they rejected the premise that UX-ers and PM’s are not getting along. They also shared a lot of space metaphors…..

The context Russell provided was that MYOB has been around a long time and enjoys considerable success with a significant market share. Disruptive competition has certainly challenged that position but that has brought about some positive changes, whereby UX and product were merged into the same teams. This has brought a lot of benefits to the relationships and the team dynamics because everyone is now set with the same objectives. It is perhaps other teams that they don’t play so well with now…!!

image6

A common approach helps everyone remain pragmatic and everyone spends a lot of time with customers. There is very clear focus on ensuring plenty of lead time is provided to design before going to the engineers. There is nothing worse than setting up a team with design and engineering at the same time and then having engineering wait for UX. It puts too much pressure on that side, and leave engineers equally in a frustrating position.

They do have some situations that don’t work, despite things currently humming along well. When an individual comes in and wants to be a control freak or a rock star that isn’t so helpful. The other side of it that Scott pointed out was that sometimes the designer has to remember to let go of the gold plated version!

REA / Chris + Ricky

Last, but certainly by no means least Chris and Ricky talked us through their approach. They also had a little bit of a scene to set – as REA had been, for a time, always arranging staff into project teams for product development. This lead to very project focussed objectives that resulted in poor cohesion between projects, and accumulation of both tech and design debt. Chris described himself as the “crusher of dreams” as at times he just had to say no to good design as the project deadlines loomed.

image7

Ricky shared this frustration at times needing to “talk up to the PM” to be able to get an idea across the line, as they were making the calls and their delivery pressures were creating tension between good design outcomes and budget/timelines. The intention had not been to create an informal hierarchy but it creeped in as a result of the environment.

REA realised they needed to change from this model and adjusted the teams accordingly. Both Ricky and Chris described how they then run specific cross-team sessions to keep abreast of what designers or product managers, respectively, are doing in other areas of the business. In terms of design this is particularly important to set out a UI toolkit /style guide to ensure end users do not get a clunky experience just because different teams are working asynchronously on the product.

Unfortunately, our 4th company, 99designs, were unable to make the session but have made their slide deck available. We hope to have Susan Teschner (product) & Catherine Hills (ux) at another Product Anonymous in the future.

Question time

We threw to the audience for questions – and there were a lot.

However, perhaps this is all best summed up by Rebecca Jackson – sketchnoting the evening (& see her blog post on the evening).  

If you wish to learn from her on how to enhance how you communicate via sketching then come check out the next Product Anonymous session (Mar 19th is the next one) & follow us on Twitter @product_anon or any of the other social networks we live in.