The Rest of the Company Can’t Handle Agile

Medium for some reason thinks I continue to want to read about the demise of Agile project management methodologies for making software. My daily email has headline after headline by Product Managers and Engineering Leads writing why Agile—by which they usually actually mean Scrum, a framework of Agile principles turned into a repeatable, teachable methodology—is over.

(I am wondering if, for balance, some other designer who is heavily into Waterfall is getting a ton of headlines about why Agile is the best thing ever and will never die.)

The articles always discuss the shortfalls the authors think comes with Scrum with its short cycles and loads of coordination, but I have barely ever seen discussions of what I consider the actually most painful problem with Agile: the rest of the company can’t handle it. To put it as short as I can:

All our best methodologies to create successful software successfully—Agile, Lean UX, Outcome-oriented delivery—say that every software team needs to be in constant learning and adaptation mode, which means that delivery is now in an R&D model. But R&D is fundamentally unpredictable and most companies are not set up to live that way.

It becomes impossible to plan marketing for a launch, to budget commercials, to have an announcement for a conference, to set up your suppliers, to keep relationships with your partners, to project the ROI to finance and stakeholders, or in any way to hit your internal targets when every week or two the direction, delivery time, or the projected features of the digital product can change.

Inside anything but a small start-up, functions and departments depend on each-other and end up depending on what features and forms are on the website, and yet the software industry at all levels advocates not committing to both a time and scope of work beyond 4 weeks because predictions that include both time and scope beyond 4 weeks overwhelmingly turned out to be wrong in the last 80 years. That’s a really tough message to accept when you depend on that software. Every other discipline can deliver to time and scope, but somehow software can’t? Indeed it can’t, actually, but to truly internalize that you have to have been a software engineer who repeatedly has blown past deadlines you committed to with full confidence just a few months ago.

(Software, but see also residential bathroom remodels. I have never heard of one of those being on time and budget and on-plan either.)

It’s difficult for agencies

Now try being a digital agency, whose model depends on promising clients certain functionality by a certain date. The dance I have seen account managers do with clients to first tell them user and market research may uncover things they absolutely do not want to hear, and then that delivery of what they agree to make might have a large margin of error and thus cost (and never downwards), has been a sight to behold. But in the end, companies use agencies to lower their risk and so they will insist the statements of work eventually specify time and scope of what will be delivered — because who wants to spend money and not know what they are getting when? Most agencies will thus sign everyone in their ranks up to doing fake Agile: everything made in little chunks but with a fixed end date, leading always to overtime.

The best way I ever saw this managed when I worked agency-side was how an account manager, after a lot of discussion with the client and a number of smaller engagements where we had proven ourselves, negotiated that the client would only purchase weeks of time of a certain team. We got away from billing for finished pieces, features, screens, separate deliverables; instead we agreed together on what outcome the client was after, settled on an approach, and would follow design and delivery for it, with a lot of touchpoints to exchange progress and feedback and agree on course-corrections as we learned. We continued to work hard to keep the trust that allowed us to stay within this model that got us away from endless negotiations about milestones and estimates, while staying true to the Agile principle of committing long-term only to time or only to scope, not both—in this case, time.

And businesses that have been around for a while

Inside companies that make their software in-house, this boundary between the Agile and the more traditional parts can get especially painful if it that company has a centralized software group to make the websites and apps that other divisions depend on. This is the model you see most often in companies older than the Internet, who had to learn how to make software later; the company tries to control the unpredictability of creating software by keeping it isolated and concentrated in one place.

This boundary between the Agile software delivery side and the departments relying on features is usually a beleaguered Product Manager who is constantly trying to figure out what the priorities really are this month while also trying not to over-promise anything. They have to handle increasingly pressing questions from department heads about why this thing they need is not live on the website yet and when are we enabling this new product category in the CMS, in between having to convince stakeholders about what the latest tests and data uncovered, to suddenly have management believe your findings (without crediting you) and change direction and expecting results yesterday while the budget stays the same because budgets are set for the year. The Product Manager feel they aren’t really in charge of their product, the other departments feel they have no control over their future, and the C-suite doesn’t understand why everything is so slow and everyone is so defeated and hires another COO to clean things up.

The solution: pushing the Agile boundary up and out

I honestly believe that the only solution long-term to this is the opposite of having a specific IT department, but instead to push software-creation deeper into the company. As I evangelized inside one of the place set up this dysfunctional: “Do you think the business group inside Facebook that manages the friendslist writes up their feature priorities for the year and then submits them to a some central programming group? Sitting there, just hoping their features get prioritized over the needs of the calendaring business group, perhaps shouting louder on every call with the central programmers to get what they need? Of course not, inside Facebook everyone whose outcomes depend on what is on the website gets to program that little piece of the website with their own team — last I heard 7000 teams could push changes to the website. Do you think Spotify’s playlist recommender is a separate business division begging for time from the central Spotify programming teams? Of course not, the Playlist business group makes their own Playlist features. Yet here we are in this platform division of [this company I was working at] trying to juggle a backlog of stories listing what 5 different internal product divisions need from our web platform and asking the VP above them to please set the priority so we can exist without always having at least 4 knives in our back.”

It takes tons of coordination to keep a large digital service coherent when so many teams can push things to the web and apps, but we have structures and procedures for that, and at least it lets all the teams in the company chart their own course. But yes, it does mean a lot more people throughout such a legacy business have to learn about making software. It means that a lot of people who signed up 20 years ago to do, say, production chemistry or business admin, now due to their successful careers in management need to lead software efforts for their division and learn very quickly what difference is between an MVP and an MVT. And lot of people are instead more comfortable leaving that to a separate software group and then bitching at them.

A stunning amount of workplace friction, if not outright toxicity, comes directly from this misalignment between traditional corporate structures and Agile ways of working. It remains to be seen whether AI-assisted software engineering is going to change the unpredictability of making software or the unpredictability of what users will use; all signs are that AI will deliver more of everything per cycle — more screens, more prototypes, more code — but no AI prompting will compensate for not knowing what the market wants or what bugs hide in back-end integrations with your new code. It will remain necessary for software system creators to show their work often, to users, to stakeholders, in order to get feedback whether they’re on the right path. You can call it something else than Agile if you want, but the principles won’t change, and thus neither will the need to do the hard work inside the rest of the company to align everyone around it.

The Two Rules Of Software Creation From Which Every Problem Derives

Scrum has been having a bad time for the last ten years, and thus so has Agile. My favorite article on this is truly exhaustive about all the problems we have encountered in the last two decades trying to deliver software of any kind using these methodologies. (I know nothing about the writer, this could totally be a Milkshake Duck experience; some algorithm just recommended this insanely long post to me one day and I went “Uh huh. Uh huh. Uh huh. Uncharitable but I can see where they are coming from. Baby and bathwater but yeah. Uh huh.” It’s been on my open tabs for 4 months now waiting for me to write this.)

Thing is, I remember the before times. Waterfall, short or long. I delivered projects in those systems. In fact, the first time I encountered Agile in a company, I was new and young and thus stupid enough to not ask what that was about and thus very confused until I looked up where it came from. I remained very confused how you get from the statements in the Agile manifesto (seriously, check them out again) to the rituals of Scrum like stand-ups, retros, pointing and everything else that makes programmers so angry they only get to program 50% of their day and have to talk to other people otherwise, until I actually did some work in Agile Scrum and understood what it was trying to do.

None of the critics are offering real alternatives, just modifications of Scrum to fit Design or Product management in. I don’t think anyone wants to go back to Waterfall, but they can’t really explain why not.

I can. With two rules (which may become more as we discuss them).

It’s the two rules that actually are behind every statement in the agile manifesto. The manifesto unfortunately doesn’t name them really; the people behind it were so steeped in the problems of software delivery—and what they thought would fix it—that they posited their statements without saying why each of these things are necessary to deliver good software. (Unfortunately, necessary but not enough for success, but that we found out in the next decades.)

They are

Humans can not accurately describe what they want out of a software system until it exists.
Humans can not accurately predict how long any software effort will take beyond four weeks. And after 2 weeks it is already dicey.

That’s it. Every other problem that you have to solve in software delivery rolls out of these two major issues, I think. I may be wrong, you may need a third or fourth.

Am I going to spend time proving these two correct? No. There’s enough literature out there, most of it documenting failed software efforts in Waterfall in the 60s, 70s, 80s, 90s, to support them, and I am not going to go over that. What I will, in the next few days, is go over their implications, how they led to current Agile practices, and how they can not be ignored when you want to make things better.

If culture eats strategy for breakfast, OKRs are just the cheap juice everyone gulps down first

Six hundred years ago, in the early 2010s, I was working a contract—a heritage company that needed their website to be responsive—where I met my first digital transformation consultant. A few weeks in I found out their day-rate was literally twice mine, so I asked them what they actually did. The answer was that after all the stakeholder fluff, their actual work was to find and look every function involved in the digital side of the company, and recommend how to align everyone’s incentives for a good outcome. I nodded sagely and had no idea what that actually meant; until then I had worked for large companies with long histories and already aligned missions, or tiny research teams that were making it up as they were going along. Well, I’ve worked for very different companies since then, and I have seen the pain of mismanaged alignments, usually in large companies that don’t take the time to define themselves.

There’s this moment burned in my brain from when I was in a 1-on-1 with an organizational advisor about some of the issues that were massively, massively frustrating trying to getting good design delivered in the company. I had pulled up an org chart that depicted two departments that were supposed to work together to make good things for customers but were instead just barely pushing a few new features out.
The advisor pointed to the topmost leaders of each department and told me how they advised both of these people and thus was cross-organizationally aware.
And soon confidently added: “They have the same OKRs, right, so that is how they stay aligned.”
I managed to not fall off my chair.

Gentle reader, if, for example, the Customer Service and the Product departments share an OKR of lowering customer complaints, but CS is culturally and financially incentivized for high throughput of calls, then CS may invest in a CRM to record the customer issues but they will not really work with the caller to find the root issue and then log it exhaustively. They will just report that 80% of all issues are password-related and put in some more voice-over messaging to send callers to the chat bot on the website, while the User Research department will have to spend a ton of money to find out what customers already desperately want to tell the company on the phones every day about what they are trying to do that doesn’t even need a password. The OKR is indeed empowering every department to chart their own course—separately.

Sales and Digital Delivery may share an OKR to increase new conversions, but if the management of Digital incentivizes rapid fail-fast online revolving experimentation, while Sales is leaning into the reliable, trustworthy, solid aspects of the established brand in their outreach, the user really will end up, at best, unnerved by the difference between what they are told and the rawness of what they use, and the designers and content strategists in Delivery trying to bridge this chasm into one experience will burn out in no time from being yelled at by Sales. By focusing only on a measurable quarterly outcome that can be pursued independently, the OKR is doing nothing to align where it counts and chewing up the people in-between.

These examples are made up, by the way, I can’t write about what I have actually seen fail.

The literature about OKRs all say things like “Objectives and Key Results (OKRs) provide a framework for businesses to execute and achieve their desired strategies through simple, collaborative goal setting” and that those create internal alignment, but the alignment ends up being only about which measurements to game this quarter or year. OKRs say nothing fundamental about what kind of relationship the company wants to have with their customer beyond “let’s make money this specific way right now”. It’s not a framework that includes a vision of how that specific money-making thing fits in the long-term relationship between the company and the customer, what the values and standards are of what the company considers acceptable to offer to customers. That’s the company culture and it needs to be set and maintained separately. Of course, that activity doesn’t generate an immediate return, so that’s a non-starter these days except in some very committed companies.

Some might right now say “wait, no, a good OKR absolutely defines a quality level: if the experience or product or marketing is below a certain quality level then you won’t make your key result, and therefore the OKR implicitly aligns the product and marketing and experience departments to this particular level; they have to talk to each-other to reach that ambitious result.”
To which my answer is: look around you at the disjointed mediocre experiences from all these companies who are supposedly all-in on OKRs. Without a company culture defining a baseline of expected quality that can only be achieved when groups work together, a culture maintained from above, departments will just do what they can themselves because creating that alignment horizontally by themselves is just too hard. The alignment will stop at the boundaries of departments committing to separate numerical targets. Every department will try to achieve the key result they settle on with the tools they control: one department may go all-in for quality in their space while the other goes for gaming and dark patterns. While everyone is also loudly complaining about internal waste and separation, of course.

OKRs supposedly communicate and align strategy. Culture eats strategy for breakfast, especially if the strategy comes in as a two-line description of a numerical target. Between all the merging and slicing of companies by current venture capitalism, the corporate cultures that unify departments have been totally eroded. When the main product companies actually are tasked to produce is a higher stock price, everything else becomes secondary to that, including even keeping customers alive, even if that was a guiding principle for absolutely decades. All that is left is departmental culture, and it only takes one group deciding on a different course from the others to make the experience disjointed to the customer.

There’s no free breakfast. Aligning takes work in very large companies, and it has to come from the top, looking at what is being put out, holding it up to the company standard you have taken time to define, doing the leg-work until you know who made what and why so you can shape teams and align incentives and create the right communication channels until everyone is making their part of the same thing. It’s so seductive as management to think you just need to write a couple of goals and target numbers in an OKR format and you can then just throw it down the pyramid to “empower” departments and everything will be alright and everyone will innovate and make their best stuff. And they will make their best stuff—within their constraints, expectations, and reward structures. Aligning those is where the real management work is.

Selection

Maybe I am too deeply connected to the Lean Startup / Lean UX / Agile UX circles in London, and what I am about to say is patently untrue because of confirmation bias, but one reason I haven’t written here much is because I have gotten very few requests of the “I am totally uninitiated in UX for my start-up” kind. It seems like tech start-ups are convinced of the value of UX from the start; the only wrangling I am dealing with know is how much to invest in it.

Still, how much to invest? What level of person to get? I have complained about it before, but I think I need to repeat it: if you are investing heavily in developer talent, why are you trying to go on the cheap with a junior or part-time UXer? You seriously want to spend your investment in dev talent to make software of which you have no idea if it will function for your target population before you release it? You want them iterating on a confusing implementation of the core idea, without proper guidance and process how to break out of this rut and start making software that fits you market?

Looking for a UX Designer just based on whether they can tart up your app or site is not going to get you the best value. It may seem cheap to get an up-skilled digital graphic designer, but the value in UX is knowing the processes with which you find out how your idea is viably brought to life, which includes helping decide for whom it is, how to find out what is important and what is secondary in your product, how to track what is hitting the spot and what isn’t, what many forms on inquiry to use to get insights, and how to translate those into something to build. There is actual science, craft, and experience-based lessons to answering these questions. Can you afford not to get good answers?

I was recently asked by a founder how to screen for a good UXer if you aren’t in the field yourself. There are plenty of heuristics, and besides the standard question of making sure you find someone you want to spend 70 hours a week with, I recommended the following:

Make sure the portfolio tell stories of how the questions I mentioned above were answered by the candidate in their projects. If all you see in a portfolio about projects is wireframes and finished screens, this person does not understand what UX is supposed to bring to the table, and they were just a cog in a big machine.
When looking at the portfolio, make sure you feel a mix of both recognition (“Yes, this looks pretty straightforward”) and a sense of innovation, and sometimes even both in the same project. You want someone whose thinking you can relate to, but who will augment you and your team in ways you currently lack.

Since I am answering fewer questions for start-ups, I will probably open this blog up to discuss the practice of UX more–as much as I can working in a big agency that wants to keep its secrets, of course.

Notes From The Field: Insecurity Behind The UX Curtain

In his latest blog post, Boon Yew Chew bravely and honestly discusses the reluctance he has to use the term User Experience Designer for himself. We have talked about this a little bit more on Twitter, but there are certain elements of his post I wanted to think a little more about, and why not think aloud, right? We UXers ask that of our user-testing populations all the time, after all.

What do we know?

Much of the insecurity I read and see, when UXers talk about their advanced cases of Impostor Syndrome, is actually because we do not have a canon. There is no basic shared knowledge that is indispensable to have in this field, there are no rules and laws and basic theories from which the rest of our craft flows, really. There are tons and tons of ideas and guidelines and processes with deliverables and artefacts, but there is no underlying model that we need to know in order to do good work, and therefore there is no hook for us to hang our security in our craft on. Yes, I have studied Fitts Law and I know about the 7+-2 rule, but guess what, I almost never use them in actual practice. To the point that I can barely tell you what Fitts Law even is, and as a mobile-first designer, I actually do not even care anymore because all my targets need to be visible and fingertip-sized anyway.

Back in the very early nineties when I started studying this field, people who had been tasked to make user interfaces for their companies but felt they had no guidelines and no background, asked me if there was a unifying or basic theory of User Interface Design, or Human Factors studies as it was called. Twenty years ago I had to say no, because what that basically was asking for a fundamental theory of mind and cognition, and neuroscience hadn’t come up with one. We still do not have that in what is now called the UX community, we just have compendiums of thought like “Don’t Make Me Think” and “The Lunatics Are Taking Over The Asylum”, but a basic theory what makes a good User eXperience, statistically solid and lab tested, or even a simple process that practitioners can follow to get significantly better results? All we have is variations of research-produce-test rinse repeat, which is what all the new Lean UX or the About or Our Process pages of Digital Agencies come down to. Just look for the diagram with arrows in a circle.

It is hard to feel secure in what you are doing when what you are doing doesn’t really have strong fundamentals like, say, Medicine or even Economics. For all the flack Economics gets, a lot of thinking has been done about basic theories of what actually is money, what are good exchanges, or on capital and work. And it may often have shaky predictive value, but the field can at least talk about models and predictions, something UX as a discipline can not. I remember work done in the 70s and 80s–I even did my thesis based on some of that–about systems to tally concepts in a command-line User Interface so as to be able to predict whether it would be easy or time-consuming to learn, whether a user would be fast or slow in it. That work has now completely fallen by the wayside in the larger practice of making web pages and mobile apps. Can I call myself an Economist without being able to explain how Marx saw the relationship between work and capital? Not very credibly. Can I call myself a UX Designer without knowing the inventory of ways to visualize repeated data sets as explained by Tufte? You bet. Many UX Designers have no idea what happened before 1998, and rightly so as there weren’t learnings fundamental or rigorous enough to stand even the test of time, never mind any actual lab test, in our ever changing computing environments.

Next week everything will be different

We publicly pride ourselves on how our varied backgrounds, the many routes we all took to become UX practitioners, makes us stronger when we work in teams, but it does mean that the field therefore has a lack of coherency, or even shared values beyond “we want to do right by the user”. Then the field changes in five years in some fundamental fashion, and some new people feel their current process or insight isn’t covered by the existing field and we all need a new fashionable term to go to. (I remember when Information Architect first popped up. I have to admit my first, and in hindsight vicious, first thought was “Card sorting as the whole of a job description. Nice work if you can get it.” And then it took off and I had a new title to collect. And yes, I have seen the error of my ways.)

Or our tools change, and because everyone is so insecure, or because they are recruiters trying to make money in a field they just walked into without any knowledge, we all pretend they are vital to have had forever. Little secret: when I arrived in the UK in 2008 from having designed and delivered sites and desktop applications since 1995 in the USA, I had no real idea what Wireframes were. I had to look the term up when I saw it in job ads. As someone who worked in User Interfaces–oops, sorry, User eXperience, there was one of those shifts again–from a software engineering background, whenever I had an idea or a design for a UI I would just code it up and see if it worked. At most I would sketch on paper first. Seriously, this whole in-between wireframing stage did not exist for me, and I had to study it.

So I took some of my old work and made some wireframes for them retro-actively. Can you wireframe? Oh yeah you bet! and I got me some gigs. I have now spent considerable time working with this deliverable, but I can’t say it has advanced my thinking or my results beyond my pre-2008 process. Yet this deliverable has become so important that you can get or lose out on jobs depending on whether you know the exact wireframing tool in use inside the company. Wireframing as a deliverable is now less fit for purpose than ever in a world where the transition from one state to another in a website or app is the real interaction deal-breaker, which wireframes suck at demonstrating. I am wireframing in my current gig, but only secure in the knowledge that the programmers to the right of me will code up an interactive element for testing when I verbally explain to them how it will work in the flows, and the amazeballs colleague with a Visual Creative background to my left will turn our collective ideas from the prototypes and wireframes into a deliverable that does make sense to people. I may user-test my ‘frames, but only with me doing the test with the user as I know all the caveats. I am sure wireframes will fall out of fashion and be replaced by something else (please!), and then recruiters and hiring managers will talk as if Everyone Has Always Done This In Our Field about the new thing.

We are about tearing ourselves down

User eXperience Design is the art of making things that are so blindingly obvious everyone wonders why this would take longer than an afternoon to come up with. Everyone except the people who made it, that is; they know how they went through iteration after iteration. And the only way to do it by constantly exposing what you sweated over and thought about, to ridicule and scorn for being too difficult to use, in user tests. User testing in all its forms is all we got, and we have to do it, but as a practitioner it is actually not that fun to have to go down in flames repeatedly. In front of your colleagues. And manager. Who may not understand that this is what the current UX Process requires, because we have no models to work to, and you end up wondering if they are wondering why they are paying you if you can’t get it right the first time already.

We end up in the strange position where we have to advocate to the organization to make resources available for us to find out how bad we are. I once, at a start-up drinks meet-up, explained this process to an accessories designer. She couldn’t believe her ears and didn’t think she could have gone through with it. Throwing yourself to the wolves in public every time? “Well, yeah, kind of. You never get it totally right on the first try, and there is no other way to know which part you got wrong.”

So yes, when you can’t get full buy-in to make proper testing happen–we have no time, we need to get to market, this is so simple, we’ll release it as a beta, it’s Customer Development, we have no money, can’t you just make it simple the first time?–sometimes it takes having to be in a UX community to remind you that you must still test somehow. It’s easy to let that slide. I have raised plenty of eyebrows by judgementally proclaiming that “If you are not user-testing your design, you are not doing UX, you are just doodling” but even truly believing that I have to sigh hard and steel myself before every time my designs will be seen by fresh eyes that have instant opinions about everything. How hard we worked, in the end, doesn’t matter, just the result.

We don’t really do this in the best circumstances

Even though I try to explicitly style myself humbly as a co-designer–“I am not a guru. I have done research but I do not know everything about this field. You in my team are the experts, and have lived with your ideas for a long time, longer than me. I am just a conduit to take all your ideas and shape them into something usable by other people in your field”–instead of a designer expert sent from heaven, I still end up in many situations where I feel “I should have seen that coming.” I was talking to some very respected colleagues today about a situation where I, with the team, after a week of sweating over some interactive function, collating all ideas into this one workflow, got shot down on a phone conference at Friday 5PM with a remote division manager who had a far simpler idea.
–“And of course now I am thinking, he’s right, he’s just right. And wondering what he thinks of me that I as a so-called User eXperience expert didn’t see that solution myself.”
And my friend correctly says: “He could only see that solution because you made an artefact that showed him the problem.”
–“I still should have come up with [that simpler solution] myself while making the artefact.”
“So why didn’t you?”
–“I was too close, I guess,, too enmeshed”
“Exactly, and he was far and gets to see this once a week. You need distance for these insights. We don’t get the time to take that distance when we are on a project.”

And in reality, especially inside Digital Agencies, the client doesn’t want to co-design all that much with you UX expert. They want to give you some knowledge and then have you show them a solution like you promised you would in your tender, for that specific amount of money. Innovation? As long it fits in that one week you budgeted between research and wireframing the home page, and by the way, budget is shortened because the dev team says they will cut more, so that week is gone, just come up with that Wow-On-The-Richter-Scale (actual client quote) while you wireframe. Digital Agencies work best when they have a close, iterative relationship with the client, but they only get that when they prove themselves in the first project which, guess what, happens with the agency frantically trying to find out what the client knows so deeply it actually can’t articulate it to outsiders, and only getting to it by showing designs to the client that the client will initially be unhappy with. Client churn is basically a given. It’s only if you have a stellar Account or Client Services manager on board, who can make the client understand this is how the process works, that you get a second gig.

It is really no wonder that we are so loyal to, and count ourselves lucky when we end up in, a business or even division that truly puts the user first, over profit or retaining the client: the people running them know what we go through.

What we end up with

So, we don’t have a truly shared body of knowledge and predictive theory to feel secure in, just an ever-changing field that keeps making stranger and stronger demands on us as the devices that provide user experiences explode and span the gamut from whole walls down to wrist-watches. Our job, when we are allowed to do it in a way we consider right, is about breaking our own hearts and having our babies killed in plain view of everyone in our teams and labs, repeatedly, until we get it right already. When we don’t get the tools to do this process, we labor under the knowledge we are probably making utter crap, mediocre at best, unless our colleague at the desk next to ours, if we even have one and aren’t the lone UX designer, will be brutally honest when we let them take a look. We are surrounded by people who have opinions and of which most think just making the right pixels prettier will solve everything. There is constant in-fighting in our field about what it is we should know (coding? visual design? taxonomy management?) mostly by people who don’t know one area and thus need to be heard saying that the area is not necessary lest they end up without a job. And we hardly ever have the luxury of time or space or variety. It’s not surprising we often end up measuring victory by getting one little good piece of innovation included in what is yet another mediocre site. It’s basically what Dribble was made to showcase.

It is also not so surprising then that many UX designers can hear themselves asking their friends and colleagues “Am I really a Designer? Am I a crafts-person? With no theory or real process? And if not a Designer, am I the best UX person I can be? Can we all do better? Is this new book / pamphlet / site about ourselves / process / intermediate step with pretty pictures going to be the key to stop us from flailing and make us get to good results like an arrow?”

Honestly, I wouldn’t sweat the name and field much. That you care about making software and services a little less heinous to use is what makes you a UX practitioner. Document your ideas and solutions into a portfolio, go to some workshops and meet-ups, and most of all, talk to other UX practitioners about the work. If with all that you have enough of a story you can get someone to pay your bills doing the UX work, then just call yourself whatever is in the job title for a while.

Every job, every field is a racket. We are all winging it, from brick-layers to CEOs. We might as well then wing it in an area we love.