Blog

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.

Using AI to Build My Site

If you’ve noticed things looking a bit off, that’s because I’m seeing how far I can push AI to build this site.

It started when I was fixing some bugs and got curious. AI’s pretty good at writing, so why not see if it can help build a site I couldn’t do on my own?

Here’s the deal: I come up with all the ideas. AI just executes what I tell it to do. It’s like having a senior engineer who can code faster than I can, but doesn’t think for itself. I’ve been trying out ChatGPT, Claude, and Perplexity for this.

It’s been interesting. AI can quickly turn my ideas into code, even for complex stuff I don’t know how to do myself. But man, the bugs. I’m constantly switching between tools because they all have different quirks and limitations.

The dream is to eventually use this to create cooler stuff for clients without needing a whole team. Right now though, it’s a bit of a mess. But that’s part of the experiment, right?

I’m not documenting every little thing, but I’m thinking about writing it all up or maybe doing a YouTube video once I’m done. Could be helpful for other designers who want to try this out.

It’s a bit of a wild ride, but I’m curious to see where it goes. AI is often pitched as the tool to come up with ideas for your site, but I’d urge you to use it as a high-level coding tool.

A Decade of Responsive Web Design

Craig Jamieson - Responsive Web Design

Today marks 10 years since Ethan Marcotte published his article for A List Apart on responsive web design. It’s become the standard for how we build websites that scale across devices and something that helped me transition from Flash to HTML in 2010.

https://twitter.com/beep/status/1264919155364503554

I had the good fortune to meet Ethan at a conference in 2018 and his workshop and he couldn’t be a nicer guy, super smart but humble in what I believe changed how web sites were built. It’s incredible to me that it’s been a decade already. Thanks again Ethan.

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.

2017 Site Maintenance

It’s been ages since I blogged properly, but I have every intention of sharing loads more with you all. I have started doing some site maintenance. Currently, I’m playing with adding some gradients to all the pages and posts and also putting my blog at the forefront rather than my work, as I’ve just not got much content to show there, as well as how I share my posts across social channels. I have had a super 2017 and look forward to doing a recap over the next few days and sharing everything I have been doing. So thanks for understanding, and please check back soon for some updates to the site and a recap of the past year.

System design: Block builders

In a big organization, 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 in which to apply to their designs. Ultimately project teams should be more focused on other priorities like functionality, better user experiences and align 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 are busy creating the system, which if I get my way, will consist of pairing up designers with developers so they can dev these components and test, break and animate them before committing them or rolling out several static designs, is 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’s how you piece these components together (molecules) and then there’s 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 projects 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’s 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’s a subject for another post, but living style guides and designs systems are necessary and utilised by most big organisations who want to create seamless experiences for their customers, but throwing tons of resources won’t develop this any more successfully than rather 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 is still enough design challenges for everyone to be inspired no matter which role they are best suited. The other is getting people to understand the vision and hopefuly 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.

Designers: learn to code

For a while now, designers have been able to fire up their favorite design program and whip out some layouts which are sold to clients and then handed over to developers. While it would be damaging to some talented individuals to expect them to be able to do anything else, other than what they are primarily good at. For everyone else, they must learn to code.

The problem is that more often than not, is that the design does not come out built the same way it looked when it was designed. There could be any number of reasons, such as the designer not understanding what development limitations there might be, the developer does not pay attention to the details a designer might see, or things like responsive behavior and animation which you can’t explain in a static design.

The only logical solution I see is for designers to become great coders, learning how to design in the browser vs in a visual design app like sketch or photoshop. Of course, if developers came to the party and teamed up with designers like copywriter/art directors come together, that would be ideal.

Designers please, enroll in some online courses and learn to build your own responsive layouts, code animations and build a set of tools that will speed up your process with best in practice functional UI. Designers must learn to code.

KLM iFly 50

I wanted to share the KLM iFly 50 website today as it’s the first website I have seen in a while that just blew me away. It’s simple but technically brilliant and I’m truly inspired.

To celebrate the iconic fiftieth edition of IFLY KLM Magazine, we created the ultimate travel collection, presenting the 50 most beautiful, surprising and mesmerizing destinations from all over the world. (found @ Awwwards)

I don’t pay as much attention to these sorts of sites anymore, but I am inspired enough to start keeping an eye out and sharing more finds to inspire you too.

 

 

 

 

Mobile Input Types

Virtual keyboards are awesome. Use them.

One of the easiest, cheapest, fastest and most effective ways of improving your mobile experience is using the right input type. It will save the user dozens of annoying taps and all you need to do is strike a few keys.

It’s not going to transform a terrible mobile experience but it could make the difference between a good and awesome one. There are dozens of input types, have a scroll down to discover when you should and shouldn’t be using them.

Go check out Mobile Input Types

Web Designers in 2016

Its been a while since I actually got to code a website from scratch without some sort of CMS or other hosted solution. Web design simply is nothing like it was when I started out almost 2 decades ago. A lot of the major engineering is gone and for that matter, so is a lot of the design/styling. We really don’t do as much grunt work as we do, know what works. So I was thinking about what a web designer in todays online world looks like.

Nomadic

Working nomadically is nothing new to web designers, but it’s never been easier than now to work remotely. As co-working/co-living spaces become more available, with high end internet access availability, there really isn’t much holding web designers back from enjoying travel/vacation and work, a term we like to call a workation.

Basic skills

No web designer should have the right to call themselves that if they cannot at the very least understand how to write html and style with css, but I have a sneaky suspicion there are plenty of folks out there who simply know how to use the customisation panel within WordPress or their hosted online solution.

Knowing

There doesn’t seem to be any reason to have to code anything from scratch anymore, so the modern web designer really does have to know, rather than have to do. You could probably surpass more seasoned web developers by simply trying all the platforms out there and understanding their offerings than actually being able to develop anything.

Designing

Often we forget that despite being able to code, or not, there is the design, in web designer. There is very little need to design anything anymore, it’s more like a mix and match type of process. I don’t even see the point in doing a mockup design anymore, I think it’s easier to just jump straight in and add your logos, select fonts and colours and add your content.

Content is king

This old rule still stands true, even today, except it’s a whole lot easier to do now than at any other time before given how comfortable we all are taking photos of just about everything using little more than our phones and writing micro copy on the fly. Crafting words will always be an art thats hugely valuable, not even spelling is something we ned concern ourselves with, given the incredible tools available to us in editors.

Thinking

I haven’t been paid to do much for years, most of how I keep the lights on has to do with design thinking. How I see things has become far more valuable than how I (physically) do things. Knowledge, experience and approach mean a whole lot more to people than how neat my style sheet is.

Users vs taste

While every designer should have good taste, I guess it’s what separates us, it’s far more important to understand our users needs than to impose a design style. I still believe I’m an artist, my tools have just changed, my choices show my style, but my methodology and approach are the real art for delivering an experience people will love.

Innovation

You don’t have to be hugely innovative to be on the edge of web design, you simply have to know how to use the right offerings, but if you do want to innovate, then there are plenty of opportunities to join teams of designers building apps, templates and services that require that sort of thinking. But being a pioneer does not a web designer make, you can earn without being the inventor, rather you are more of a curator, so to speak.

The web is dead

If that was the case, then I see web people. Web designers are everywhere and I would think it’s one of the easiest things to get involved in, no matter what your experience. The learning curve is constant, you have to keep your skills sharp, whether it’s designing, coding or learning the latest online offerings. Being a web designer will always evolve, the web is not going anywhere. As long as there is a browser, web designers still exist and while I’m sure their is a decline in people accessing the internet by way of the browser due to apps, there is a growing internet access footprint as connectivity becomes more available.

In 2016, you don’t need to design or code to be a web designer, you just need to know how to solve problems for the web.