Blog

Performance Is Professionalism

Shipping something isn’t the same as building something that works.

Most people ship product like a teenager fucks: fast, messy, forgettable, and far too impressed with themselves.

Teams become so fixated on delivery that they lose sight of whether their creation actually performs. People spend hours debating frameworks, naming components, and endlessly defining the process. Yet somehow, in all that motion, no one stops to ask what the minimum standard for performance actually is.

A product that looks polished but stalls on a weak connection isn’t ready. A campaign site that crashes on an old iPhone isn’t complete. A feature that loads sluggishly or breaks accessibility standards falls short of acceptable standards.

The MVP Trap

Testing whether something merits building represents sound logic. Shipping quickly to gauge interest demonstrates smart strategy. That’s not the problem. The issue lies in what happens afterward.

The MVP becomes the final version. The quick build transforms into the blueprint. The mindset of moving fast evolves into an excuse to never improve. Eventually, people forget that MVP was meant to test interest, not define quality standards. The early shortcut becomes the long-term strategy.

This is how “good enough” becomes the benchmark not because it’s the best option, but because it fits the timeline.

Delivery Versus Value

Hitting deadlines and staying within budget only proves that a quote was followed. It reveals nothing about whether the result performs under real conditions. In most businesses, delivery gets treated as the definition of success. The project launched, the work shipped, stakeholders were satisfied, and the invoice got paid.

That’s not a measure of quality. That’s a financial transaction reflecting cost recovery, not usefulness, performance, or user experience. Most delivery focuses on turning a profit from the hours sold, where the end result just needs to exist, look presentable, and function during a demo.

That’s not design. That’s theatre. Surely, as a business, you want to build something outstanding that exceeds expectations and sets a benchmark for the quality you deliver. If you need a financial justification, consider it part of your marketing budget, because people talk about good experiences.

Beyond Product Launches

Designers ship far more than just products. They create marketing sites, prototypes, onboarding flows, documentation, design systems, internal tools, investor decks, content hubs, dashboards, and microsites. Each of these assets needs to withstand real-world pressure. They don’t exist in a vacuum. They face actual usage from genuine people.

A three-second delay on a pricing page alters behaviour. A janky scroll on a pitch site damages perception. A sign-up form with broken contrast erodes trust. None of these details are minor inconveniences. They represent the moments people notice, remember, and discuss.

Every piece of work must hold up. Not under ideal conditions, but in the environments people actually experience.

Performance Extends Beyond Speed

Load time represents only one component. Performance also encompasses how quickly someone can interact with your interface, whether the layout shifts while the page renders, whether assets are properly sized for mobile devices, whether the app can be downloaded without consuming excessive phone storage, whether text remains readable at small sizes, whether pages can be found and indexed by search engines, and whether video content slows the experience when a simple image would suffice.

This isn’t polish. It’s baseline functionality. These decisions fundamentally shape the user experience: app size, image compression, format selection, font loading strategies, animation weight, responsive layout design, and video implementation. None of these elements are extras. They’re core components of making something functional.

Performance doesn’t emerge from luck. It stems from discipline.

Metrics Matter

Performance can be measured objectively, not through vague opinions but with clear signals: First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift, Time to Interactive, and First Input Delay. These aren’t technical jargon. They represent real moments in someone’s experience where something either succeeds or fails.

They are moments that determine trust and metrics that reflect friction. When ignored, users feel the impact. When prioritised, experiences simply feel better.

A site that loads smoothly, responds instantly, and doesn’t fight back earns trust. It creates presence, removes barriers, and functions the way things are supposed to work.

The Cost of Neglect

Performance fails when no one claims ownership. That’s when the wrong image format gets implemented, when ten font weights load instead of two, when JavaScript blocks the main thread, when background videos auto-play without fallbacks, when mobile views get tested last, when accessibility checks are skipped, and when animations get added without considering their performance cost.

These aren’t conscious mistakes. They’re the result of leaving quality to chance, assuming someone else will address the issues, and failing to ask the right questions early enough to prevent problems.

Establish Standards Early

Performance should be integrated into the initial brief, not retrofitted during QA, not crammed into the final sprint, and not left to a lone developer trying to squeeze out milliseconds in the final hour.

Exceptional performance emerges from establishing clear standards. It requires understanding what matters, defining it precisely, and ensuring every team member knows what they’re working toward. It demands planning, not panic.

Designers structure content for clarity, developers optimise delivery mechanisms, writers eliminate bloat, and everyone contributes when the objective is established upfront.

Build for Excellence

Anyone can ship a product. The challenge lies in shipping something that endures. Something that runs efficiently, functions everywhere, responds immediately, maintains readability, and scales without collapse.

These qualities make people return. They build lasting trust and deliver meaningful outcomes.

Don’t settle for vanilla mediocrity. Performance should be the minimum expectation, the foundation upon which everything else gets constructed. When you commit to this standard, you’re not just building products. You’re crafting experiences that respect your users’ time, attention, and trust.

The idea that there’s a choice is part of the problem. This shouldn’t be up for debate. Teams need to stop chasing delivery at the expense of performance and start taking their work seriously. The difference isn’t just technical, it’s professional, ethical, and ultimately what separates forgettable work from outcomes that create value and leave a lasting impact.

Performance planning, not panic. Make it your standard.

The Missing Brief

One of the things I’ve always found missing in product design is a decent brief. Not a set of tasks in Jira. Not a Miro board from a discovery workshop. An actual brief.

The nature of product design makes this absence somewhat understandable. It’s not advertising, where the problem is predefined and the deliverable is an asset. Products evolve. Requirements shift. Discovery shapes direction. So, the idea of writing a brief before the work starts can feel like trying to sketch a map without knowing the destination.

Yet this is precisely why we need one.

A brief is not a spec
A proper product design brief is not a requirements document. It doesn’t pretend to know all the answers. Instead, it defines the why, clarifies the who, outlines the what, and acknowledges the how is still in progress. It’s a living document written by the team together and updated as new insights emerge.

When done right, the brief becomes a shared compass. It aligns stakeholders. It focuses the team. It stops you from chasing edge cases or overengineering features no one needs. It helps product owners say no. It gives designers and developers a lens to evaluate whether what they’re building is solving the right problem.

Stop hiding strategy in Jira
Often, briefs get replaced with backlogs. The strategy disappears into epics, and the original intent dies under a pile of tickets. A task list is not a narrative. And without a narrative, teams default to delivering outputs instead of outcomes.

A good brief re-centres the work around outcomes. What are we trying to achieve? Who are we doing it for? What should they feel, understand, or be able to do after interacting with our product? These are the questions worth answering.

Consider this structure for a product design brief:
Why this project?

What problem are we solving? Why now? What will success look like?

Who is this for?

Not just demographics, but behaviours, motivations, and accessibility needs.

What are the constraints?

Time, tech stack, budget, dependencies. Be honest.

What is the narrative?

Is there a story that frames the user journey? Is the product onboarding intuitive, is there a payoff?

How should this feel?

Functional? Delightful? Invisible? Is it helping people do something better, faster, more confidently?

What do we know, and what do we need to find out?

Where do we need research? Where do we test? What do we prototype?

What principles should guide us?

Simplicity, clarity, accessibility, speed. Decide early and stick to them.

None of this is revolutionary. It just doesn’t get done. Or if it does, it’s buried in slides that no one opens after the kickoff.

Make it collaborative and living
This isn’t a document that gets handed down. It’s something the team builds together. Product, design, engineering, research, even marketing. It works best when all perspectives are present. And it doesn’t stop at the start. It evolves.

Done well, the brief becomes a source of truth you return to at every stage. It’s the reminder of why you’re here, what matters, and what doesn’t.

Product design has matured in many ways. But our approach to briefing still feels like an afterthought. Bringing it forward and treating it as a collaborative, strategic tool could be the simplest way to raise the standard of what we make.

Not everything needs to start with a brief. But everything should be able to return to one.

Your Product Agency Is a Dev Shop

A lot of tech companies position themselves as digital product agencies. They claim to deliver end-to-end product solutions, but look a little closer, and they’re just shipping code.

I’m calling bullshit on this practice.

Real product agencies balance design, development, and business strategy to create products that solve problems, deliver value, and drive outcomes. Overstaffing developers, under-resourcing design, and neglecting strategic conversations isn’t building products. It’s a production line disguised as a product team.

Balance Your Team
A team stacked with developers and thin on designers is built to execute, not to create cohesive products. Effective teams bring together designers, developers, and business strategists, all equally involved from concept to launch. When design is under-resourced, it becomes surface-level. Designers are brought in to make things look good instead of influencing key product decisions.

The absence of strategic input causes the work to drift. Developers end up building features without understanding the underlying business goals, and design becomes a cosmetic layer rather than a strategic element. Structuring projects to keep design and business as present as development maintains alignment with the product vision. Each function shapes the final outcome, not just completing their assigned tasks.

A workforce dominated by developers without strategic input is structured for output, not impact.

Integrate Workflows
Strict handoffs between design and development don’t lead to cohesive products. They create disconnected features. Design and development are not separate stages but intertwined practices that need to work together from start to finish.

When designers hand off screens without context and developers build based on assumptions, the result is a fragmented product. Features function in isolation instead of forming a seamless experience. Maintaining alignment throughout the project prevents these gaps. Designers and developers should collaborate continuously, discussing technical feasibility, iterating on interactions, and addressing potential issues as a team.

Strictly following handoffs creates silos. Connecting the work across stages is what builds a cohesive product.

Set Your Standards
Debating frameworks and file structures is not progress. It’s friction. Standards establish a common ground, preventing projects from going in different directions based on personal preferences. If the organisation uses specific frameworks, that should be defined upfront, not argued over.

Assign leads to define standards for file structure, component naming, and documentation. Make sure guidelines are communicated clearly and include criteria for exceptions. Updates should be driven by proven solutions, not personal whims.

Arguing over frameworks rather than solving client problems is a sign of internal misalignment.

Understand the Problem
Diving straight into execution without clearly defining the problem is a common mistake. Effective projects begin with a structured approach to uncovering what truly needs to be solved. This involves running workshops or design sprints where business leads, designers, and developers work alongside the client to unpack the challenge, capture pain points, and align on specific outcomes.

These sessions do more than set expectations. They surface hidden complexities, highlight conflicting priorities, and clarify what success looks like for both the client and the team. Dedicating time to this phase prevents rushed estimates and misaligned efforts later on.

A shared understanding of the problem is not just a step in the process. It’s the foundation that keeps the work focused, purposeful, and strategically aligned.

Manage the Scope
When deadlines loom and budgets tighten, development teams often start slicing features to stay on track. What begins as minor adjustments can quickly turn into wholesale descoping, with entire sections of the product being cut to meet timelines. The result is a butchered product that no longer resembles the original vision.

Scope management is not about cramming everything in or cutting corners at the last minute. It’s about making deliberate decisions that protect both the budget and the product’s integrity. Planning in sprints allows issues to be identified early and adjustments made without gutting the work.

When changes are unavoidable, clearly communicate how adjustments will impact cost, timing, and deliverables. It’s not about saving face; it’s about maintaining the integrity of the product without turning it into a shell of what was promised.

Build Reusable Assets
Starting every project from scratch is a waste of resources. Product-focused teams invest in reusable assets like design systems, code libraries, and templates that provide consistency and reduce effort.

Asset development should be treated as an ongoing practice, not a one-time task. Assign leads to maintain and update these resources as living documents. Reusable assets streamline the work, reduce churn, and provide a solid foundation for future projects.

Insisting on starting fresh every time is not innovation. It’s inefficiency.

Build Client Relationships
Treating client interaction as a distraction rather than an opportunity is a missed chance to gain insight. Casual conversations build trust, uncover deeper needs, and strengthen working relationships. Discouraging engagement with clients means losing valuable context.

Not every interaction needs to be a meeting. Casual chats over a drink, a check-in email, or a short call can reveal crucial information that formal meetings might miss. Viewing client relationships as a line item on the budget misses the bigger picture.

Focusing solely on tasks while ignoring client connections is not product work. It’s order-taking.

Culture Isn’t a Performance Metric
A culture measured by attendance at social events or who posts the most emojis on Slack is performative, not authentic. Real culture emerges through how people work together, communicate, and resolve conflicts. It’s built on shared values, not forced interactions.

Inclusive cultures allow people to participate or not without fear of judgment. No one should feel pressured to attend social events to maintain good standing in the team.

Culture isn’t a checkbox to tick. It’s the environment shaped by how people work, not by how many quizzes they join.

Beyond Build
When the work ends the moment a product ships, opportunities for impact are missed. Taking responsibility for the go-to-market phase is not an afterthought. It is a critical extension of product work.

Creating landing pages, demo videos, messaging frameworks, and sales collateral ensures the product reaches its audience effectively. Staying involved post-launch allows for tracking user feedback, monitoring performance, and iterating to improve outcomes.

Dropping out after handoff isn’t product work. It’s project work that misses the long-term value.

Some agencies claim to build products, but their practices tell a different story. Structures centered around developers without strategic input, workflows based on handoffs instead of collaboration, and a focus on task completion rather than outcomes are easy to spot. Real product work is about alignment across design, development, and business strategy. It’s about creating meaningful connections between teams, clients, and the final product.

What is a design system?

A design system is a living ecosystem that serves the teams working on deploying products. As a central repository, it can be a combination of a coded components, design guides, brand assets and rules of engagement. This is usually an independent project run by a dedicated team who maintain the overall repository, code all the components, deploy updates and create all the assets for consumption by the teams across an organization.

The following are some of the most common categories within a design system.

Styleguide Commonly referred to as a living style guide is a visual reference of all the design assets that make up a brand and it’s supporting media and include things like colour, type, layout and other assets to help the design team consistently utilize the brand assets. This is constantly growing as more and more assets are added and the brand evolves.

Visual Language The brand will share the visual assets and their usage to best communicate effectively across media and contain a variety of produced assets such as video, icons, illustrations, and photography.

Design Language Every great design starts with a definition of the values and the standards to which a design effectively comes together and communicates seamlessly across multiple media. Principles are shared to help teams better understand why decisions were made and how best to apply them.

Pattern Library A coded repository of atomic-like assets for developers to easily consume to reduce the amount of churn and repeated assets that need to align across a project and function in a consistent way. This is usually html and css and some basic javascript. It can be, but not necessarily include complicated coded assets such as angularJS, jQuery and React, as technology changes so quickly code might be redundant before going live. The coded assets are both visual, functional and can be executable.

Voice & Tone Effective content and communication requires a brands voice and tone, while also including guidelines on how to effectively add content to communicate consistently across media.

Brand Guidelines Brand assets can be downloaded and appropriate guidelines shared to ensure consistent brand usage and avoid dilution of the brand and incorrect deployment creating confusion when developing brand assets.

Added to that, guidelines, legal documentation, how to contribute, get support and update logs are essential to maintaining a design system.

I hope you found this very basic guideline useful. Design systems are ever increasing in their detail and functionality and I’m sure in the future I will explain in more detail all the new features you can add and why you would need them. Whether you’re a designer, a developer or running teams and projects, a design system has to be the best way to create a consistent product, increase productivity and align your teams to your companies product vision.

System design: Block builders

In a big organisation, there are a lot of moving parts across various departments and projects and when the goal is to create a single design language, keeping a consistent design can become almost impossible.

My strategy for this was to develop a core design team who would be responsible for designing the individual components of our design system which could then be deployed and consumed by designers who worked within project teams.

This was met with a huge amount of resistance as people seem to think that having bums in seats within projects would speed things up and deadlines would be achieved. However, the goal is to have a consistent design and building up a living style guide would provide us with a platform that all teams could understand and consume the required components to apply to their designs.

Ultimately project teams should be more focused on other priorities like functionality, better user experiences and aligning all projects into the specific channels that will deliver these to the people who will use them.

In order for me to explain this over and over again, to which I have mildly had some success, I have managed to create the analogy that this core design team are busy creating the system. If I get my way, it will consist of pairing up designers with developers so they can develop these components and test, break and animate them before committing them or rolling out several static designs. I call these my Lego block builders.

Their responsibility is to make the Lego blocks which the Lego builders will consume to make the Lego models.

There is a very generic list of components almost every project may consume from (atoms), there is how you piece these components together (molecules) and then there is the way they work together (organisms).

The Lego builders consume this within their various projects and should they need a specific block that does not exist, it is their responsibility to identify it and bring it to the core design team who will then work with them to create the blocks and how they work together to deliver on the project’s needs, feeding back into the system for all other Lego builders to consume.

I have borrowed some language from Atomic design principles, and we have probably all played with Lego, so this should be language most people can understand.

I am often told that this is not agile and this is creating silos etc. Maybe, but it is necessary if you want to have a single look and feel that represents the brand consistently.

Spreading the design out across multiple teams, on multiple projects, in various buildings would simply not work. While I could move across all teams and keep alignment, the task is too great and much easier to control by giving out a set of guidelines for teams to follow.

It is a subject for another post, but living style guides and design systems are necessary and utilised by most big organisations who want to create seamless experiences for their customers.

Throwing tons of resources at this will not develop it any more successfully than putting a core team together who work with each other to solve the visual design challenges and deploy them into the style guide and then iterate accordingly.

I think the challenge is to identify the brick builders from the Lego designers who consume the bricks and make sure that there are still enough design challenges for everyone to be inspired no matter which role they are best suited to.

The other is getting people to understand the vision and hopefully make them understand that in order to be consistent and speed up the design process, a small core team is the most practical solution I can think of.

Why I subscribe to UX, but don’t call myself a UX Designer

Quite often when my friends introduce me to new people, they are unsure how best to introduce me, as explaining what I do is challenging, in truth, even for myself. But more often than not of late, I get introduced as a user experience designer, big thanks to my friends who always pop in “one the of the best …”, kudos! They call me this because I often talk about user experience as part of how I think about solving problems, and a practice I have gotten comfortable with, as I typed that I rolled my eyes, but I reluctantly use user experience as part of my thinking.

For me it’s all kinda simple, I design useful stuff that people simply love. The industry buzz word is user experience and it’s opened up an entirely new category of the team member in product teams and the like, who play not only a huge part in the success of a product etc, but they have huge clout!

I really believe that everyone is a user experience designer, as we are all responsible for the experience of the end user. But then that’s like saying everyone’s a designer because we all solve problems. Well, it’s how you solve those problems that define who we are and what we do.

Of course, given my constant attention I give to better experiences for users, or more specifically people, I am more broadly understood as being a user experience designer. But I am not. The guys that stand out for me as user experience designers might not be thinking on a whole other level as me, but they apply themselves on a level, I simply am not comfortable doing.

The thing that makes someone, specifically a user experience designer, is not purely how they think or the methodology they practice, but the tasks they do, such as user research, creating personas and hypothesis etc. There are lists of things user experience designers do, that I can do, that I enjoy hearing about, that I understand and I include in my decision making, but I simply don’t like to do myself.

I have been designing for digital channels and making stuff for nearly two decades and there are many I do well, but I am well aware that what I am when you strip away any fancy titles I might have received or called myself in order to qualify myself, is simply a designer. Where I practice my design is a whole other conversation. But what I am not, is a user experience designer, I simply subscribe to thinking and best practice and apply it to my work.

If only I could find a better handle for my social platforms, as I cringe that I still use @digiguru with all the misconceptions and remarks that name refers to, both the reference to digital, despite most of the work I have done has been in this gray area of what some people call digital and to sitting cross-legged in the lotus position somewhere on top of a mountain in the Himalayas.

The only thing that’s constant, is change

In the earlier years of my career, I did much smaller projects. Microsites, personal sites, presentations etc. Then things got bigger, campaign sites, platforms, e-commerce sites and so on. Now days, I am very much interested in building product eco-systems, and I like to work on the same project for longer periods of time, by constantly iterating and improving things. I love how platforms like Medium, Pinterest and the like are always evolving the smallest details and constantly improving on their designs.

I could never have imagined that when I began my career, I was constantly about new things, but now the new thing, is a small detail that makes for a better experience for users. What I find amusing is that we used to redesign, and then make a big deal about it. But now we keep changing things, subtly as if no one will really notice, the site just kinda feels better. As they say, the only thing that is constant, is change.