How to get a good website after your AI Binge (part 2)

In Part 1 I laid out how this effort to get away from the confusion and cruft on your site has to start with

  • empowering someone / team to create and maintain a coherent website,
    • or if that person already exists, like a CPO, to remind them this is part of the job, and also
  • doing the hard work of formulating what quality looks like or how it shows up in metrics.

Next follows a set of steps that have worked in previous instances of doing this kind of renewal.

Recommit to your customers and how you can truly help them

So before anything, you need to have a vision of what you want to be for your customers. Jared Spool has written very clearly about what a vision is and what it must do and how to get there, and it starts with the question: What does the ideal experience for our users look like?

This means that you truly need to know what your customer’s life is like, and what their pain-points are. You have to do your structured research of who they are and what they want from you and what they dream you could do. Because you don’t want to just listen to a set of feature requests from your biggest clients and end with a vision of a faster horse.

This vision has to include:

  • An overview of who you want to target. This can be personas, descriptions, actual customer profiles, but somehow you have to make these people come alive for your teams. They may think they know them already, but if your teams truly did, why is everything on your site so hard or unclear or old?
  • Their pain-points, both as a context of using your service, and while using your service. What are the trying to achieve in the wider world?
  • What you want to be for them in the future.
    • If you have ambition and capability, you could paint a whole dream scenario target of how your new efforts truly improved the lives of your customer. Sit down with customers and creative people from your company and imagine how the currently toughest problem for your customers would be solved as if by magic by your company.
    • At the very least, describe what you want your customers to feel and experience when they use your site, what kind of relationship you want to have with your customers on a brand level and a site level.
  • A very rough outline of what kind of platform you want to be for your customers. No too detailed, because your teams need to be contribute their knowledge and experience to make this all better.

Making that vision

Normally you only need to make that vision in companies or divisions that have lost their way from the original founding culture leadership had in mind when they set the company up; companies that have a lot of legacy as a result of time of M&A or that have pivoted once or more. But you may also need it after having been in experimentation, learning or sheer survival mode for too long, AI-driven or not.

Whatever the reason, if you have to right a wrong course, it has to come from as high as possible. The C-suite might not have time to get involved to develop a vision of how the website works in the future, but the layer below will have to invest the time because in the end, getting back on track requires a culture change and the C-suite sets the culture, so they need to buy in to the point it looks like the vision comes from them.

The best version of this I have seen did involve an outside agency, but the cooperation was carefully designed for the outside agency to be a catalyst, not a supplier. The agency did not gather all input, go off for a few weeks, and return with a deck of advice; that model I have seen have zero results too often. What I have seen work is an agency working with the highest level stakeholders they all could have regular progress and work meetings, multiple times a week, discussing who to interview, what sources to consult, how to divide the work between agency and client, working together on gathering information, going over responses and results, constantly putting things in context, strongly benefiting from the outside POV the agency brought to question everything, and working towards a vision together with constant iterative feedback so that nothing about the final vision is a surprise to anyone. The storytelling about that result, however, was at the highest level like only a good digital agency can do.

You definitely want this done by the highest level management that has the time to do this, and keep the layers above involved. They should make the time for this because this is the future of the company, after all.

If only one part of the digital experience needs this refocus, it is OK for that part to take the lead, but they have to involve and consult with all the parts contributing to the digital experience, or resentment about being left behind or not joining up will build and infighting becomes a possibility, tanking the investment in the vision. I have seen this happen first hand, and the fact that the strife was petty AF somehow did not seem to deter grown adults from engaging in it.

Inventory

So now you know where to go. Now you have to look at what you got and make a first improvement. In practical terms: you have to inventory everything to know what to cut. And you do have to cut. Or merge. Or redesign. And all of the above.

You need to map out all the journeys a user can take through your site, together with:

  • stats of how often they are taken,
  • how users feel about the steps,
  • and how they succeed or fail.

This is simple journey-mapping, but if you never did it or have not kept your maps up as changes were made to the site, whatever you have now is outdated and the totality of your site now only lives in a few people’s heads. And without them you simply cannot make good choices. You have to be able to put them all together so your team can see where the gaps and the issues are, and also so everyone is on the same page of what it is that that can be done and how on the site.

Having this mega-map will also help onboard new stakeholders and seniors much faster, so there is a secondary, monetary benefit to making and maintaining it. And if you really can’t swing it for your whole site, at least do it for the top 3 to 5 key journeys on your customers over their lifetime.

The second thing you want out of this exercise is agreement about what the basic concepts in this service are (also known as “the mental model you want the user to have of what you offer”):

  • the objects and ideas you offer or sell to the user, that they need to interact with and keep track of to get to success,
  • the actions a user can take, most often seen as steps or transitions in their journeys,
  • the visual items they interact with on the screen, like profiles, settings, shopping baskets,
  • the names you want them to use when interacting with chat prompts or visual controls like buttons and links to next steps in the journeys.

This is where you need to involve stakeholders and product teams for each area, just to surface the different viewpoints on all these steps and objects, why they exist, where they originate from, what they cover, and what differences are between similar concepts. Skipping this step to “hit the ground running, trial innovations” gets very expensive in the long run: confusion will be endemic in the project teams and users, and the simplifications after take longer than if you had just started out with a known, curated list of what is what.

Simplify

During your inventory you or your team already noticed duplicates, or worse, not quite duplicates: concepts or journeys that are almost the same but not quite.

Now that you know in what direction you want to go, you can actually, with purpose,

  • group similar items together, and that can be several groupings: by journey, action, goal, page, etc.
  • merge items (concepts, pages, journeys, visual constructs like icons and images, actions) that are either duplicates of each other or need only small changes. You want less of everything.
  • cull items that confuse, distract, annoy, or users simply do not easily glide through,
  • make peace with the fact that there’s always going to be a category in any categorization system of oddities and exceptions.

This is now a first practical step your teams can get to work on that will visibly improve the experience and have pay-off in faster future development.

Get your foundations right

Consistency

Go through all your content and fine-tune it to only use the concepts, journeys, branding, visual language, and names you settled on. Make sure you stick to what your vision needs to come to fruition; don’t just work to get everything right now, but work towards the future.

You have to document this. Online, internally, describing these guidelines so new creators in your company can be on-boarded quickly, and future output stays on course. The “new creators” here include the LLM AIs you will set up to review your current materials and help you review new output for not being on-brand and on-guideline. AIs absolutely shine at this work of comparing one structure to another.

In practice this means that your workflows now have to be retooled so that anything created for your website or app goes into central places for the AIs to help flag compliance. All imagery, all content, all video, as a step in getting published. This can be in directories, the CMS, repositories, but they all have to be known and monitored. Very often these workflows are about your designers and programmers giving their AIs prompts on what to make, and then having other agents check for compliance and validity when the work is added to repositories. It should also include a stage for a human to check the results. You end up with many teams working more or less together, but subject to a consistency step to align everything.

Design System as a marker of collaboration failure

These guidelines sound remarkably like an expansion or completion of a Design System, and they really are, serving the same function of speeding up production while maintaining ease of use. Except this consistency is not just at the visual level, but at the language and conceptual level, minimizing what cognitive objects like brands, languages, actions, journeys the user has to keep track of.

In theory, implementing and using a Design System already has given you the experience of how to maintain consistency and speed up production. But you have to be honest, did you really fully implement the Design System? Did you empower the DS team to enforce using the DS, including updating the old code? Or maybe make a junior FE engineer available to systematically transfer the codebase to the DS, even if it took 6 months? Or did you just hope the DS would be used by developers moving forward and that old pages would be updated to use the DS when they got touched (which ensured the oldest and most stable flows would never be updated because nobody ever touches them)? There’s a ton of DS managers burning out because they are now made responsible for DS outcomes they have no authority over, and now the DS is one of five sources to be synchronized for every brand update instead of the only one.

If you didn’t get the balance of responsibility and authority right for your Design System creation and management, how is this new push going to work then? How are you going to make it sustainable? How will you keep it going?

Show a pilot

Before I go deeper into the issues with collaboration that are the real problems holding back a tight, solid offering, a word of warning: it will be around now that your main stakeholders like your CEO or CTO will complain that they spent a lot of money on agencies and time and haven’t seen anything breakthrough on their website. This level of stakeholder, unless from a design background, doesn’t see the value in creating consistency and getting rid of cruft as a preparation for new, considered functionality. They just see the bill from buying a vision and doing first alignments and no new 10x lines going up anywhere yet.

Suggest a pilot for the vision: a project of limited scope that illustrates one or more aspects of the vision, and a time-frame for it. Get input from the teams currently working on those pages or features about how long things take, what the workflow really is, and what is on their list to fix anyway. Then choose carefully with your Vision project team what will show off the direction the best in the time that you have. Maybe it is updating a section, a complex journey, a big piece of the navigation. If you can, do more than one piece.

You need to deliver or your career is internally over. Once you deliver and the internal forces start understanding what you are doing, make sure to credit their backing and wisdom. They will not understand from this pilot the full extent and ambition of the vision, but you have bought yourself time.

Fix your collaboration architecture

Why did your UX designers let it get this bad? Weren’t they in charge of the experience? Weren’t they running the Design System? How did they let everything get so fragmented?

Again, look at your product teams, look at the flow of features from ideas or requirements to screens or devices, and then answer: who has the power in that chain to say No? What mechanism was there to make sure new features fit what research said was what users struggle with? Ever since the lean product discovery team became a way of life inside companies with their squads (or domains or tribes) and their product triangles of product manager, design, and one or more devs, the designers did not get to say no anymore; it was either the product manager who made the final calls, or decision making was split between the three with a strong bias to having to deliver something, always, and telling Design that the obvious gaps would be fixed when iterating to version 2, after the MVP ‘won’ and would be committed to. Don’t blame design for something they had no final authority over.

(Spoiler: in 90% of all SaaS, the MVP ‘winning’ meant that it never got retired or enhanced but that the product team got put on another gap identified or idea from the CTO or CEO or other initiative that had to go live in a ridiculously short time-frame to keep up with the competition. The words “Version 2” are just by themselves a bitter joke inside UX.)

As I noted in Part 1, this wasn’t the biggest problem until all the Copilots made it so easy to throw things out there over and over, and since every team is incentivized to succeed by themselves, they tried to. The operating framework in which your teams deployed their autonomy is missing a few pieces, like:

  • A reward framework that rewards more than Line Go Up. If you just have one main goal, like say x% conversion / sales / increase in usage so you can increase pricing, that one goal is what the teams will game. If you want to get away from that, you’ll have to look at your digital offering and ask yourself, what does quality mean in this system? What does it mean for the user? Do we care about lifetime value? What will get us the customers that are now asking Claude how to solve their problem the easiest and are being sent somewhere else?

    This is if you believe that investing in a streamlined, consistent, simpler experience gets more customers. It may be that simply lowering prices and keeping good inventory on an average experience (the ALDI / Lidl model) is all you need. But if you believe or can prove that a quality app or website is key, you will have to start rewarding your employees and contractors for delivering that quality, and discouraging anything else.

    If you want to express those goals as numerical targets, make a basket of them, and apply them all to everyone so all teams take on each-other’s concerns and make a joined-up experience. For example, let’s say besides the standard increased sales target, you are also setting a goal of lower customer support costs and fewer returns, to get that incentive of a better online customer experience going. But if only the customer support department is made to care about customer support costs, the website will never get that simpler login that could fix 70% of all support calls because the website sales team is too busy making a bigger Buy button to hit the sales target; the customer support department will just be told to outsource better. Joined-up outcomes only happen when holistic thinking is rewarded.
  • A proper empowering of the glue people. Find your glue people in your organization, especially the ones being approached by multiple departments. No, it is not your Product Managers, they are supposed to be interfaces that talk to outside divisions as part of their mandates. Ask around: who has frequently contributed data, insights, ideas, details from an unexpected source outside of the team? Who in the team often gets called by other divisions for insights into how the digital side works (which means they are very well trusted)? Who recently made sure two different digital areas aligned?
    (If most of the people in question turn out to be women and/or minorities, you have a culture problem, BTW.)

    Once found, ask them why they are having to be glue people, because often that is not their actual job. What walls between silos are they trying to puncture? What information about business processes in other divisions, or how users are using the online services, or other insights from various areas, is not being shared but for them? Why do people reach out to them to pass on information between groups or find out how things really work inside digital teams?

    Find a way to formalize this information exchange, but not through meetings and reviews. In a large or fast-growing organization, details of how your product or service gets produced and delivered need to be as widely spread as the clarity on who your customer is and what their actual problems are.
  • Decentralized programming. I’ve written this before, but I am repeating it again as part of the solution: if your product or service is sold or delivered over digital, every division of your company that contributes to those solutions needs to have their own teams to put their part on the website. No more jockeying by various business divisions about “when will they get time from the web team” to put their ideas on the website. If 70% of the customer support calls are about the login experience, why can’t the customer support team fix it themselves?

    But didn’t I just advocate for centralization and gatekeeping? Yes, to fix your current mess. After that you need to get to a model where the local autonomy for new ideas and improvements live in harmony with a centrally-supported drive towards clarity, simplicity, and consistency, all in the service of being customer-oriented.

Make a platform for the future

The vision you made tells you where you want to go. You have simplified and streamlined, cut down, removed, built up, written guidelines, created workflows that support re-using the guidelines and the Design Systems, and there’s a person or people trying to make sure everything works together smoothly, while you are also empowering more teams, closer to their stakeholders and their customers, to contribute to the system. What is the goal here after that?

The goal here is a place where there’s a framework of real customer-centricity. Whether it is a new culture that proudly refuses to release anything that does not hit a certain quality mark or does not make the user’s life remarkably better, whether it is a framework of OKRs that doesn’t allow for simple optimization gaming, whether it is a structure of rigorous testing and assurance that even experiments adhere to coding, security, and design standards, you have to create that sandbox.

You want to end up in a place where many can contribute and experiment, being enabled by central guidelines, frameworks, and workflows, supported by AI, that create the security that even the tiniest team trying to get something out for their small group of customers, can design and deliver it quickly and effectively, up to the cyber-security, coding, and design standards set by the company experts in that area. This means that central teams of experts create the sandbox everyone can play in, guided by the company goals and the supervision of the product executives. And yes, the sandbox can have corners for disruption and experiments.

But “let a 1000 flowers bloom” and then end up with 7 half-working competing or retired systems is a huge waste of resources, burns out workers who feel useless or in constant competition with each-other, and hostile to customers—but it sure makes the VPs responsible look like they are “innovating” while they happily get to ignore any details and get away with making no choices. It’s been done and now with AI speeds it is making companies release features that are empty, cloying, and code-wise grossly insecure. The only reason Google survived that is because their ads make so much money.

The reason any start-up eats incumbents’s lunch or opens a whole new category without incumbents is because they have a vision and a culture and they stick to it. Even if the vision comes after a pivot, they stick to their directions and put all their resources into that direction, with leadership that will curate the offering towards a goal. Any company can do that if they have the leadership with the guts to get stuck into details and take bets with enough direction so designers and developers can focus, even in traditional companies now turning digital. But you have to stop treating the digital arm as its own contained department you can look at from a distance and occasionally yell ideas at.

If you’re the CEO of a media conglomerate and you only find out from an external source that the search function on your main delivery channel, the website, is hard to use and hasn’t comprehensively searched your database for years now, you’re in the wrong job, because how your website fundamentals work aren’t minor details anymore you can just “leave to the IT boffins”. If you’re a CEO of a SaaS and your users are disappointed by the experience after purchasing a subscription because it is so much dowdier than the ads and funnel that got them to subscribe, you’ve lost sight of how you serve users and how your tech teams are unbalanced and half is in the dumps. (Both are actual examples I lived through.)

Your website and apps are not an afterthought to the amazing Big Deals you fly around the world to close. Linus Torvalds managed thousands of external contributions to the LINUX code-base but through his vision, tastes, and help from his closest colleagues still kept his product coherent, stable, and on-track for decades. Steve Jobs could quickly communicate in a single meeting to the home video editing software team the details of what level of usability he wanted so as to get them going and then maintained enough overview to demand hardware and software work together and be perceived as high quality across all product lines for years. For both these examples I can give you five of competitors, sometimes huge ones (Nokia), that lost because they could not get their act towards the user together and let all their middle-managers compete against each-other, ending up with disjointed crap nobody trusted.

Everything King Midas touched turned to gold, as he wished for, but people forget the part where the abundance starved him. Gen AI may be exactly what you asked for, too, with real features being delivered at the highest velocity, but the abundance is confusing users and turning them off, and you lose them and their money. That same AI, through a chat bot, is sending people to cleaner competitors, warning them about your dark patterns, and guiding them through your offering in ways that do not allow you to bind them. And on top of that, the token-economy is collapsing, so you really need to use your AI more targeted than pray-and-spray.

Time to clean up or slowly starve.

How To Get A Good Website After Your AI Binge (part 1)

Person walking on a glowing path surrounded by many error and notification windows

Eighteen months ago I told you

We will need to know our users better than we ever have before we even start to design something, or we will flood the zone with so many bad ideas our users will run away from our product or brand at the speed of light.

But no, you went the easy route, so congratulations, your Claude-enhanced Product Manager crew have vibe-produced their way to a plethora of new features. Like a drunk King Midas your crew touched everything, hoping it would turn to gold, and now after months experimenting with new ways of creating and testing new functionality, one or two features actually have some traction. All the new features are also all over the place, distracting from core features because your PMs made them over-visible to get a new success, all of them slightly incoherent with each-other, and everything just feels… off, although you would never truly admit it because several usage lines are trending up. Your system is subtly, and in some places explicitly, over-complicated.

Normally I would only walk into this situation in companies that have existed for decades and accrued digital cruft in that time, or who have a large portfolio of sites and apps due to various mergers and acquisitions. However, when you empower a lot of people to push a lot of things live without a foundation of either an authentic customer-oriented culture that knows exactly what your users wants and sticks to it, or strong oversight structures ensuring only things that fit your brand and overall experience go live, you will end up eventually with the same kind of complex business site.

How to tell

How do you know your system has become too complex? Here are some classic signs:

  • The same action is called different things in different sections,
  • Or opposite: your system is using the same name or icons for things that work slightly differently,
  • There are a ton of concepts and items and prices and features for the user to keep track of,
  • The menu bar or footer is no longer consistent site-wide. A good CMS should not allow this, but who builds their website on a CMS these days anymore? Or your site is a collection of historical sites you never rationalized and people are just supposed to know what each brand does differently,
  • You used brand names as category names, like in menus.

We also have some more recent markers of a system that is going in the wrong direction:

  • Users aren’t taking clear paths. There’s strange backtracking in your logs, mostly because they are trying to find the optimal deal for themselves, and you added all this competing cruft,
  • It’s not easy to move backwards from an action. For an explicit example: pressing the back arrow on the browser does not simply go a step back, but throws the user into some indeterminate state, so users can’t explore,
  • Your design system has multiple brands. Maybe even the same pages under different labels.

And what I promise you will be the new classic symptoms of over-complication:

  • Your users can only get good outcomes using prompts in some text box on your site. This will be an accessibility violation in the future WCAG standards, I promise, because prompts are not discoverable,
  • Users are consulting some off-site LLM AI first how to get something done on your site.

Why fix it

The one thing the web has been exceedingly good at since it became popular, is letting a newcomer eat an incumbent’s lunch, and that has just been dialed up to an unprecedented degree.

You have the best content? Not for long. Cheapest? Smartest? Somebody wants to disrupt your whole horizontal and vertical and walk away with all the money, and they are looking day and night at how to change the things you think can’t be changed and are keeping you in business.

Now this renewal has always been part of tech, but this time AI has ramped the optimism and the big thinking up. Nothing is safe anymore to these new entrepreneurs, and many come from having done this before. They will take one look at what seems to be a complex or unhelpful path on your system and whip up a super smooth flow of their own to capture just that revenue and optimize on it, and slowly wean those customers off your proposition. The level of effort to get something out has gone down, and enough people are trying that some will actually make something so good that it will succeed.

But wait, how are users going to abandon you for just one simple green path somewhere else? How would they even find it since they already come to you all the time? Because of that same AI you are trying to stuff everywhere on your site against everyone’s will. People are using Gen AI systems a lot to find things, and these systems send them left and right for different items and actions, to wherever the AI is convinced will answer the need, without any thoughts for incumbents or loyalties. Claude will read a decade of people discussing your difficult service on Reddit and recommend another site with far fewer complaints. The concept of loyalty to one online proposition is being eroded fast, and instead users are being trained to go to the most efficient place for a single transaction. These AIs, and therefore their users, won’t care about all the other things you bring, they just want that one path, that one action done. And every one of those little shops and flows has Stripe check-out, social logins, and other low thresholds to let users get their work done and maybe keep them.

Incumbents will scoff and say this startup only has a tiny piece of the market and hasn’t dealt with the Big Problems yet, and forget that for this startup to grow for now they don’t have to fix the big problem, just eat up everything else. Alternatively, this startup has actually proven they can and will move mountains because they already moved the small hills, and thus they will change the field. There’s a lot of suppliers, including government, that love to change ‘the way things are done around here’ because they are tired of the inefficiencies and the cruft too. They’ll jump on this new proposition if it makes their lives easier or just makes them look modern and with it.

I’m a member of the next play mailing list, a community run to bring together heavy hitters looking for their next startup, heavily biased currently towards using Gen AI, and what is most amazing to read are these x-rays of startups going into forgotten or un-glamorous fields like donating financial instruments to charity or rolling back mortgages. These startups go in, learn everything about it, have a vision of how it should be in a modern age, start iterating relentlessly with a bag of money to get any foothold, and then rapidly transform that field. They just need one or two customers to buy in and let them peek behind the curtain and then they close some deals with suppliers and other formerly immovable constraint-holders, focus on making an AI SaaS suite to create scalable modern change, and start the revolution. Many of them have left the “small beachhead lean startup little first change” mentality behind and are swinging for an AI-driven primer-to-setting-spray make-over of their chosen field. You need to stay ahead of them and another feature on your site to game a KPI won’t do it.

How to do it

How do you stave off this competition? How do you, maybe for the first time, maybe once again, get to a place where your proposition is easily understood, quickly converted to, creates satisfaction, and your website can become a coherent platform for true innovation instead a of a feature fest held together by a half-implemented Design System?

The role of the Design System

Because you did invest all these resources into a Design System, surely that was supposed to make everything consistent and thus easily understood?

Even if you have designed and implemented and used your Design System flawlessly, no, a DS does not enforce simplicity, or even clarity. It only enforces consistency, and mostly at the visual controls level, maybe page templates. Few implementations will have templates for flows, and if they do, they will not be all the flows. So you can still use a DS to make a page with 50 buttons on that nobody will understand. A Design System that has been universally used is a basic necessity on a complex or large website that needs to be the platform for your future, but it is not enough.

Organization

If you really want your flows to become coherent and lean so as to be recommended as the easiest way to get things done, be a delight to use so people come back, or just simply get your more revenue by volume, you have to ask yourself the same question you do with the Design System: is there someone actually tasked and authorized with maintaining that quality?

The root of the problem wasn’t increased feature production thanks to AI. The problem is having all these teams in your domain / squad / tribe be empowered to never have to consider the big picture. Absent a deep culture of approaching the customer holistically and with quality, which is indeed lacking in most companies always trying to hit their quarterlies, these teams all retreated to the safety of trying to make some line trend up in their own area. This used to end up OK with a little steering and discussion between teams because everything took time and developers had to prioritize coding, but that was before a feature took only a week to release by a team alone.

I have bad news for you: to create lasting change, you’re going to have to actually care how your software is made. By which I mean you will have to change the way you organize and empower your teams, because your current hands-off system of kingdoms is what iterated your digital service to disjointed mediocrity and near-irrelevance. You have to change your Collaboration Architecture1: you have to examine how the teams along your feature pipeline work together, who coordinates with whom, and how to create processes and a culture that keeps all your teams on the target of focusing on the customer’s whole lifecycle, not just their own little piece. You need a person, and soon a layer and way of working, that makes teams listen to the knowledge created internally of what users want and what everyone is making and why.

Your product (The AirBnB Lessons)

Supposedly this is exactly what AirBnB did to step away from all the local maxima A/B testing created: reorganized their practices to always have a coherent product on their website. The person who took on the responsibility was a leader who unabashedly gets into every detail of the experience so they can make sure it all works together, organized disciplines together so they maintain coherency at a design level, in how they develop, in how they steer projects, etc,. only releases all new features when they are ready together, and reviews how everything is moving forward as a unit constantly.

Did it work? I can’t tell personally, because the core service is now so toxic with all its fees and scams that I would never use the service anymore. In the end, the core lesson is to make sure you have a service that people actually want at a price they also want. If you do not have that to start with, you’re toast anyway. Work on getting that right first.

No quick fixes will last

Simply changing your top OKR to include the words “quality” or “simplicity” and hope all your autonomous squads start working together to reach this overarching goal is not going to work in the absence of a culture of quality or simplicity. Holistic thinking requires giving up autonomy towards a shared goal, and thus a specific person or team making decisions about where to go. Little lean teams fighting for relevancy or budget or survival can’t work together that way. As Meadows posited in her Systems Thinking work: you can’t fix a system from inside the system. Which means the system with which you have generated your overly complex website needs to be changed.

As a first and necessary step, someone in your organization, maybe even you, will have to be empowered to look at your service holistically, but also getting in all the details, see all the flows, see all the features, and work towards improving the quality of the whole experience. This means this person or team must have the ability to stop releases, stop features, retire ‘experiments’ that haven’t made their target; just simply be allowed to say No to mediocrity or disjointedness. This person may also be a team, or a current leader working within product or design who knows what is live and gets new responsibilities and authority. You can call them Chief of Product, Principal Designer, Senior Staff Designer, Strategic Product Manager, whatever, but stopping short of empowering this coordinator to that degree is a clear signal that you are not serious and thus nothing will change. The disengagement disguised as delegation from the top of Product Management needs to stop.

Second, you will have to work out as a culture what you mean with quality, when is good actually good, what you mean with holistic and customer oriented. I have worked with many stakeholders who say “I want a great experience for our customer” and then walk away as if that edict is enough to make it happen, and it is not. If you want to actually earn the stakeholder position you have now, you will have to do the hard work of defining what a great experience is, because your teams can’t live up to your standards if you can’t even articulate them. Yes, if you are a CPO, Head of Product, CEO in a flat organization, you have to be able to say when good is good enough in ways your team can understand, and keep them to it.

And if your standard of quality is only some single numerical target being hit, just quit already, because you should know your teams will just game them and not really get better. You might get away with defining a basket of targets to be hit that can only be reached by truly improving the product, like Fewer Calls To Customer Care AND Less Backtracking On The Site AND Shorter Help Chats.

Once you can express as a main stakeholder what you want to achieve, how fluid and simple and clear your experience needs to be to survive the coming wave of hungry competitors, you can get away from that gatekeeper model. And you have to, because gatekeeping does slow you down, and it is not making that person popular so they will turn over. You also have to take a clear look at what your business environment actually looks like, what truly needs to change, and step away from short term numerical targets to create a culture of lasting renewal and competitiveness.

No, none of this is fun, quick, or free. It requires you to take some unpopular action now in redefining the autonomy of teams (and you’d better change the incentives to match, no more team bonuses per released feature or your gatekeeper will quit within a month) and some deep work in defining who you are, what you want to be to your customers, and what your benchmark for quality is. But it is either this, or a prolonged slide into irrelevancy in an environment that is radically different from a year ago; one where your competitors are using their tokens in a smarter way than Spray and Pray Features and, as we say in Dutch, want to eat the cheese off your bread.

In part 2 I will tell you what the practical steps are to get there: how to envirions, how to shape, what to keep, what to cut, short-term, long-term, to get you out of this feature-binge hangover, plus go deeper into the points above as I help you prepare for the future of not repeating the same mistakes.

References

  1. Holst, A. (2026). Collaboration Architecture: Service Design for Knowledge Work : Organisations hand infrastructure work to IT too early. Touchpoint – Emerging Service Design, 17 (2), 6-11. doi:10.30819/touchpoint.17-2.01

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.

But what if you could explore a lot of terrain quickly, and not need maps?

Why software dev is so hard, Part 1, Part 2

Testing in production is really expensive

As discussed before, decades of experience teaches us we have to show users what they say they want so we can find out what will actually work for them, and we have to do this often. So often, that we created a whole inventory of ways to find out, from ‘painted door’ for concept tests to A/B tests for more tangible experiences, to interviews with prototypes before making things, and then validation testing after making things, in small conversations for insights or large numerical samples. But as this article by Judd Antin posits, what this led to is a lot of research that tells you about features, and very few answers to the big questions of what will actually make a change in people’s lives that they are willing to pay for.

For a decade a whole industry told all of software creation to “build test measure” but forgot to give a real founded answer to build what? Everyone could see that it actually meant “throw stuff you think will work at the wall and hope something sticks”, with stuff being whatever the poor Product Manager or HIPPO could come up with from either their hunches or customer service or competitor features, while at the same time we were telling ourselves it was ever so scientific and valid. You couldn’t but feel cognitive dissonance looking at the process. Meanwhile the design process didn’t even fit software development properly anyway, see Part 2.

It is then not surprising that many Product Managers end up frustrated and thinking that they could get the answers they really need by “getting out of the building” and “talking to a few users.” They feel the real gap in their knowledge is how their users really live with their products, not whether the OK button is green enough. (“Getting out of the building” without a rigorous agenda and user selection doesn’t work, BTW: just talking to whichever target person you end up with will just enable enormous amounts of confirmation bias.)

Don’t take just my word for it; Pavel Samsonov here discusses with other examples how cyclical design and development ends up unsatisfying. Many comments on the article are beautiful examples of copium: repeating Ur Doing It Wrong without engaging with the main problem that everything about making experiences for users, from deciding what to make to how to make it, chafes for every role in the team, and has for the last 15 years.

I don’t agree with the article, and others like it, that the solution is to redefine delivering value every cycle not as making a feature or capability, but to mean learning some lesson. The problem with that is you are still using your development team to ‘try something’ over and over, but this time with the explicit assumption they will throw 75% away. A full-fledged, production-code releasing dev team is a very expensive place to learn what not to build. Among other things, it puts a large psychological toll on designers and developers who are pouring blood, sweat, and tears on stuff to then have it be thrown away in the name of ‘learning’, over and over. You also can’t explain it to the budget people who will see the throw-away as waste.

This cycle was and will remain necessary for a while in organizations terrified of Big Design Up Front or that don’t have a separate deep research capability, but it will feel uncomfortable, and the team will slowly move back from releasing-to-learn to releasing-features-to-hit-KPIs. You don’t build careers by publicly admitting you ‘are going to waste’ 75% of your dev efforts.

But the article does point to a way out: what if your dev team didn’t have to create and release experiment after experiment to find out what to build for real? What if the design and research group could test alternatives much faster, and not just one-page A/B tests, but whole realistic funnels, whole new concepts, many at the same time, without needing dev resources?

Enter AI and no-code

In case you haven’t followed UX for the last 20 years, one of the questions we always debated was whether UX designers should be able to code, and with code we always seemed to mean HTML/CSS/JS (which then implied that UX was only about web pages). The pro-arguments included that designers who could code wouldn’t be wasting everyone’s time by designing impossible pages, or, on the extreme end of the arguments, that designers who actually coded their designs would speed up time to delivery so much because there wouldn’t be a whole specification (first Photoshop, then Sketch, now Figma) stage. There’s a whole set of assumptions in that statement that I don’t have time to unpack, even from experience because I used to be such a designer-developer, but the rarity of user-experience designers who code their own designs into production says enough about how realistic that idea was.

But creating front-end web code has become a lot easier.

  • In the same amount of time it takes to become ace at Figma, you can become an expert in Webflow, a system to visually make web-pages. I can now output a static HTML/CSS front end of acceptable code quality, ready for a JS programmer to add connectivity and motion to, as fast as I can wireframe. This means I can explore about three different directions in a day, and thus three different funnels in a week, ready to go live in a sandbox for qual and quant testing.
  • I recently asked vo.dev, a promp-based (so an LLM under the hood) site-builder, to make me a portfolio site for a very specific kind of UX candidate. It knocked the full code for 3 pages out in 5 minutes, ready for me to change with CSS styling cues.
  • UIzard (also seems LLM based) is like having a (really dumb) UX Production Assistant on call, that you have to explain a lot to, but will allow you to iterate your ideas inside the tool, prompt after prompt.
  • I know one high-powered web researcher who is turning around the deepest knowledge-representation experiments, experiments sponsored by the biggest data warehouses in the world, whose outcomes could change whole paradigms, twenty times faster than he used to because he can now add a menu to a web-page to select or transform stored data as easy and fast as he can ask Claude. (The interfaces look super basic and are definitely not production-stable, but for that experimentation that is irrelevant.)

It’s now just a matter of time until the AI UX generators find their way into the no-code graphical HTML tools, with full round trips of intention between the AI and the human. Pretty soon we will be

  • describing personas and tasks and creative directions to our UX tools,
  • see screens appear as designs but also code, for us to then move and re-color and warp and remix,
  • to then be submitted to stakeholders whose comments can be absorbed into the designs real-time,
  • to then output live code directly into our A/B sandboxes or crowd-sourced user-testing systems or interview workflows,
  • after which the results and statistics get pushed back into our tools so we can tweak the designs.

This is way beyond an AI plugin in Figma, but a live continuous dialog between design, development, and testing, mediated through language, iteration, integration, and direct manipulation like in our current design tools.

The tools themselves will not innovate, their designs will be bland, but they will inform. LLM-based tool only regurgitate what they already know, they are retrospective. ChatGPT will never tell you to query ChatGPT, because ChatGPT’s corpus doesn’t include ChatGPT—but v0 does know everything about what features and paths we have been grouping together in our interfaces. The very first time I used v0 I didn’t just become more productive, but also more complete: its output included some flourishes and ideas I had not considered yet but upon inspection were actually baseline for what I was doing.

(Yeah, there are issues here: LLMs are in the same category of resource-greedy as all crypto-currency, and the big LLMs were all created by stealing the intellectual property of everybody who ever published anything on the web. This can’t be discounted. But if the latest Chinese efforts bear fruit and you no longer need the complete energy output of Wichita and the daily production of Dasani to get a mock-up web-page, plus we factor in that as UX designers we were all copying each-other’s ideas already anyway, then using them for UX design actually could become ethical.)

If a design team can prototype at full fidelity quickly, a lot of current ways we organize designing software can change.

  • We can show users many things even better than we used to, and get many comments, keeping us on track. Rule 1 is taken into account.
  • Design will outrun dev even more than it actually already does in many places, except that now design needs that speed so they can thoroughly vet what they are making at whole new levels.
  • Product and UX as a discipline will have to get even better at finding hidden ideas and needs from all sources like interviews, customer support, comments, observation, stakeholder knowledge, and at getting quickly to statistical validity for choosing a direction. The main art of UX will go back to being the glue and shepherd this whole design process together to working conclusions, not decide on color wheels.
  • What you get out of the AI box will be so middle-of-the-road, that making the designs stand out for brands that need it, or for innovative new functions, will require real sweat.
  • Content Designers will have to push harder than ever for Product to please, please, please start with content first, and let them innovate on content first, or all content will be forced into the same 10 formats. However, a team with strong content designers that takes the time to design some different content formats first will be able to test very fast which of those formats gets the best results for their specific brand and goal.
  • Design gets a lot closer to being research. Design can experiment more to learn lessons faster, without eating up dev time on prototypes or experiments that will be thrown away.
  • Dev can now focus on robustly delivering the ‘winner’ but will have to take the design output and run every line through their own translators to integrate them into existing production code. And they will have to fight to be allowed to do it because what the AI / no code / Design cycle produced for testing will look good enough to release. There will be production UXers involved to keep all touch points coherent.
  • Which will then organize developers and designers into parallel tracks that are less dependent on each other and allow both disciplines to operate at their own speed, increasing comfort and quality.
  • Hand-off between stages will be even more of a trip. The AIs will help us manage the design systems, the code repositories, link the tokens and and variables directly, drop templates into the CMS for instant use, be helpful in all kinds of ways, yet somehow unpredictably fall flat on their face serving some users complete garbage in ways we can’t even imagine right now. We have to check all systems with intense reviews and QA before anything goes live.
  • We will need to know our users better than we ever have before we even start to design something, or we will flood the zone with so many bad ideas our users will run away from our product or brand at the speed of light. Y’all have no idea how many bad A/B experiments y’all were spared just because Optimizely had the built-in bottleneck of requiring JS programmers to really work. UX Research had better get really good at answering the big questions about our customers and their issues to keep us on track.

Yeah, design is absolutely in flux with the lay-offs and the re-orgs and the reckonings, but not in the way you think it is right now. How we work is about to be reorganized. The new designers are very ready to use no-code and AI tools to make the current wireframe jockeys look like chumps. Get ready.

The Map Is Not The Territory And A Wish List Is Not A Map (2)

The Limits of Prototyping in Agile Development

Central thesis of why software development is hard, and Part 1

So pretty soon in the late 90s it became common to find out what humans wanted out of computing systems by giving them a simulation of the system to play with, a prototype, which could come in all kinds of fidelities, from hand-sketched screens to, as the technology got better, clickable wireframes, to full front-ends. The craft of a UXer at the time was to be able to execute all these prototypes well with the tools available. The art was to fit prototyping at the proper fidelity into the software process such that you could find out the most, in order to decrease the risk of making the wrong thing as much as possible with the least resources. Sometimes the schedule would allow for a lot of time before development and you got to call that a “discovery phase”, sometimes you had to fit it into the Agile cycles somehow.

In a few engagements I even got both, so my team could make some outlandish mid-fidelity prototypes in Axure to run through with users and really elicit some deep thinking about their problems in the field we were working in, but then also do a broad test of the half-finished system mid-way through development to see if we were getting it right. The art there was to put the right user stories at the top of the backlog so you would have an unfinished but testable system halfway.

This is a notion that could fail in fun and unexpected ways. Like every map leaves something out of describing the territory, prototypes can’t be complete. For one effort, as we were in the UK, we put T&C stories at the bottom of the backlog, so to do after mid-way testing, because surely we didn’t need them to test the rental funnel? The prototype ended up failing testing in Germany because the test subjects insisted on thoroughly checking the T&Cs. And as I once had to explain to a group of stakeholders on another platform, we can’t prototype even more thoroughly to find all contingencies because by then you have basically just built the thing for a lot of money.

So prototypes are an answer, not the answer to dealing with the fallout from the rule

  1. Humans can not accurately describe what they want out of a software system until it exists.

The reason that knowing when to use prototypes, and which, is an art and not a craft is because Agile doesn’t actually know how to deal with product design. Check the original principles: they do talk about design in one spot, but it is a given software developers just take one next step at a time and then check if it was the right one with the business people, and that is the full extend of the thinking about what Agile makes. How it is decided what that step is, and how to make sure you end up with a coherent system across the multiple touch-points at the end, is left as an exercise to the reader. So when these Agile edicts were translated into repeatable and teachable processes like Scrum or Kanban, fitting in designing the experience became a matter of how the team or department wanted to organize, and the UX field has been struggling with that since.

Especially when the development field when through a long phase of demonizing Big Design Up Front and deciding instead software creation was supposed to be about jumping right in and asking in tiny steps if what was made was right, with a lot of bright people advocating you could go from a two-wheel kick-scooter to a Porsche SUV in small cyclical increments, of which the first stage got called MVP and rushed out. And if the market was only ready for a Porsche, well, you’d better hope you found that out by having some really deep kick-ass user interviews and conversations about that scooter MVP, or some other channel, because you’d never find out from sending that MVP out on the web and checking the numbers. Quant doesn’t give qual answers.

User research through prototyping made a resurgence, but flattened to be a repeatable and teachable process, called Design Sprint, to be only about asking people on the street what they want with half sketches, in a cycle that is only allowed to last a week. The rest of the knowledge to create a success has to come from… hunches from the product manager? Marketing? In my last job it was edicts by stakeholders, when it should have been customer service. Pulling all these signals together is the synthesis-between-departments glue UX Research and Product Design should really be bringing now and are often not empowered to do or can’t because they are stuck in cycles.

As Joanna Weber writes in this brilliant article about why Agile and Lean are such difficult fits in organizations that are vast and actually have to be trustworthy, coherent, and good: “If Scrum only worked for as long as there were waterfall systems in place to support it, we need to replace both with something that both acknowledges and improves that reality.“

And the reality is rule nr 1 above, and that

  1. Humans can not accurately predict how long any software effort will take beyond four weeks. And after 2 weeks it is already dicey.

So that replacement has to stay incremental in nature and show a lot to users at every step. It’s a tough situation and it has been true for years: we still do not have a repeatable, teachable process to make great software systems that span multiple touch-points and are a joy to use and maintain. We have to navigate between speed of incremental delivery and allowing time for thinking for design.

Right now there are roughly three fundamental ways in which design fits into Agile of various forms, Sprint 0 (which can be Big Design Upfront), Sprint Ahead, and Parallel Tracks. Of these, Sprint 0 and Sprint Ahead are the ones I am finding the most, with Parallel Tracks, that could combine research and design into a very strong customer experience proposition, seeming the least popular, mostly because “devs want their designer embedded for synergy and speed”.

That should change, though. While UX Research and Product Design currently have an employment and cvredibility crisis, I recently did some prototyping with new tools that make me think there’s a whole new direction to go here. But this is already too long, so I will describe my ideas for the future next week.

The Map Is Not The Territory And A Wish List Is Not A Map (1)

“Where have all the task decompositions gone?” I was talking to a very experienced Head of UX about the state of our vocation when she asked that. I had to agree I have not seen one in years either. A task decomposition is when you take a task and divide it into steps, and then divide those into smaller steps, until you reach some granularity that makes sense for why you are doing this, like making screens or coordinating robot movements.

We used to do them all the time in UX, mostly when the field was still called HCI, to make sure we understood what the human was doing before we taught the computer to help them with it. There were many notation systems for them, and you could write PhD’s on comparing these notation systems and then inventing new ones.

Also something I haven’t seen in a decade is a specification full of descriptions of features that a system SHOULD and MUST and COULD have. The were called Functional Requirements, and while they often tried not to impose a view on how the system should look to users, you could tell how desperate the writer was trying to convey their needs in something else than fuzzy human language when they invariably started to use Word’s shapes tool to mock up screens—and then write the word SUGGESTION underneath so as to not offend their designers.

TDs and FRs are a relic from the waterfall period when you did a lot of design and understanding up front to make sure you were making the right thing for people before you committed the programming resources to make it. They were intrinsically incomplete in the same way a map always leaves things out of its description of the actual terrain, and expensive to make, and of limited use because:

  1. Humans can not accurately describe what they want out of a software system until it exists.

Bit of an issue.

Rule nr 1 is and was true all the time. You’d computerize a workflow of paper files in a shop or local government and at the end it would turn out that there were all these exceptions being made by clerks and admins using different color pens or writing in the margins that all the workers understood, but nobody above them working with IT did. The exception would be so important you’d have to retool the whole thing down to the tables in the database, and the project would be late and expensive.

When Agile originally said to deliver value frequently, it wasn’t to unlock money from customers cycle after cycle—that wasn’t even really possible until we started putting everything on the instantly monetizable web. It wasn’t for investors either, they will happily wait years for a return if the projected return is big enough. Agile wants frequent releases so you can show the results to humans fast and get feedback and then correct, instead of finding out when you deliver the whole thing after two years that rule nr 1 above always holds. It’s only around the time Lean Startup came along that every iteration wasn’t just to correct the course but also had to deliver some new mini-feature every time.

So if you want to replace Agile Scrum or Kanban with something, you have to deal with the fact that 40 years of trying to first find out how people work, and then making wish lists in all kinds of notations of how that work is to be done by computers, never was really successful and often a total failure.

Still, adding functionality bit by bit as you explore what is needed comes with things you should be aware of:

  1. The resulting system is kludged together cycle after cycle, unless you take some choice time between cycles to refactor huge chunks. This is why every seven years a software team wants to just start over, they can’t take doing archeology in all those cycles of hacks anymore and don’t feel they can add any more functionality without watching the tower of hacks fall over.
  2. It’s actually not faster than Waterfall. It just decreases the risk of ending up with garbage a sub-optimal product-market fit.

But, but, but, if wish lists specifications didn’t work because making software in itself changes the work the software is supposed to help out with, what about prototypes? That worked, right? Yes, with a list of caveats including that Agile actually doesn’t know when to use them and that AI-derived UX is deeply changing that game in the last 6 months, but I’ll discuss that in part 2.

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

  1. Humans can not accurately describe what they want out of a software system until it exists.
  2. 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.

Making Promises We Don’t Know How To Keep

I left London after ten years, and moved to Berlin, for various reasons. There is a lot of UX work here, but most of it is in digital B2C Product creation in the lean / Agile / data-informed variety for start-ups (or companies that think they want to be start-ups). Showing up with twenty years of product facilitation and advanced concepts on the CV meant a lot of searching to find a good fit, and I now am working in scientific publishing, enabling an internal platform for many business units.

I recently noticed a core piece of anxiety I used to have almost every day at work in London at the various agencies and clients, is gone. It isn’t just the way UX in London is so over-hyped with its constant events and conferences that makes you feel just doing your job is not good enough, but something else has qualitatively changed for me. I sat with it for a moment and realized what it was: I am not asked to do the impossible anymore.

The higher I got, the more unreasonable the requirements I had to take responsibility for became. I have been the Director of UX for a client where someone included in the pitch the promise that our version of their new website would increase conversion by 10%. Just like that. Or I have been co-tasked with revamping a whole web product to be more socially conscious and long-term oriented, but then also told the lead-generation part of it could absolutely not drop, even though offering those leads were in direct contravention in tone to the new product. That sort of thing, mostly just blithely required so someone upstairs could get or keep their bonus.

So, increasing the business, not hurting the money they make, why do I call that unreasonable? The problem with those kinds of requirements is that UX doesn’t have the tools to evaluate them before the work is taken on. I have no way of conclusively starting out and saying, oh yeah I can do that. Asking me to sign up to goals I can’t evaluate, well, yeah that is unreasonable.

Every UX Researcher will tell you: users never stop surprising you. Every UX Designer who has had their stuff user-tested a lot will tell you: the version before first testing is trash. We can throw however many years of experience we have at any design, however many heuristics we have to get it right, and we will still be surprised at how users interpret some aspect of a page: the copy, not seeing a button because of the surrounding elements, the sizes of boxes misleading the eye. Add to that how every design these days is very often not the actual full page, but a piece that will be inserted into a system of modules, journeys, cookie banners, mail sign-ups, surrounding content, and unpredictable ads, and we’re unable to have any certainty even if we did have predictive tools.

But we don’t have predictive tools in UX. Just a mountain of ways to lower risk by gathering information pre- or post-design. So when during a pitch I find out I am being signed up to a 10% increase of conversion I can’t actually say No and keep my job. I can barely say “I don’t know”, really. I have gotten away with “I’ll do my best” or “Well, their site is fundamentally ten years old–I really think we should be able to do better”.

Programming, i.e. software development, switched to Agile methodologies because it turns out the intricacies of legacy layers of code and business-requirements make it impossible to predict scope and time beyond four weeks. UX design tries to do the same shortening by advocating repeating quick build-test-measure cycles, calling it a “product experiment” to “fail fast at”, but it is still not accepted everywhere, and the reason this methodology needs to exists, that fundamental inability to predict during design how good a design is, just hasn’t properly percolated back up to decision makers yet. We also haven’t let it: part of clawing our way to a seat at the top table has been putting up this facade that “finally” letting us do “proper” proper Service / UX / Customer / Product / User-centered Design will surely lower risk and increase profits by making better products. That facade is hurting us by not letting us push back against requirements we can not fulfill, and that desire for a place at the table is holding us back by stopping us from staring the business in the face and point blank asking “Instead of making me obsess over 40 colors of green to increase click-through rates by .1%, have you considered making a product at a price people actually want? Because if you did, I could hide that Buy button and people would still click it.”

But no. Industry does not work that way. Instead I carried around a tiny gremlin far away in my consciousness, a gremlin I could easily explain and wave away as the way things are, or that by the time the client would notice I did not increase conversion by 10% or whatever, we would be further along the path of doing other things. But it still gnawed at me. I only notice now that it is gone by how much.

My job now has problems of how to display the contents of a book online that has, literally, 20.000 chapters, and how to let users search in reference media without having to ship the whole catalog over in hidden javascript–meaty questions of weighing user needs vs technological capability, and how to best communicate the trade-offs and effects. It’s fun work, it is hard work, it is serious work, but best of all, when I say “I’ll see what we can do, but no promises–this is kind of weird and unprecedented and we’re going to have to make it up for a while”, everybody understands, and nobody waves a contract at me where they go “But we promised the client that…!”

‘Conversion’ is not the work I signed up for twenty years ago when I wanted to make computing easier for my mother. This is.

Content Strategy: unless you are making something small, you need it

The first time I actually worked on something we could term User Experience, I was changing the default positions of my icons on a UNIX workstation running some version of SunOS (in other words, it was a long effing time ago) and part of that was designing some icons in black and white, pixel by pixel, for programs that did not have icons. These days I make big things for many people, and I wouldn’t release anything on an app or website unless it had been made by a trained, experienced, graphics professional, which I am not.
I used to be able to code a website front to back too, and I stopped doing that as part of all my other tasks in 2006 and now it’s so complicated you can’t just do it as a side task of many. Thinking I have the knowledge to do everything myself on an app or website to high quality is just so arrogant it is stupid.

The same goes for content. That might seem like a no-brainer, but you can tell who still doesn’t have these brains: teams who design with Lorem Ipsum, or teams on a project with more than ten pages who think all they need for their content is a copywriter.

I was there myself a few years ago inside a big agency, thinking that content is just something you quickly commissioned and wrote. I should have already totally been over that when a previous project for a car brand fell apart when they wanted a whole new website and the sole copywriter they hired wasn’t fast enough and didn’t really know what to do, so I was told I should just use last year’s copy. The result was a mess, and yet I had not learned my lesson. A huge strategic gap in the creation of a rich, vast website with existing content was staring me in the face and I simply did not see it.

At first I did not know how to deal with Content Strategists, but now I am glad the agency had the foresight to sell their services to the client who wanted a re-platform and a re-vamp that reflected the aspirations of their high-end brand, whether it was just to raise the billable hours or not. By working with Content Strategists, a whole weight fell off my shoulders as a UX Director and I could focus my team better. The whole question of what the hell are we going to do for educational content about the brand and its USP and its products, what can we re-use from the existing site, what is even there in their twenty-thousand pages, and how do we get our brand’s point across coherently, was now being handled by a group of people whose main focus was indeed making coherent publications.

They had tools to find out what was already there, and patience to inventory and tally what content users obviously already liked, or needed. The Content Strategists created criteria for what should be considered success, and failure, in an article, based on their knowledge as editors of how people absorb corpora on information. I could focus helping users find what they needed to do, they focused on what users needed to know to get it done, and then get good at it.
It is a absolutely indispensable discipline when you either know that the user has deep educational needs in the service you provide, or the client already has a vast collection of content that is usually stale and no longer to the point. Just being able to walk up to them with some existing content around a form and being able to ask “Does this live on? Do we re-use it? Is it any good?” and getting an answer based on usefulness, current use, current satisfaction, and adherence to tone of voice, sped up my designers to no end as we never had to come up with our own placeholders or use lorem ipsum, which the agency, correctly, had banned anyway.

If you are going to be content-driven, having people who do content research at the beginning of the project, based on the user needs UX and Research have worked out, is mandatory–and these days, being content driven as a site in itself is mandatory.

I am currently consulting for a large consumer-finance brand, so established and large it is basically an institution. They have their (semi-)celebrity blog on consumer hints and myths, their social content, random pages for SEO value, and more articles of which we know the user is searching for them and desperately needs education. None of it is linked through from the current web site where they have their account. What they do have in educational content inside the service part of the website is about 60 questions, so-called frequently asked. I begged for a content strategist, trying to make clear that just having a copywriter for gaps isn’t enough. I am now working with a Content Strategy team in what I consider a model cooperation.

  • We worked together to agree on a view of who our users are (very tricky in this specific case, because nominally we are designing for everybody here, so we had to agree on levels of understanding, language, and progression. The usual case is working from your personas).
  • The Content Strategists made an inventory of everything already there, and held it up to brand values, tone of voice, and user needs as we understood them.
  • My Product / UX team focused on the clicks and buttons and page journeys for the core service the brand provides.
  • We look together at these service pages and note the educational needs on each page. The Content Strategists either suggested a link, or extracts or videos from existing content, or we identified we had a gap and they started on writing briefs and getting the necessary content made ASAP.
  • They showed me their plan for all the articles and frequent questions and video and info-graphics: how they were grouped according to how they saw users currently search, what educational needs they satisfied, what was already available.
  • My Product / UX team worked with them to re-design a library section of our website that could contain or point to all this content according to our joint user research, from hub pages to article templates
  • My Product Managers are working with the third party that will host all this content, based on my UX templates. We needed a 3d party because this corpus needs to be easily seen by our phone support people, and integrate with their phone support tools in a piece of service design. Usually the content goes in the same CMS the website is being made with.
  • I don’t have to worry about porting the content, filling in the gaps, or making sure it all looks good. The Content team is on it, commissioning writers, illustrators, photography, and videographers. They write and execute the plan for governance and approval, maintenance, and adaptation of the content in the future. They got this. I don’t have to.

This all creates such an increase in speed and especially quality, that they are totally worth the investment. Furthermore, their expertise in re-use and adaptation is saving money where my UX team would have been unable to accurately identify the gaps or articulate to content creators how they should be filled.

(The best part is watching them go to a client with a presentation like “You have 20.000 pages of SEO garbage. Yes, we counted. Your users hit about 600 of those, if that. You can save a ton of money by getting rid of those 19.400 pages, and guess what, you also won’t look like cheap hucksters in a list of Google results anymore.” The look on a client’s face when they realize how much they have wasted on old-school SEO is priceless. Make sure your Content Strategist at that meeting is both authoritative and really soothing.)

What has made these collaborations so good is their knowledge gained from specialization; most of the Content Strategists I have worked with come from the worlds of journalism and publishing, where having a single voice over many kinds of content, focusing on what people want or need to know, understanding where and who your readers really are, and  how they absorb information, is a basic ingrained task. It’s where they always have lived and now live in a new medium.

I raise some hackles left and right these days when I proclaim I consider them part of User Experience (or Customer Experience, or Service Design, or whatever we are calling ourselves these days) as much as the visual graphics team or the user research team: many UX people do not understand their value yet, and Content Strategists themselves are still so isolated often this viewpoint is new to them. But I won’t work on one of the large websites I usually get asked for without them. I do not have the knowledge of what they are so good at, and I definitely do not have the time.