If you want a transcript of this episode, access to the links I mentioned, or to find more reading material and imagery go to the associated blog post. 

If you want a transcript of this episode, access to the links I mentioned, or to find more reading material and imagery go to the associated blog post.

If you want a transcript of this episode, access to the links I mentioned, or to find more reading material and imagery go to the associated blog post.

Hello again,

So I recently had a fascinating discussion with one of the people I coach. She works as a UX designer for an agency and was asking about how she should handle situations where she believes terrible decisions are being made. She struggles to balance speaking up and knowing when to accept defeat graciously.

It is a topic I touched on tangentially a while back, but I wanted to discuss it more directly today because I believe it is a balance many people struggle to get right. It is certainly something I struggle with myself.

Some people fail to speak up because they lack confidence, while others must learn when to keep their mouths shut and let things go. I will let you guess which category I fall into!

I have learned over the years that I don’t know as much as I think I do, and any decision probably includes many more factors than I am considering.

For example, the user experience must always be balanced with factors like business objectives and return on investment. It is not as simple as always going for the best experience possible. If that were the case, every company would give away their products and services for free!

Each stakeholder will come with their perspective based on their understanding of the project. Each will only see a part of the puzzle, so disagreements are inevitable.

As I have said many times over the years, I prefer to test when these issues arise to decide which approach is best. However, that is not always possible due to time constraints, budget, or the nature of the issue.

That is where it falls to leadership to make the final call, and it is okay if they don’t always agree with you. However, we must learn to accept their decision even if we disagree.

Does that mean they will always get it right? Absolutely not. However, ultimately a decision needs to be made and they will have the broadest perspective of all the factors involved.

That said, we have a responsibility too. Our responsibility is to communicate our opinion as clearly as possible and back it with as much evidence as we can gather.

But it is also our responsibility to shut up and accept defeat if we fail to convince leadership. Continuing to argue will damage the project, undermine relationships, and is extremely unlikely to change the outcome.

That is not to say you need to agree with the decision. Never say that you think something is correct just because somebody else says so. If you do, you will get sucked into the blame game if things go wrong. So instead, agree to disagree and implement their final decision with no more fuss.

However, most of all, I would encourage you to be more laid back about whether a client or boss implements your idea or not. Your job is to present the options and give them your opinion and any associated evidence. After that, it is down to them. If they reject your idea, focus on getting better at communicating your opinion next time. Never take it personally.

Ultimately life is too short, and you will be constantly unhappy if you consistently fight colleagues and management.

Today I will show you why you shouldn’t take me (or any other supposed expert) too seriously. I will contradict myself entirely and, in doing so, show you how context is everything.

But before I do, can I be honest with you? You are not supposed to say things like this because you want everybody to think you are in high demand. However, the current state of the world means I am light on work. So, if you need some consultancy, coaching, training, or help to improve your conversion rate, drop me an email. I’ll even throw in a 10% discount if you book in October.

Not too long ago, I shared with you my preferred approach to developing digital services. An approach that began with a discovery project that crucially includes user research.

I have even written about what you should do as a minimum in this type of user research.

However, if I am being honest with you, I often ignore my own advice. Blindly following best practices can often be wasteful and less effective in delivering results.

Let me give you a real example, hopefully explaining why you should always favor common sense and your judgment over what you see online.

I have been working with a company for some time now, helping them improve the conversion rate on their website.

Because of a change in circumstances, we concluded that the site needed to be redesigned and rebuilt.

I am not usually a fan of this approach, but it was the most cost-effective in this case.

Typically, I would start with a discovery phase to better understand the user, understand the competitive landscape and speak with stakeholders. However, I decided against that, jumping straight into prototyping. I didn’t even do any card sorting or top task analysis to decide on the information architecture.

My reasoning was I knew this client, their audience, and their needs well enough to have an initial stab at the website.

Of course, I am making many assumptions, and I may well be wrong. But I intend to conduct my interviews and user research retroactively rather than upfront.

If I had begun the project by interviewing stakeholders and users, I wouldn’t have known what to ask them. So I would have done it to go through the motions rather than because I had burning questions.

However, prototyping has thrown up various questions in my mind that I can now address through user research. Moreover, showing the prototype to users and stakeholders will undoubtedly generate even more questions or wrong assumptions on my part.

It makes a lot more sense to carry out the user research at that point when I have specific issues I need to resolve.

What I am driving at is that too often, we do these exercises because that is what we are supposed to do, not because we have a clear idea of what we want to learn. Everything from customer journey mapping to user surveying are tools that help us answer questions. If you don’t know what questions you need to ask, then don’t use them until you do.

Use these techniques when it is sensible, not just because somebody told you to in an article.

Hello again,

I have found myself thinking a lot about working with others recently. Digital requires us to do that a lot. We work with designers, developers, marketers, researchers, copywriters, and countless other stakeholders.

We need the expertise of each to deliver effective websites and digital services. However, balancing those many voices can be challenging and being heard even tougher.

Each stakeholder approaches projects with their unique perspective and personality. So it is unsurprising that this can lead to conflict and some voices being drowned out, resulting in simmering resentment.

Yet the alternative is not particularly attractive either. Organizations that prioritize consensus do so at the risk of reducing progress to a snail's pace, nobody taking responsibility, and solutions being watered down to the point they please nobody.

So how do we run collaborative, cross-disciplinary digital projects without them either grinding to a halt from too many opinions or leading to conflict with one or two individuals dominating?

Well, I have grown to favor three techniques:

• Establish clear ownership — Before I start any project these days, I try and get everybody to agree on who will have the ultimate decision. I seek to agree on one individual who makes the call when different voices disagree. You will find that people are reluctant to decide on this, but the alternative is some issues being almost impossible to resolve without painful and time-consuming debate.
• Have agreed upon objectives — I also seek to agree on a set of objectives and ensure these are prioritized. For example, is it more important to prioritize conversion over a positive brand perception? Should copy conforming to a style guide come before making a sale? Having these priorities establishes a pecking order in opinions, not based on seniority but the type of feedback and opinions being expressed.
• If in doubt, test — Probably the most important of the three, I have learned that the best way of resolving different perspectives is to test. That could be a survey, an AB test, unfacilitated usability testing, or whatever else gets the job done in a lightweight way that gets an answer fast. Don't over-engineer the testing; instead, seek to find a method that will get you an independent answer as quickly as possible.

That last point also brings me to another aspect of working with others that, although challenging to hear, is true — just because you are the expert doesn't mean anybody will listen to you.

Despite all my years of experience and impressive portfolio of clients, I have learned that people will still not listen to me unless I can provide independent evidence.

Now, whenever I express an opinion, I must present something to back up that statement. Either some piece of research I have done, some insights from analytics, or, if all else fails, an independent source who validates my opinion.

In all honesty, this is often why I am hired. Internal digital experts are frustrated that stakeholders ignore them, so they turn to me as an independent outside source to validate their opinions. It is terrible that this is needed, but it does work.

Trust me; I know how frustrating it can be to justify everything you say. You feel like you are wasting hours gathering the evidence you need. But the alternative is endless argument and debate that takes even longer.

Working effectively with others is a skill like any other. It takes time to learn, and I still do not always get it right. However, delivering excellent digital services and sites is impossible without it.

So my advice is to start practicing today, try things, observe what works and iterate!

I cannot tell you how much I hate Gantt charts. Why? Well, because they are the greatest work of fiction since Facebook declared it cared about user privacy.

In 27 years of working in digital, I have not once worked on a project that stuck even vaguely to the timeline laid out in the Gantt chart.

Trying to map out the entirety of a digital project from the start is a work of futility, and yet, time and again, executives and clients ask for it.

The truth of project planning is that we can only be confident about how our project starts. The further into the future we go, the less we know.

But, for a moment, let's imagine a world where this was possible. Well, when it comes to a digital project, that is still a terrible idea.

You see, digital has two distinct advantages over many other types of projects.

• It has no raw materials as such. No inherent costs outside of labor. Pixels are free.
• It is easy to gather detailed data about user behavior and characteristics.

These advantages enable a more flexible approach to project management, adapting to what you learn through user research reducing risk, and improving quality.

Of course, this ability to adapt to what you are learning is negated if the project has all been planned out in some Gantt chart at the outset. In such scenarios, supposed "scope creep" becomes the enemy. You must stick to the plan, irrespective of what you learn on the way.

So, if not Gantt charts and upfront planning, then what?

Just a quick aside. I have found myself with some availability starting next month. Drop me an email if I can help you or your organization with coaching, improving conversion, or your digital strategy.

So, instead of a linear project plan, we have a process that branches, allowing for adaptation.

I tend to define specific points where we embrace adaptation to retain some control over the direction and reassure stakeholders that the project isn't a free for all.

To achieve this, I break most reasonably large digital projects into four distinct work packages, each informing the next. These are typically:

1. Discovery. This is where we gather background information and specify what needs to be done at the highest level by identifying user needs, business goals, and constraints.
2. Alpha. This is where we create a detailed specification in the form of a prototype that is then tested with users. We can then iterate and adapt based on what we learn.
3. Build. This is where the digital service is built using the specification from the alpha. Some testing is still carried out, but changes will be more limited.
4. Live. This includes any post-launch optimization and will involve further refinement based on how users respond in the real world.

So initially, you will only plan and price the cost of the discovery phase. However, once that is done, it will provide the scope to plan the alpha. The alpha will allow you to scope and plan the build. Each phase informs the next, allowing for much more accurate project plans.

Furthermore, you can quickly adapt between phases. So, for example, your discovery phase might conclude the project is not viable and if so, you could stop before you waste too much time and energy. Alternatively, the alpha might morph the service from a website to a mobile app.

Finally, there will still be some adaptation in each phase itself based on user feedback. However, because of the limited scope of each phase, it is relatively easy to predict the amount of testing and time for iteration required.

This approach is easier to manage, leads to more accurate project planning, and reduces risk. You are not committing to a massive project but a tiny series of stages. This works particularly well when engaging an outside supplier.

At its heart, my problem with Gantt charts and, by extension, upfront planning is that it gives us false confidence. We act like we know the future, and we don't.

At best, they are an educated guess; at worse, they are a weapon that is used to beat team members around the head when they fail to hit milestones.

So, let's stop lying to ourselves and others and be honest about what we know and don't when it comes to project planning.

https://boagworld.com/emails/is-your-content-crap

https://boagworld.com/emails/no-need-to-be-embarrassed/

https://boagworld.com/emails/jargon