Skip to content
Prediction. We’ll make team work more predictable: we’ll make it easier to know what users needs and what we need to do to meet their needs.Collaboration. We’ll make team work more collaborative: we’ll no longer be a team of one person silos grouped together in a Scrum team. We’ll achieve true collaboration.Learning. We’ll make team work on continuous learning: the team will deliver great products and services because of what they learned, not what they thought they knew.
Everyone is a designer.Not everyone is a good designer.Everyone can become a better designer.
People that start to build expertise start from a stage of unconscious incompetence: we don’t know what we’re doing, and we don’t know we don’t know what we doing, we don’t see the difference between good and bad, we can’t judge whether we’re doing good or bad stuff.The second stage is conscious incompetence: somebody points out we’re not good and we suddenly become aware of the distinction between good and bad.If we keep practicing we learn we can become better, we can develop skills by learning the basic practices. We become good at what we do. That’s called conscious competence. We’re not great, but we can get good outcomes: we can follow a recipe, we understand a procedure…The last step is when we encounter a situation we’ve never been in before, and we make it work. This is called unconscious competence. We’re so good at something we don’t have to think about it anymore, it just works.
Unconscious incompetence → Conscious incompetence. We call this Literacy.Conscious incompetence → Conscious competence. We call this Fluency.Conscious competence → Unconscious competence. We call this Mastery.Exposure to users: they’ll realise the things they’ve been building don’t help, and will seek the low-hanging fruit.CritiqueComparisonsUI StandupsDesign Studios (w/critique)Paired Design & Developers Surfacing confidenceRegularly reviewing design rationaleDeveloping emergent principlesScenarios and journeysReflections on what we’ve learned
Build up your Agile team’s UX capabilities
The transformation to a mature Agile UX company is based on three pillars:
Many (if not all) of the decisions affect the experience users will have. Finance, HR, performance… Those are UX decisions, whether we recognise them as that or not. If the team doesn't have the expertise they need to make those decisions correctly, the odds are they'll make them incorrectly. Agile and UX can't work together when the UX expertise lives in just a small portion of the team. And we don't have enough designers to make sure every UX decision is made by a designer.
We have to accept this, especially when working in Agile teams:
There's a common confusion between roles, skills, responsibilities, and knowledge.
In UX, jobs are often filled as roles.
But the work isn't done by roles. It's done with skills, knowledge, and experience.
Expertise is the total sum of an individual's skills, knowledge, and experience in every area.
We have to help everybody on the team upgrade their skills, responsibilities and knowledge (their expertise).
Our expertise can be broad, it’s not a label. The zero sum notion that becoming better at something makes you worst at something else is wrong. Everyone on our team can grow their expertise.
Management trainer Martin Broadwell had this theory that there are four stages of competence. Noel Burch later helped teach it broadly.)
We can classify the transition between stages the following way:
The individual understands the difference between good & bad, but can't make the outcomes themselves, yet.
The individual can now regularly produce decent outcomes on their own, as long as they follow established routines and practices.
The individual can produce great outcomes that require going beyond the established routines and practices.
If we want Agile teams to become better we need everybody to be literate or fluent. We don’t need everybody to be a master.
If everybody around us was literate or fluent in UX design, they would do amazing things. E.g. a product manager could talk with a user without asking leading questions and actually come back with a clear problem.
As UX leaders, our #1 job is to increase the maturity of everyone on the team, making sure that everybody is as fluent and as literate as possible. The more fluent and literate they are, and the more they know about our users and what those users need, the better our products and services will be.
Brown-bag lunches and Lunch-n-learn sessions will have very limited success. These instructor-driven techniques are usually too abstract and separated from the work. Instead, we need to integrate our “design education” directly into the day-to- day work (experiential learning).
Experiential learning starts with concrete examples, then gets into abstract concepts. Learn things by doing them, not by some theory. Experiential learning is proven to be far more effective to teach new skills.
There are many proven techniques for experientially teaching UX:
These need to be integrated into our sprints. They shouldn't be isolated "training" activities. Repetition is our friend. We need to use it. We should not isolate training from working, they’re one and the same.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.