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.