NOEL:  Hello and welcome to Episode 18 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and want to help other people find it, please leave us a review on Apple Podcasts. If you want more news and information about us, follow us on Twitter at @Tech_Done_Right or read our technical blog at Medium.com/Table-XI. Sorry about all the underscores and hyphens. We really weren't thinking about reading these things out loud when we came up with those URLs. To learn about past episodes, leave comments and generally stay up to date on all things Tech Done Right, find us online at TechDoneRight.io. No hyphens in that. No underscores.

Today on the show, we have Jeff Patton. Jeff is a consultant who combines product design and agile delivery practices. He's the author of the O'Reilly book, _User Story Mapping_. Jeff and I talked with Table XI's Yana Carstens about how to integrate UX design with an agile team and how to take a team from unconscious competence all the way to conscious competence.

Yana, would you like to introduce yourself?

YANA:  Hi, there. This is Yana Carstens and I am a senior user experience designer here with Table XI.

NOEL:  And our third guest is Jeff Patton. Jeff, would you like to introduce yourself?

JEFF:  I'm Jeff Patton. I'm a consultant who works with product companies or companies that want to be product companies and want to evolve their process to be more product-centric and the only advice I have for you is never trust consultants.

NOEL:  Okay. We're going to disregard that advice, since actually all of us are consultants here.

JEFF:  Oops. Edit that out, okay?

YANA:  I like it actually.

NOEL:  I'm very trustworthy with other people's time and effort. Jeff, why don't you start by describing the kinds of interventions that you do, the kind of product development that you try to get companies started on? What problems do people come to you with and what do you normally try do for them?

JEFF:  I've been around in software development a long time. I started building software in the 90s and in my company in the 90s, I evolved to being a product manager and then I got a very early start with this agile development stuff in 2000 or 2001. The term agile was coined in 2001. I'm an agile old-timer. Most of the companies I work with these days started doing agile development, hoping that agile development would solve all their problems. Agile development solves a lot of problems but the problems agile development does not tackle very well are... with agile development, you can start building things finally. If you were jammed up and not getting anything built, agile will help you there but mostly, organizations I work with are sort of post-agile. 

They started building more predictably and now they realized the problem isn't that we can't get stuff built, the problem is that we build dumb stuff. That's where we start to layer on good user experience practice and good product thinking practice and then the problems quickly evolved to how do we put that in our software process holistically? How do we not just do that stuff and throw it over the wall? How do we involve whole teams in doing that stuff?

YANA:  Wow, that's music to my ears. First of all, I'm absolutely beyond myself geeked at this opportunity of getting to talk to you today so thanks for joining us. I have so much to ask you. You have no idea. I literally had to constrain myself. I have a framework of questions ready. Otherwise, I feel like you'd be stuck here with me for hours.

JEFF:  Good, because I was telling you before, I don't have much to say this morning so I need your questions.

YANA:  Awesome. Well, here they come. Again, on the history of agile development, as you mentioned, starting almost a couple of decades ago, the agile methodology became a way the team started to develop products and it picked up pretty quickly as an effective way to develop features. Now, there were roles that were created such as a product owner, QA analysts, grandmasters. There are different types of engineering roles. It seems that what you've mentioned: new products are being developed in a dumb way, so to speak. But it seems like that HCI and design as a whole was left out of that inception phase. Do you think that that was an oversight? What do you think happened there?

JEFF:  Two things, I think are going on there. First, a lot of the people involved with creating agile and a lot of the organizations, a lot of the companies they worked in when they were first describing agile, we're building software for traditional IT use -- organizations building stuff for their own use. When you're building stuff for your own use, when the users are not the choosers and when the people who use the product have to do so as part of their job, the user experience becomes less of an imperative. Not that it's not important, it's just less critical.

In contrast, building consumer facing applications software that where you're building a product that users are choosers, especially if it's a consumer application or an enterprise application, users and choosers are a little bit closer. If you're building the software for sale and you've got competitors, quality of user experience matters an awful lot more. A lot of agile got its foundation there.

Ten years ago, if we walked into a bank or an insurance company or something like that, there'd be no UX people. If there were token UX people, they were only working on the consumer-facing website and there were only a very few of those. That's the world that agile came out of. It wasn't agile's oversight. It was software development's oversight. I think to some degree, when UX is undervalued, again agile didn't help things but agile was building on misconceptions... everybody's misunderstandings about what UX was and what product thinking was, it just wasn't there before.

YANA:  So who ended up doing the role of the UX designer? A lot seems to have been put on product owner but in terms of describing the why and for whom a feature needs to be built, who did that for the software developers?

JEFF:  Nobody does that. Everybody knows what to build. That's the problem. If you're building software and you don't have anybody that can write code, you won't get any software built. But if you don't have anyone that can design a user interface or knows how to talk to customers or knows how to correctly identify what problems you're solving, if you don't have any of those things, software will still get built. This is the problem that most things that are user experience related and most things that are even product-related and by product-related, I mean should we build it? Is it aligned with where our organization is going? Is this the right thing we should be exploiting for our company? Is this the right area to be focusing on building software?

All of those decisions can be armchair-quarterbacked. They can be made with everyone's intuition. In the absence of not knowing any better ways, intuition rules. Everybody, when you say user experience... I'm not sure who the listeners of this podcast are and they probably know a little bit better, but when you say user experience to the average person, they're thinking, "Look and feel." They're thinking the way it looks on the outside and not all of the decisions we made that led up to that.

NOEL:  I was a pretty early adopter of agile stuff in the projects that I was in so I've been on projects that call themselves agile for about 15 years now. A lot of that time has been spent trying to figure out how to integrate designers, how to integrate product knowledge, how to prioritize, how to do that kind of stuff, how that stuff all ties together? I feel like every team that I've ever been on is trying to reinvent that wheel. How do you see that kind of product vision, that kind of UX design, how do you think it should be integrated into an agile development process?

JEFF:  You know, there's no simple answer to that. I'll riff on you're reinventing the wheel thing. I'm not sure if we ever actually invented the wheel yet or every wheel we come up with is not very round.

NOEL:  Yeah, a lot of flat tires.

JEFF:  Yeah, a lot of flat tires. Nothing really rolls very well. There just aren't obvious solutions to this and so much of it depends on how organizations culturally see where they see these decisions made or how risky they see these decisions being. I think your original question is where should it be included. The farther you get away from the act of writing code, the type of product we're making, the type of organizational context we're in, puts more weight on the context.

I solve process problems, Yana, the same way that you'd solve design problems. Asking what the right process is, is asking like what the right design is. You can't answer that question without talking about its customers, its users and the purpose of the product. The same goes for process. You can't answer the right process question without talking about its context too. That said, there are some common patterns we should talk about that make things go better. But I think we're far from finding a right answer just because the process we're describing lives in so many different contexts and there's, probably a lot of right answers. Maybe the first thing we're learning is there isn't a right answer.

YANA:  Do you believe that it's possible to create great products, meaningful products that people love to use without a design process in place?

JEFF:  Yes, that's the scary part. What do you think of that when I say that, Yana? Is that a scary thing?

YANA:  Yes, it is. If you said, "Yes," it's possible.

JEFF:  And even worse, it happens an awful lot.

YANA:  Yeah, so what are some things that teams take into account that leads them to create great products and experiences?

JEFF:  The thing is I don't know if it's teams. When I work with organizations, I made a joke years ago that the product you're building or we talked about a product is a FUBU product. Are either of you guys old enough to remember a clothing brand name FUBU?

YANA:  I don't.

NOEL:  That doesn't sound familiar to me.

YANA: Only because I didn't grow up in this country, I think.

JEFF:  Because I'm trying to remember what the years were and it may have been as long as 20 years ago, there was a clothing brand called FUBU. FUBU was started by African-Americans in New York who noticed that most of the clothing brands they were wearing were designed and created by foreign companies and European designers and they said, "We should be able to design our own stuff," and they launched a clothing brand and the brand was called FUBU, which is short for 'For Us, By Us." There's a long history behind that clothing company and the clothing company still exists and look it up online. But a lot of the best products are FUBU products. They're 'for us, by us' products. They're oftentimes conceived of, built, and initially designed by the person who has the itch and is scratching their own itch.

Now, that works to start with when you're building, you don't have to be very user-centric. You don't have to understand users and understand their problems when you are those users and those are your problems. In that kind of context, a craftsman builds a tool that is fit for their purpose. A lot of products spin out of that. But the challenge starts to come when a product is, is something you put out on the market, you sell it and the product's job isn't just to make people happy, it ultimately has to earn money and sustain the organization that made it.

An organization tries to sustain itself. Now, it has to worry about sales and marketing. Now, most organizations have a goal to grow themselves so they have to grow beyond the boundaries of the people that the product was originally built for. Now suddenly, we've got people building products for people they don't understand. Furthermore, we've got to build more software and now, we've got to hire a lot of people that aren't that core-founding team -- people that don't understand the problem they're solving, that don't understand customers and users. It's not a FUBU thing anymore. That's when we start to add process.

Yana, tracking back to your original, I think it's possible for teams to do that but it's only when they accidentally do a lot of right things, when they accidentally have deep customer empathy and understanding and they've got some people, whether it's explicit or accidental, have a little bit of a design sense and understand what it feels like to use a good product.

NOEL:  I like the phrase, 'accidental empathy.'

YANA:  Accidental empathy. Can we push it on everybody, please?

NOEL:  Yeah. That sounds like the name of a consulting company somewhere.

YANA:  I like it.

NOEL:  Would you say that one of the goals of process then, in that case is to be able to replicate a successful outcome?

JEFF:  It is. I think you both work in a consulting organization. There's the two by two that some consultant will draw about being conscious or being deliberate about something and being competent at something. If you draw a two by two where the bottom side and to the right is 'we're conscious, we're deliberate, we know.' Then the top, 'we're good at it,' and the bottom is 'we suck at it.'

Now, we get a bottom-left hand quadrant where, 'we don't know, we suck at it and we don't know we suck at it.' The top-left hand side, 'we're good at it but we don't know we're good at it, we're unconsciously competent.' The bottom right hand side, 'we suck at it and we know we suck at it,' and the top-right hand quadrant, because we're always trying to get high and right on these types of drawings is 'we are good at it and we know we are good at it, we know why we're good at it.'

We spend a lot of time as, I see organizations that suck at product thinking and suck at UX, they're in the bottom-left hand quadrant, we're trying to move them to the bottom-right hand quadrant. We're trying to help them understand you suck at it and know enough about it to know why they suck at it. Then, we use process to put good things into it so that they can get better but what ends up happening is there's a U-shape. If you look at this drawing, if you've been drawing along with me, a lot of organizations that are founded and are successful, start by being unconsciously competent. They start in the upper left quadrant and then as they grow their products and they expand their market, they drop down into being unconscious and sucking at it. Then we move them to the lower-right and then hope to move them to the upper-right.

YANA:  Wow. Jeff, all of my problems that I've experienced in the last eight and a half years, you just described it in this little box so thank you for that.

JEFF:  You're welcome.

YANA:  You put everything into perspective for me. Revelation! That's awesome. Do you have a name for this little diagram?  

JEFF:  No, I don't.

YANA:  Did you just make it up?

JEFF:  No, I did not.

YANA:  Did you just improvise?

JEFF:  It's one of these things where there is the Four Stages of Competence. "Gordon Training International by its employees in 1970" Oh, it's been connected to Maslow's Hierarchy of Needs and I don't why that would be connected to that. Anyway, if you look at Four Stages of Competence, that will give you a little bit of history on that. They don't draw it just the way I drew it for you. They draw it as a pyramid there but they talked about these four boxes. I draw it as a two by two.

YANA:  Let's say there is a young team or a person, a UX professional who was hired into a company, whether it's a tech company or other kind of company, that probably is doing something well so they're in that bottom-left quadrant where they're fairly successful but they are unaware of what goes into creating that successful product. What are some --?

JEFF:  So that would put them in my drawing in the top-left or kind of in the middle. The thing is if it starts to move them towards bottom-left. They wouldn't have hired a UX person if they wouldn't recognize a little bit of incompetence in some way. I have a feeling that it's hard to precisely put everybody in the same place but if they've been successful to some degree, then they've got some unconscious competence there.

YANA:  Yeah, what is some advice that you would give to that person who just started at that company? What are some things that they should expect some challenges that they would need to overcome to move up in terms of the competence level, in order to move the company up in terms of the competence level?

JEFF:  I think, you just asked me about a newish UX person where the company doesn't necessarily understand the value of user experience. Is that right?

YANA:  Uhm-mm.

JEFF:  It is funny. There are some organizations that I worked with where UX is well-understood, it has a strong presence and some organizations, it's common to see a user experience person on every single team or at minimum, you see one UX person to two teams ratio. Those organizations that in general, understand what UX is for and there's a lot for those UX people to do.

But if you're a UX person working alone, maybe the first don't do is to try and lecture people about what they don't know, if they are unconsciously competent. You know, I talked to founders of organizations that know they started their company without UX people and know that they've been very successful in the past without having UX people so when a UX person comes in and tries to explain to them how they will suck if they don't have UX people, they have anecdotal evidence, at least that that's not true.

It's funny, I tell them to read a book that I own and have never read before. That's from Leah Buley. Her book is 'The User Experience Team of One.' I've talked with Leah a bunch of times and I've known Leah and this is part of the reason I have it on the shelf and haven't necessarily read it because it needs to be looked at but she said something once to me in passing over a beer that user experience isn't a product that designers produce. User experience is a process that designers facilitate.

One of the challenges with the user experience is it isn't a thing. You can't throw it over a wall. Every single person working on software does something that helps move it forward or sets it back. That strong user experience today should be, ideally at least the way I'd like to see it, is more team-centric. The way an individual user experience person can start to help is to start to move people towards competence, help that user experience person doesn't deliver good design, that user experience works more transparently. Tries harder to get teams involved with what they're doing, actually leans on the team for feedback a little bit more, whether they really need it or not. But a user experience person working alone in an organization that doesn't understand what they do has a job of educating people and nobody wants to be deliberately educated, especially if they don't think they need to be. There's a little bit of clandestine education going on here.

YANA:  On the point of integrating with the UX person to integrate with the development team and to create that form of transparency and to make the whole process or the creation of a feature, let's say more transparent and collaborative. You know, we've been experimenting with some methods here within Table XI to make our design and development practice more integrated. When it comes to assigning design cadences within a sprint cycle, is that something that you would advocate for, like to increase that chance of collaboration and the transparency to actually set up some specific cadences for UX folks to do during an agile cycle, just like development does?

JEFF:  You said set up cadence and I hear a little bit of a process. I hear a little bit of structure in that. But there's an interesting thing where all process or all structure we put in is a little bit of a hoax. Let's put it this way. We can all come up with examples of companies, of people, of organizations that are really effective at what they do but if you try and watch what they do, they don't seem to follow any prescribed structure. They seem to improvise a lot.

An old friend of mine used to say that experts don't follow rules -- the rules are there to turn beginners into experts. That doesn't mean we don't need structure, we don't need process, we don't need rules. We need those rules there in order to up people's confidence and then to let go of them. When you ask me a question that starts to feel a bit like that, I'm thinking, we need to be somewhat prescriptive in order for people to build skill. It's not individual people we're talking about. It's team competence we're talking about. But then, I find that the very best teams relax or let go a bit of formality there.

YANA:  The reason why I asked that question is looking at the competence scale that you've chatted about earlier and moving a team or a company up that quadrant to become consciously competent and really good. Starting with somewhat of a framework, so to speak, like a cadence...

JEFF: Yes, that helps.

YANA: ...until the teams get into the groove and the team dynamic really builds where they can become more independent and they can in turn start to innovate on their own. That's why I brought it up, like my head is still in that quadrant, where we're not working at the highest potential, highest level of competence and highest quality. That's where cadences seem to help jumpstart that trajectory towards successful outcomes.

JEFF:  Yeah, the general idea is that when an organization recognizes what UX people do, there's the general 'work ahead, follow behind' sort of structure, where there's another model. I might want to draw it but let me come back to it. When we're talking about the kind of research work that UX people might do to better understand the problem and validate whether we should or shouldn't be building something and do high-level design, sometimes we see that as two sprint ahead work. When we talk about tactical design or, "Yes, we agree. We should be building it and now, let's design this thing and maybe do a little bit of validation," that's usually a sprint ahead work and the goal is that the team is ready, that they understand the design and they can execute predictably.

When a sprint comes or an iteration comes, when an agile team starts building, it's nice to have user experience work through so they're solving technical challenges, not user experience challenges. Then, there's the bit of follow behind. The annoying thing about building software is we're building little bits of a big thing. When we start putting pieces of user experience what's built in a single iteration or single sprint is some of the user experience, not all of the user experience. As we start to pile more pieces together, there's a bit of follow behind of making sure that the design still is still coherent, still makes sense. There's a bit of follow behind in testing so you generally see UX people working ahead and following behind and then during a sprint, supporting what's going on inside the sprint.

NOEL:  I've been in a couple of teams that have independently stumbled into this model, where the designers are a sprint or too ahead of the developers. It always seems to me like it's a very fragile mode, it's very hard to keep everybody in-sync. If you do keep the designers way ahead of the developers, it starts to feel not agile because you start to feel like you have less flexibility. What are some of the practices that you see that can help teams make that process more robust?

JEFF:  Let me backtrack just a little bit and talk about there's two sides of the design here. I'm sure that you guys have talked about this before and you all of heard of things like lean user experience and lean startup kind of thinking.

NOEL:  Well, you can do a quick definition for people.

JEFF:  The basic idea here is if you look at traditional user experience or traditional product design process, there was a research process that gave us a lot of information and made sure that we really understood the problems we were solving and we used the research to then evolve design. There might be a certain amount of testing of that design and then we'd go into a building phase and build the stuff. That's more traditional user experience.

But lean user experience and lean product thinking in general, starts with the idea that that big phase upfront wasn't helping us. That very quickly, we can describe our product concept or our product idea and very quickly, without doing thorough research around the problem or detailed design, we can very quickly identify risky assumptions, unanswered questions, things we should know and then we very quickly go about validating those assumptions. Basically, it doesn't matter if we're making an assumption that these kinds of customers really exist and they really do have a problem we're solving. I don't need a detailed design in order to do a little bit of research to validate that there is a problem that exists there. 

When we start putting prototypes in front of people, some of the earliest design work we do isn't validating whether it's usable, whether people can figure out how to use it. It's value testing. It's a validating whether people find value in the solution and recognize that is a solution to their problem. A lean process isn't about producing great design. Embedded in design is the assumption that we understand the problems we're solving, we're solving the right problems and that aesthetically, it looks good, easy to learn, to use, pleasant to use, things like that.

Design has, in my head has two sides. There's the validation part of it and that overlaps on the product side of things and then there's the craft of actually doing good visual design and interaction design. Some people see design as the craft part, meaning you can design something really beautiful, really sexy, really easy to learn, to use but that nobody wants. Then, there's the validation side. Does that makes sense?

NOEL:  Yeah. Now, practice is to integrate that with development in a way that feels robust.

JEFF:  If you borrow the Leah Buley quote or that kind of thinking, the design is a process that designers facilitate and if you know that it isn't the design work that's happening a sprint or too ahead, it's the work. The organizations that are doing this better make that work just as transparent. They expose very quickly, borrowing lean thinking, their hypotheses, their beliefs. I think both of you might have seen a hypothesis statement that might come out of a lean process and it's not expressed like a user story form. "As a user, I want this.. so that". Hypothesis statement is "we believe if we build this for these kinds of people that have this problem. We'll see them do this and we'll measure success this way." We expose hypotheses very early on and we expose risks very early on and then we say what's the least we could do to validate these things.
	
Validation moves start to be talking with customers and users, start to be producing very early simple prototypes and things like that. The teams that I see working really well expose those things and then start to say, "How do we get whole teams involved with doing those things?" It's common for teams to sit in on customer interviews.

One of the organizations I worked with that I like a lot is a company called Carmax. You guys have probably heard of that company before and I can direct you to a couple of articles that people at Carmax have got out there in the outside world. I can get you some URLs to those. But one of the things they do is they do interviews remotely and they use Zoom right now but you could use WebEx or GoToMeeting or other things like that and engineers and others sit in the room and Carmax has a simple process. If you're sitting in the room, they expect you to take notes and if you're taking notes, they expect you to synthesize those notes with everybody else's, whether you're a UX person or not so we expect developers to sit in and take notes. We expect UX people, we expect product managers and other stakeholders or testers or others that are involved to do that.

If you expose that part of the process, there are other things -- I suspect you guys have heard of a practice called the design studio practice or collaborative design sketching approach. Once we understand problems, that's something we do to arrive at solutions collaboratively so we expect teams to participate in those.

YANA:  Jeff, here at Table XI, we've been experimenting with some methods to integrate, design into development and along with creating some services that allows the designers to do some research and to get an understanding of what the problems are ahead of time, like who our users are, what the goals are that ultimately will guide what we should be creating for them. Those are pretty lean about half a week to a week timeframes that we call inceptions and product strategy workshops. Now, is there a new project approach or a method that you believe is critical for anyone to embrace if they want to be successful integrating design into agile development?

JEFF:  If you are starting something new, having some sort of structured approach and some sort of guidance through that is super important, especially organizationally, you are trying to up your game or trying to understand why this is important. It's having a leader or having a guide get you through that. You guys had something on design sprints before. Design sprints include something like a design sketching or design studio process. But there's a lot more structure in a design sprint and that's one approach. But there are a lot of approaches as to having a structured sort of inception and that's super valuable. I'm not sure if I directly answered your question but let me give you a warning here.

One of the interesting things, you said the word project and that's a weird word. I work with a lot of product managers for existing companies and I spend a lot of time reminding them that it's not about projects. The products life starts when the project is over. Products are a continuous thing. We often use these structured inceptions at the beginning of something big or when we've got a new problem to solve or a big problem to solve but the same kinds of thinking that goes into one of those inceptions when I work with a product company, they're doing that stuff continuously a little bit of a time because every new feature, every new capability, every correction for the product needs to go through that same kind of thinking. It just starts to be measured in hours, not days that we go through things like that.

Structuring a strong inception is valuable to organizations. I'm trying to expose their teams or their organizations to working this way and a good structured inception will help them learn, to become a little bit more consciously incompetent and move up and start to move towards competent but they have to know what they don't know.

YANA:  Sure. I have a question for you on team development. Now again, imagining ourselves in the shoes of a newly-found practice, whether it is a client who comes to Table XI, who are consultants and we will help them set up an agile design and development practice or it's a company who is looking to hire. We're thinking of a company that's not highly apt at doing user experience in the most effective way. When it comes to team development and upskilling a UX team, can you talk to me about the benefits of hiring experienced professionals and also about the benefits of even upskilling people from within the company that come from other disciplines?

JEFF:  Why hire an experienced person and why upskill the people you've got?

YANA:  Uhm-mm.

JEFF:  Hidden in your question is one of the challenges that I run into an awful lot. There are lots of organizations that are trying to get better at this stuff. There's a lot of buzz around things like design sprints, things like lean UX and lean startup kinds of things and there's a lot of people trying to learn how to do this stuff from books. I suppose it can work but it's super challenging.

I see people really struggling trying to learn how to do something that they've never seen done before. If I go all the way back to agile development, I was lucky enough to start on a very pure agile team and I know what it looks like and feels like and what it doesn't look like and feel like. I've got this mental model that helps me both teach and coach people towards that ideal. I'm sure that you can get there but having an experienced guide helps you go a lot faster.

Now, when it comes to this stuff, when we talk about what contemporary design and product thinking looks like, most organizations don't have people that are already competent. One of the other things I see them trying to do is to hire competent people and they're just not that many out there. The best organizations work hard to cultivate, to grow those people internally, to see it as an internal competence. Some of the best way to do that is to get them with experienced people, to get them some mentoring.

NOEL:  Yeah, I'd imagine that it's tricky if you're an organization that doesn't 
have anything like this to even recognize competence versus mediocrity, as you make your initial hires in this area.

JEFF:  Yeah, exactly. If it hasn't been a competence in your organization, you tend to assess that competency the way you assess other competencies. Organizations are... it's going to take another decade or two before we all start to understand what the thing is that we're talking about. There's been a rash of large organizations buying design agencies in order to acquire that competency. It started with the... Was it Capital One that bought Adaptive Path?

YANA:  Yup and Facebook bought Teehan+Lax.

JEFF:  Yeah. There's a way to pull in that competency and then when you buy that organization, the problem that they're left with is how do we integrate this competency and how do those people enable the rest of our organization, not how to just have a cheaper in-house design firm so we don't have to pay them so much money. I'm pretty sure that wasn't the reason for the acquisition.

YANA:  I'm curious, you have started in UX and you have been part of this whole agile movement and you have been in it from the beginning. What is most different about now in 2017, in regards to UX practice as a whole versus how it was in the 1990s?

JEFF:  You were talking about the 1990s and then into 2000s, it's funny that this discussion wasn't supposed to be about that conscious incompetence thing but it starts to kind of frame a lot of what we're talking about. In the 1990s and into the 2000s, if we look at UX practice, UX practice was constrained or framed or UX people saw themselves and their process as a step in a bigger process as, "This is where we do the UX and now we hand off to people to build it." UX process in the 1990s and into the 2000s was sort of optimized around doing that step well and doing it effectively but the result of that step was a design to hand off to somebody who would build it.

Now, I'm sure that there are people that are listening that might have been working during that time and they might say, "We didn't do things that way," but it's easy to go to books and go to what was taught in universities and they look at a design as a phase. Contemporary design today is integrated. It's knitted in. I know that when I was talking at UX conferences or HCI conferences and things like that in the early-2000s, I got a lot of people pushing back saying, "You're dumbing down our practice," but now, the types of things I was talking about and we were talking about in early-2000s is now seen as best lean practice.

NOEL:  Having been a developer for most of that time too, I would say that one of the hallmarks of the agile processes in general is they take things that are hard, that you were originally doing infrequently and make them something that you do continuously in smaller steps. I see what you're saying as being the application of that concept to design. We started with design being something big that we do in discrete steps and we are moving towards an area where UX design is something that we do continuously in smaller pieces.

JEFF:  That's right. Part of the constraint for UX people was there weren't enough of them and they couldn't do it continuously. What UX was, it wasn't well-understood inside their organization. There weren't enough of them, they couldn't do it continuously because their organization saw the work that the designers did as the stuff that we did to get detailed requirement so that development could move on. Organizations, as a result of agile process, they don't work that way anymore.

Now, what's happened also if I look at the early-2000s -- we talked about this earlier in this conversation -- the agile people didn't understand what user experience was or a good product thinking was. But now, it's 2017 and when we're recording this, the cool thing now is even the agile community has moved to a state of conscious incompetence here.

I was exchanging messages back and forth with a friend of mine this morning, a lady named Melissa Perry, who talks a lot about product thinking and there's an agile conference going on this week as we're recording this. My friend, Melissa runs the product track. There's a product track, there's a UX track in the big US Agile Conference and ten years ago, these weren't subjects that were even talked about. Now, there are whole tracks and lots of speakers and lots of people talking about this. Lots of people are talking about the things we're talking about right now -- how do we incorporate this into an agile process and there's still not consensus about the best way.

YANA:  But it's moving upstream on that competence scale, for sure.

NOEL:  Jeff, can you tell people where they can find you online, if they want to learn more about the kinds of things that you've been talking about?

JEFF:  Oh, yeah. It's funny. I spend a lot of my life just working and doing. You can find me online at JPattonAssociates.com, man, there are no short URLs left. Just Google 'Jeff Patton.' You'll find my website. There are some online articles there. You learn a little bit about what I do but I'm also surprised to find videos of myself in past talks I've given all over the place. I'm easy to find online and I'm easy to contact through my website there and follow me on Twitter. I'll put things out there and I'm on Twitter at @JeffPatton.

YANA:  Jeff, thank you so much for sharing your wisdom. It's been a pleasure chatting with you and I hope our audience has enjoyed this episode just as much as I had recording it.

JEFF:  It's an honor to be here. Thank you, guys.

NOEL:  Thank you.