Words have meaning. Words can be defined in many ways – and can be misinterpreted in just as many ways depending on the context in which they are used. Have you ever had a conversation about ‘design’ with a development team only to find half-way through the conversation that you are talking about the UI and the Customer, and they are talking about the design of the database structures, the code, or the technology stack?
Let’s consider for a moment how many large organisations are coming to the realisation that their size, legacy and ways of working have industrialised the ability to think and act creatively out of their businesses. They study start-ups and create innovation teams to try and emulate some of the practices they deploy to disrupt service, products and business sectors and they study agencies to understand how to create people and culture programs to engender better ways of working for their employees.
Over the years I’ve seen the approach to innovation vary in organisations. Where organisations are design-led an innovative approach is part of the cultural fabric or ethos of the organisation. This can be seen in organisations like Apple and Tesla. It can also be seen in many start-ups, where a founder, in pursuit of defining a vision sees obstacles as challenges to be solved and the perceived risk of large organisations as opportunities.
We all like to think of ourselves as responsible designers and researchers. We follow design methods that take into account our experience, we analyse data and we follow user-centred design methods that involve testing with our Customers. But designers who follow design methods don’t commission ALL research that is conducted. Research is often commissioned by project managers, proposition teams, sales teams or others who have various agendas that revolve around saving time, managing scope, conforming to budget, plugging revenue gaps, or fulfilling other less customer or design-centric reasons.
Having worked as a consultant and contractor on both sides of the Transformation/BAU fence, there is often present a divide in ethos, ego and perception. In digital, People who work in the BAU arena typically optimise and maintain live websites, apps and software. BAU teams are predominantly made up of permanent members of staff because it often requires a lot of specialist training and continuity. As employees, they feel more a part of the fabric of the organisations they work for.
Micro experiences can be delightful artefacts to design and use. They are designed with care and crafting and seen as completely standalone pieces of functionality that are meant to delight in their simplicity and usefulness. But how standalone are most pieces of functionality? How often are these small, simple pieces of functionality part of a larger User Experience?
I find myself using the word “narrative” a lot lately. Whether I’m talking about UX and the cohesion of design, or CX and the importance of journey mapping, or agile delivery and the breakdown of epics and stories into sprints. You see… I’m one of those closet dreamers who took a break from their career to earn a master’s degree in creative writing. I’m a closet wannabe novelist working out my frustrations through wireframes and design.
Many organisations are undertaking digital transformation programs to “put digital at the heart of their businesses”. This isn’t a new thing. In a way, by replacing legacy systems, upgrading IT infrastructure, and putting in CRM and distribution systems, we’ve been on this path for the better part of the last decade. In parallel to this, User Experience and in a larger sense, Customer Experience, have been gaining traction at putting the People closer to the centre of our designs and our organisations. So if at the same time we talk about putting digital at the centre of our organisations, what does that mean for People using digital systems?
“Ever tried. Ever failed. No matter. Try again. Fail again. Fail Better.” Samuel Beckett Fail fast is a nice alliteration – which is one of the many reasons I think it has gained such momentum in the product design space. “Succeed fast” or “iterate quickly” doesn’t roll off the tongue nearly so well. Fail better seems only moderately more hopeful. How many times can you fail fast before you need to succeed in something? Small organisations – e.g. start-ups – might be better positioned to fail fast – if only because their idea-to-launch cycles can be quite short, and the ability to pivot more easily done.
In my experience it never fails that many stakeholders come to usability testing with the question of “will” vs. “can” Customers use their products or services. It’s a natural and desirable outcome of conducting user research. A positive answer can lead to acceptance of a business case, sign-off on a product launch, or pre-mature glory for the product owner and team. A negative answer can help to avert a disastrous build and launch.