『UX Insights - User Experience Leadership and Strategy』のカバーアート

UX Insights - User Experience Leadership and Strategy

UX Insights - User Experience Leadership and Strategy

著者： Paul Boag
無料で聴く

Need quick, actionable insights to sharpen your UX leadership and strategy? Short on time but eager to grow your influence? UX strategist Paul Boag delivers concise, practical episodes designed to enhance your strategic thinking, leadership skills, and impact in user experience. Each bite-sized podcast is just 6-10 minutes—perfect for busy UX leaders and advocates on the go.Boagworks Ltd 経済学
エピソード
  • Stop Copying Your Competitors

    Stop Copying Your Competitors
    2026/07/16

    One of the most dangerous mistakes I see people make with their websites is fixating on what the competition is doing.

    Don't get me wrong. Competitive analysis is a valuable part of any digital strategy, but there's a fine line between being aware of the competition's strengths and weaknesses and letting them dictate your own direction.

    The slow slide into copying

    That's the danger here. Very quickly you can go from a healthy interest in your competition to essentially copying them every step. And if you fall into that trap, the inevitable result is that you're always going to be one step behind them.

    Not that anybody ever sets out to copy their competition, but it's insidious and it can happen without you even noticing. It starts out with a competitive review and then quickly moves to "Well, none of our competitors do that," or "Everybody has this kind of information architecture, so we should too," and before you know it, you've created a clone of your competitors.

    It's not only about being one step behind

    But this isn't just the worry of being one step behind your competition. There are two other considerations here as well.

    First, you quickly find that in some sectors all the companies end up looking the same, as they all copy one another, and so your site does nothing to stand out from the crowd, making it largely redundant.

    Secondly, and in my opinion more importantly, there's a false premise behind the desire to copy the competition. That's the belief that your competitors somehow know how to do things properly and that we should learn from them. There's an assumption that they've done their research, that they've made good decisions, which in my experience is simply not true.

    But they're bigger than us, surely they know what they're doing?

    Now I know what you might be thinking. "Our competition is much bigger than us. They've got more resources and more time, so surely they're making good decisions based on real data, and we can learn from that." However, that's rarely the case. I've worked with many large enterprise organizations, and to be frank they're just as disorganized, inefficient and over-stretched as their much smaller competitors.

    You are not your competitors

    And then, of course, there's the fact that you are not your competitors. Although you may be very similar, every organization is unique and needs to approach the market in a different way. If your competitors really are bigger than you, then you're not going to have the same success adopting their tactics.

    The real reason we copy

    However, in many ways, all of this is a distraction from the real reason that most people want to copy their competition. That's the fact that you don't get in trouble for doing what your competitors have done. They give you a point of reference that you can point at and say, "Well, they did this and it obviously worked for them." Of course, the chances are that's not actually true, and the very feature you're copying could well be underperforming for your competitors. Nevertheless, you have a justification for your actions.

    Do your own research instead

    But copying the competition is not the only justification you can use. Far better is to carry out your own research into user needs and behavior and base your decisions on that. Even if that research is just desk research, carried out online using the help of AI deep research tools like Perplexity.

    And if you really need to see a particular approach working in the real world, then I'd encourage you to look outside of your sector, where there are ample opportunities for you to find ideas that could be truly innovative in your own.

    So the next time you find yourself tempted to reject an idea because a competitor hasn't adopted that approach, or to implement a feature you've seen on a competitor's website, I'd encourage you to think twice. Because the best that approach can ever deliver is mediocrity.
    続きを読む 一部表示
    4 分
  • Stop Treating Every Task as Important

    Stop Treating Every Task as Important
    2026/07/30
    Every website and app I’ve worked on has eventually developed the same problem. It accumulates content, features, navigation options, and stakeholder requests until everything is apparently important. Of course, when everything is important, nothing is. You end up with a homepage trying to please 14 departments, navigation labels negotiated by committee, and an interface that gives the refund policy the same prominence as whatever users came to do in the first place. Which is a slightly peculiar way to design something for humans. This is why I’ve relied on top task analysis for years. Find the few things that deserve attention Top task analysis identifies the tasks, questions, and features your audience values most. Rather than asking people whether they like a particular idea, it forces them to prioritize what matters. That distinction is useful because people can want many things in theory. But when they have to choose, a much smaller set usually rises to the top. Those top tasks give you an evidence-based foundation for decisions such as: What should appear prominently on a landing pageWhich features deserve attention in an appHow a website’s information architecture should be organizedWhat information belongs in a dashboardWhich stakeholder requests can safely sit further down the list It won’t make the political conversations completely disappear, sadly. But “our users ranked this above that” is a considerably stronger position than “I feel this button should be bigger.” Why a normal survey isn’t enough A traditional survey can collect what people say they want, but the result is often another long list. You’ve discovered 47 things your audience cares about and somehow made the original problem worse. Well done, everyone. Top task analysis adds prioritization. Participants choose the 5 tasks that matter most to them and then rank those choices. That gives you a clearer picture of relative importance rather than a pile of individually reasonable requests. The approach can work for all sorts of digital products. On an ecommerce site, tasks might include checking delivery charges, tracking an order, or arranging a return.On a marketing site, they might be understanding pricing, comparing options, or finding evidence that a product works.In an application, they might be the handful of features people use every day. Once you know what sits at the top, you can design around those priorities and fit the smaller tasks around them. I’ve built a free app to make this easier Although top task analysis is valuable, running one has traditionally involved a slightly awkward collection of survey tools, spreadsheets, and manual cleanup. I’ve spent enough of my life staring at those spreadsheets, so I built a dedicated Top Task Analysis app instead. It is 100% free, and I intend to keep it that way. You can create a survey, add a few sample tasks, and share it with your audience. Participants select their 5 most important tasks, add missing options for others to choose, and then prioritize their selections. The admin area shows which tasks matter most, and you can compare the priorities of different audience groups. You can also rename, merge, or remove responses as you clean up the results, rather than performing spreadsheet surgery and hoping you haven’t accidentally deleted Western Europe. If you’d like to understand the process before creating a survey, I’ve also written a step-by-step guide to running a top task analysis. It covers gathering tasks, recruiting participants, analyzing the results, and using what you learn. The difficult bit remains reassuringly human The app will collect and organize the evidence, but it won’t decide what your interface should become. You still need to interpret the results, balance competing needs, and make sensible design choices. That is a good thing. We already have enough tools claiming to replace judgment while producing dashboards nobody reads. But top task analysis gives that judgment somewhere solid to start. It replaces a surprising amount of guesswork with direct evidence about what your audience came to do, and it makes prioritization conversations much easier to have.Try the free Top Task Analysis app A small Product Hunt-shaped favor I’m also launching the app on Product Hunt today, complete with a short video showing how it works. If you have a moment, please take a look at the launch and let me know what you think there. View the app on Product Hunt I’d genuinely value your first impressions, so if you have a moment, please leave a comment on Product Hunt. In particular, I’d love to know: Whether you can see a situation where you’d use itHow you’d like to use itWhether there are any features you think are missing And once you’ve had a chance to try it properly, ongoing feedback is equally welcome. If you run a survey and discover something confusing, missing, or mildly irritating, please let me know. I built this to ...
    続きを読む 一部表示
    5 分
  • Your UX team is set up for the wrong job

    Your UX team is set up for the wrong job
    2026/08/13
    I spent a good chunk of my career insisting that proper UX work should only be done by proper UX people, and I told myself that was about protecting quality, when honestly a fair amount of it was about protecting my own job description. I would sit in a meeting, watch a product owner sketch a screen on a whiteboard, and feel a small internal wince, as if they had wandered into my kitchen and started rearranging the crockery. It felt professional at the time. It was territorial, and it has not aged well. These days I find myself telling clients something that would have horrified younger me. If you want better digital products, the answer probably isn't sending more work through your UX team. It's changing what you employ them to do. Everybody is designing now, whether you sanctioned it or not You have almost certainly seen this happening inside your own organization. Somebody without design in their job title describes an idea to an AI tool and comes back a few hours later with a clickable prototype, realistic content, passable copy, and a flow that mostly hangs together. Developers are generating interface options before the ticket is even refined. Marketers are building and testing their own landing pages. Product owners are turning a rough thought into something demonstrable over a lunch break. Some of that work is genuinely good. Some of it is a small mountain of plausible looking rubbish that nobody has the expertise to spot. All of it is happening whether the design team blesses it or not, and it happens fast, which means it usually arrives before anyone thinks to involve them. Cutting the design team is the obvious response and the expensive one I understand the temptation. The team is expensive, the tooling has made production cheap, and somebody senior is asking what the return on all that research actually is. So the headcount that leaves doesn't get replaced, the budget line gets trimmed, and the design team's seat at the table quietly becomes an invitation to comment on decisions after they have been made. What you lose in that trade is judgment, and it shows up about two quarters later. Every team invents its own version of the same pattern, so the product starts to feel like it was assembled from three different companies. Accessibility problems accumulate because generated interfaces look fine and fail quietly. Decisions get made on assumption rather than evidence, so you build things nobody wanted and only find out after launch. Rework becomes the largest hidden line in your delivery costs, and nobody attributes it to the design cut that caused it. The organizations getting this right aren't the ones with the biggest design teams. They are the ones who moved their design people upstream, away from producing every screen and toward setting the conditions in which everybody else produces decent ones. What that structure actually looks like The version of this role that earns its keep looks less like a traditional designer and more like a conductor. Rather than routing all design work through a small team and watching a queue form, you fund that team to build the tools, standards, and guidance everyone else needs. Quality gets protected through what you hand people, rather than through gatekeeping that colleagues will route around anyway. In practice that means investing in a handful of assets. A design system with real usage guidance**, so a developer building a screen at 4pm on a Friday makes a reasonable decision without asking permission.Playbooks for the work people keep repeating**, like a landing page playbook that walks a marketer through structure, evidence, and calls to action without them inventing it from scratch each time.A research repository anybody can query**, tagged and maintained, so the research you already paid for keeps earning its money long after the readout deck has been forgotten.Functional personas that stakeholders can interrogate**, built around what customers are trying to get done rather than their age and job title, and useful enough to settle an argument in a meeting.Standards for briefing AI well, because the difference between useful output and confident nonsense sits almost entirely in the brief, and your design people are better placed than anyone to teach that. Alongside those assets, the team offers services rather than delivery. Open office hours for anyone about to build something, quick audits of work in progress, coaching for the team that keeps getting it wrong, training for the people who want to get it right. They still take on the genuinely hard, high risk design problems, but they stop being the only route to a wireframe. What has to change on your side None of this survives contact with the existing performance conversation, because most design teams are still measured on throughput. If you judge them on how many screens and tickets they got through, they will keep behaving like a production line and the queue will reappear within a month. ...
    続きを読む 一部表示
    9 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません