Jared M. Spool
Building a winning UX strategy
How much should you invest to truly delight your customers? When you focus on removing frustration you end up with a product that just satisfies. Moving past that to delight means changing your whole approach.
Learn how to use the Kano model to help you prune features, locate missed customer expectations, and identify innovative ways to add the value that delights customers. Helping you to build a strategy that solves real problems, not just adds new features.
— > Session notes
- Kano model frustration → delight via investment
- Hyatts attempt to add delight via ‘random acts of generosity ‘ failed because they didn’t first fix the customer frustrations
- To get to ‘delight’ you have to get past the point of thinking ‘lets just not suck!’
- Avoid experience rot — the adding of more and more features until the product usability goes backwards
- ‘Start with no’ (via 37Signals — Getting Real)
- Be brave and refactor, remove features and focus on user needs
- Meeting ‘basic expectations’ is hard as expectations are always increasing.
- Meeting those ‘basic expectations’ never gets you passed the neutral ‘lets just not suck!’ point
- Things that initially ‘excite’ and ‘delight’ users eventually become ‘basic expectations’ so you always have to be looking for the next opportunity to fix user problems
- Because the key is to focus on fixing user problems not just adding features — the features need to map to real problems (identified by real user research)
- Innovation is about adding value to existing inventions rather than actually inventing
- See Bruce McCarthy’s ‘themed roadmaps’
- A strategy based on solving user problems is a UX strategy
Ben Yoskovitz
Implementing lean analytics
Lean Analytics is the combination of Lean Startup best practices and the use of data to build better startups and products faster.
The goal is to help you understand how to use metrics (along with your gut!), what to track and when.
Ben will cover key topics from the Lean Analytics book including the One Metric That Matters, the 5 stages of a startup (or product) and the Lean Analytics Cycle.
— > Session notes
- It is the ‘measure and learn’ elements that the Lean cycle tends to break
- What to measure and when to measure it?
- You have to remain intellectually honest with yourself — trust your gut but don’t be a slave to it.
- If a metric won’t change how you behave it is a BAD metric
- Start with a drawing out your customer journey map and then identify the steps within that where you need more data — this will change over time as your product matures
- Pick a single metric that matters
- This will change and it is more about actually having a single indicator of business health that provides you just enough information to dig deeper if need be
- There are likely to be other metrics collected at project, department etc levels — these need to contribute to the overall metric in some way — there needs to be join up
- Once you have that metric that matters get it on a wall including the hypothesis behind it — refer to it all the time
- A LEADER KNOWS WHAT QUESTIONS TO ASK
Roman Pichler
Agile product roadmaps
A product roadmap is a high-level plan that shows how a product is likely to evolve over time. While a roadmap is a useful tool, applying it in an agile, dynamic context can be challenging:
How can we create a realistic forecast when markets and technologies change frequently and unexpectedly? How can we build a longer-term plan when development teams commit to no more than four weeks? How do the product roadmap and the product backlog relate? This talk answers the questions above and provides practical tips to help you leverage product roadmaps in an agile context.
— > Session notes
- A roadmap is “an actionable but high level plan that shows how a product is likely to evolve”
- It is often split by major releases or product versions
- They provide a continuity of purpose that gets people to look beyond the next couple of weeks/sprints
- They can help with stakeholder communication and understanding as a single point of truth that everyone can buy in to
- Good roadmaps help with prioritisation of the backlog
- The roadmap is strategic — the backlog is tactical (though this isn’t a one way relationship and often the backlog can influence the roadmap)
- Focus on goals not features in the roadmap and ask why?
- A goal should represent the benefit you are trying to bring to the user of the product (similar to the theme approach mentioned in first talk)
- It is useful to add timeframes to the roadmaps
- It is also important to make sure the goals are measurable and that the success criteria are captured and reported upon
- Features are included but they are ‘second class citizens’ — only there in support of the goals
- Realistic roadmaps need to be validated by product visions / strategies that have been validated via user research
- Product managers should own the roadmap but openly and in collaboration with team members and other stakeholders (including users)
- Review the roadmap — it is not static but you need to be realistic and not create a constantly moving target
Umesh Pandya
Learning to build Wayfindr: independent travel for blind people
Of the estimated two million people living with sight loss in the UK, almost half say they would like to leave their home more often. Wayfindr is a pioneering not-for-profit on a mission to empower vision impaired people to navigate the world independently.
We’ll take you on a three year journey of continual learning from initial prototypes, through pilot projects at London Underground stations, to the upcoming release of the Wayfindr Open Standard for audio-based wayfinding.
— > Session notes
- Working in partnership with RLSB inspired by the challenges facing young visually impaired people face
- The team focus on making the most out of already existing technologies to make peoples lives better rather than chasing the next shiny thing
- 285 million visually impaired people worldwide — 2 million in the UK
- Team took a ‘design research’ approach including simulation (travelling the underground wearing glasses that simulate visual impairment), observation exercises and co-creation with potential users (including journey mapping.)
- Started off building a mobile app but then realised that creating an ‘open standard’ that everyone could use would be more beneficial as there was a need for emerging tools to be consistent
- They created a backlog of hypothesis and then worked to validate each of them via user research. Real users. Real settings. Real time updates to the prototypes.
- They tested in context not in labs.
- Looking to measure the well-being of the users before and after using the prototype.
- The team are opening up all their user research and discovery findings to make it easier for people to build on their work.
Johanna Kollmann
Understanding systems
User research, analytics, hypotheses and experiments: we are focused on gaining understanding through data, validating that our interventions bring about the (user) behaviour we desire. We design systems, the systems we design interact with other systems, and it’s all getting awfully complex. Can we truly understand what’s going on?
In this talk, Johanna will introduce you to core principles of systems thinking, and discuss how they relate to our work as designers of products, services, companies. What methods and tools can we employ to make sense of systems? How do we enable users to form a mental model of a system — and what role are we designing for our users?
— > Session notes
Got a bit lost by this session but this is a list of links to people referenced in the talk and a couple of the major processes which I’m pretty sure gives a solid grounding in to the history and opportunities of systems thinking and how it fits with product design.
- Donella Meadows
- Abby Covert
- Peter Checkland
- Dave Snowden
- Russell Lincoln Ackoff
- Kevin Slavin
- Matthew Milan
- Iceberg model
- Rich pictures
Tendayi Viki
Five principles for building innovation capabilities in established companies
Established companies are under pressure from various quarters to act like more startups. This is mostly because there are now several examples of large companies that have been unexpectedly killed by newer and more nimble entrants into their markets.
But large companies are NOT startups, nor should they aspire to be. The startup way is toolbox of principles and methods that can be applied by any type of organization working on innovation. This talk will outline the five key principles from within that toolbox that are relevant for established companies.
— > Session notes
- Wherever you put your ‘innovation’ initiative in a big company/organisation sooner or later someone has to decide what to do with the outcomes
- traditionally established companies have been good at ‘exploiting’ not ‘exploring’ ideas
- But established companies are NOT startups and should not aspire to be
- Innovation is ideas plus sustainable model not just ideas
- Principle 1 Innovation Thesis — there is such a thing as a bad idea so you need an innovation thesis in the same way as VCs have an Investment Thesis. What are you going to concentrate on? Where are you going to invest resources?
- Principle 2 Innovation Portfolio — look for a balance between core product, adjacent to core and transformational — something like 70/20/10 is optimal
- Principle 3 Innovation Framework — stop people investing in Powerpoint fictions. Make them follow a process that enforces the Lean methods — especially discovery and validation of ideas (also prototyping)
- Organisational capabilities are more powerful than individual skills so if you don’t create a supported process people will leave as they don’t get sufficient cover.
- Principle 4 Innovation Accounting — if you ask people to experiment then you need to treat them like that from a finance point of view — not like an established product. Different (set levels) of funding available at different levels of the Framework — basically risk goes down, investment goes up. VC style.
- Principle 5 Innovation Best Practice — you need to train the product teams to understand the process. Empower champions. Create a playbook. Create a company wide culture with support from the top. Eventually it will become an ecosystem.
Jane Austin
Radical trust: learning to let go as a leader
How do you scale your effectiveness as a leader? I’ll take you on my journey in answering this question. Moving from a culture of top-down management to one of radically devolved teams. Learning new ways to help build autonomous, inclusive teams that are empowered to find their own direction. Allowing you to let go as a leader and be confident that your teams will all go in the right direction.
— > Session notes
- Agile enthusiast as it put the trust in the hands of people doing the work
- Changed attitude towards leadership
- Beware of ‘cargo cult’ agile — calling a meeting a stand-up does not make it agile!
- Raffi Krikorian — ex Tech Lead at Twitter — talks about 3 important elements of high performing teams: Autonomy, Purpose, Mastery.
- Empower the team as much as possible
- Set the vision and ‘show the way north’
- Support the team — give them as much cover as possible
- Trust teams to deliver and self manage BUT if someone abuses trust deal with it immediately
- Don’t micromanage — coach
“Anyone can steer the ship if the sea is calm” Publicus Syrus
- Leaders need to accept dissent — encourage your team to speak up. There is nothing wrong with friction and discussion.
“The antidote to fear is trust.” Ed Catmull
- Keep high performing teams together
- Build a culture of openness and honesty especially for retrospectives
- Trust your team and your processes but evolve them together
- Give credit where it is due — say thank-you
Trust is contingent on the character of the leader.
- The whole team does user research (Testing Tuesdays)
Jeff Gothelf
Scaling lean: project, program, portfolio
The term Lean has become widely popular, particularly with the word “startup” attached to it. This has led many people to believe this is an approach to work relevant only to new companies or initiatives. Lean-curious companies who have tried to implement these ideals often stall at one or two teams citing organizational complexities, politics and dependencies as insurmountable obstacles to Lean Startup at scale.
Can Lean Startup practices be scaled — not just as culture and philosophy but as tactical process? In this practical presentation, Jeff will share several methods for scaling Lean Startup techniques in large organizations exemplified in detailed case studies and professional experience. Jeff will cover knowledge management, intra-team dependencies, infrastructure requirements and several other elements of ensuring successful Lean Startup practices in companies of any size.
— > Session notes
