Blog

Stop. Collaborate. And Listen.

Design handoff is what happens when designers stop designing and developers start building. It is the moment when the output from one group becomes the input for another. On paper, it looks clean: final screens, tidy flows, and documentation. In reality, it is often clunky, misunderstood, poorly timed, and full of assumptions. It is where gaps appear, where product decisions are made too late, where time gets wasted, and where trust is lost.

In a dream world, handoff would not exist.

Instead, you would have ongoing collaboration. Designers and engineers would be paired like copywriters and art directors in traditional ad agencies. Working through problems side by side. Sharing ideas in real time. Bouncing solutions off each other before any pixels or code are committed.

But we do not live in a dream world.

Most teams are under pressure. Short on time. Spread across projects, sprints, or time zones. Often, design and engineering meet far too late. One team has already made decisions the other is unaware of. Work has started without alignment. You are forced into a handoff.

This is about making the most of that moment and avoiding the worst of it.

First, know where you are

Designers: if you are joining a project, find out where engineering is. What has already been built? What decisions have been made? Are you picking up from an earlier phase or starting from scratch?

Engineers: same for you. Do not assume the design is locked or that everything has been considered. Understand where the design team is. What has been tested, validated, or still needs refinement?

You might be further apart than you realise. That is not a blocker. It is a signal to talk.

If there is a gap, decide whether you are building on what exists or pausing to realign. This is rarely a formal meeting. It should be a working session. Sit down. Talk it through. Be honest. Define the shared outcome and work backwards, considering both what the user will see and what happens behind the scenes.

Good products are built when both sides see the full picture, not just their part of it.

The handoff should not be a mystery

Designers do not need to code, but they should understand how development works. Developers do not need to design, but they should understand the intent behind the design and how users will experience the product.

It is not a handoff. It is a handshake.

Make time to show and tell: casually, frequently, and with purpose. Share how things work. Explain flows, architecture, constraints, and patterns. Avoid jargon. Use it as a chance to build mutual understanding. These conversations reduce confusion and strengthen collaboration across every future project.

Designers: create pages in your Figma files specifically for developers. Clearly labelled. Focused. If the team is expecting updated calendar designs, do not bury them between 20 random layouts from a creative streak.

Developers: do not camp out in design tools waiting for clarity. Respect a designer’s process and request a walkthrough. Get the context behind what is being built.

Work in chunks, not silos

Smaller and more frequent handoffs reduce the risk of things going off track.

Designing in isolation for two weeks and then passing everything over rarely works. Nor does building something quietly and only reviewing it near completion.

Sit together and say, “I did this. Does it match what you expected?” Or, “I’m planning to do this. Will it cause any issues for your part?”

These are not formal meetings. Just regular, honest communication. Whether it is Slack, a quick call, or a shared workspace, make these conversations part of your rhythm.

The more you talk, the more aligned you will be, and the less rework you will need to do.

Present together, own it together

Before any internal or client review, design and engineering should sync. Go through what will be presented. Confirm what is ready and what is not. Do not leave each other exposed.

Clients do not lose trust because something is unfinished. They lose trust when teams are misaligned.

You are not building a design. You are not building code. You are building a product.

Forget the org chart, fix the workflow

Even if your organisation separates design and engineering, your output must be unified. That means moving away from handoffs and towards real collaboration. Pair up. Talk it through. Work past friction. Make time to understand each other’s thinking.

If process, tools, or vague expectations are slowing you down, raise it early. Do not stay reactive. Suggest ways to work better. If there is a more effective way to collaborate on this project, use it. You are the ones delivering the outcome.

It is your responsibility to make sure it lands.

Vibe together, ship together

The best teams are in sync. Designers who understand development tradeoffs. Developers who can explain design logic. That is the goal. That is the vibe.

You do not have to be best friends. But you should know each other. Go for beers. Share playlists. Build something that works better than what either of you could have done alone.

When a team finds its rhythm, let it roll.

A handoff is necessary when teams work separately. Collaboration happens when teams work together.

You may not always be able to avoid handoff. But you can make it smarter, smoother, and less painful. Start early. Communicate often. Share your thinking. Align on where you are going. And when in doubt, sit together and figure it out.

Building my site with AI

I built my website using AI. Not a site builder or a drag-and-drop interface, but actual HTML, CSS, JavaScript, and a custom WordPress theme, written and structured with the help of AI tools.

When I lost my job last year, I needed to pull together my portfolio quickly. I tried a bunch of tools like Squarespace for ease of use so I could just focus on my case studies, and Framer to build something modern with no-code tools, but I thought using AI would make for a more interesting experiment. At first I just used AI to help me generate some ideas using HTML, CSS and JS, but I knew I had to use a CMS and ended up using WordPress. I had not built a theme in a while and the last time was before the block editor was in use. This part was fairly easy, simple prompts in both ChatGPT and Claude gave me all the foundational templates I needed to start from. I was really impressed with the ease at which this could be done so I kept going.

I wrote a list of features I wanted my site to have based on ideas I had played around with before, and I used Claude, Perplexity and ChatGPT. None of them alone could output consistently enough to build what I wanted. At first things were really frustrating because I was prompting and making headway and then out of the blue the AIs would hallucinate or just forget everything and stop working sensibly. It drove me mad and I rediscovered what I consider as close to road rage as I had ever experienced, I would never speak to a human the way I furiously typed my distaste for the AIs messing things up.

There are limits to how much AI can output. There is also only so much you can do in a session before things start to collapse. Often AI forced me to take a time-out. I was making good progress and then out of nowhere it would break something that was working perfectly or introduce some random failure. One of the most infuriating behaviours is when it decides to delete huge chunks of code without telling you, entire features just vanish. You only notice much later when you are too far into a new flow to remember what was lost and that one flaw nearly broke me.

I still do a lot of the coding myself. I lean on AI to give me structure, clean things up, check my logic and handle the grunt work. But AI does not do the thinking. I still have to understand the problem, design the solution and make judgment calls. It is not a replacement for my own skills, it is a faster way to scaffold, clean up and iterate, but the mental heavy lifting still needs me.

But it was me who had to learn a valuable lesson. If nothing else let this be the ultimate takeaway from this article, you need to break up tasks like you would if you were building or designing something yourself. One thing at a time. AI cannot handle large prompts even well structured ones without dropping parts. I had to learn to break everything down. That does not mean I was not outraged again. No all the AIs were excellent at fixing one thing and breaking a few others and it got infuriating. I am certain my neighbours must have been terrified of me. I even took a trip to Bali while working on the site and I am sure that while I kept my composure in coffee shops my typing might have scared some of the nomads sipping on their coconuts in the co-working space. But I persisted and chipped away until I had something close to what I have now. I recently did an update aligned to my new branding. But here are some of the features of the site.

I went with a mobile-first approach and scaled up accordingly. WordPress adds some nuances I am still working through but mostly it works.

Snap to scroll and full width and height for content unless the content is longer than that area and then it allows natural scrolling. It is not perfect. Something I do not understand is making it not nearly as smooth as I would like.

The sections throughout the site change colour on scroll. Instead of having solid background blocks, each section smoothly fades from one shade to the next. It adds a more dynamic and polished feel to the scrolling experience.

I’m a huge performance nut, so I rely on CSS variables to reduce redundant code and system fonts to minimise load time. On Apple devices the site uses San Francisco fonts, which feel native and sharp. Android users also get a clean and legible experience thanks to optimised system fonts.

I also implement viewport-aware background images. These automatically adjust based on device size to maintain visual impact without wasting bandwidth. After a recent hosting migration I lost some of these image files, so I’m in the process of re-rendering and re-optimising them now.

The sections have bite-size amounts of information because lets be honest who reads. There is a bunch of scripts for time of day, day of the week, random case studies on the homepage etc.

I originally had different themes load based on time of day but now that I am introducing my brand colours I have only one theme with different colours based on the section you are in.

I am now spending more time refining the content for AI search results and it is challenging every day I learn something new and have to adjust.

I still add features but Ive learned to break them up. A big one I want to work on after all the recent bug fixes is animation. I had some but found it caused browser lag. I used js frameworks but they seem so bloated for me, so looking at an alternative approach.

I am also considering a new navigation which is still my typical floating on the top right on desktop and bottom on mobile I think there might be something fresher I could add. Feel free to share any new user friendly options you might have seen.

Working with AI is not easy. I’ve also tried Bolt, Lovable and a few others, as I’m constantly bombarded with builders, but honestly none of them offer the refinement I can get with just ChatGPT and similar tools when I keep things simple and focus on one task at a time.

A personal site is never truly finished. It grows as your skills grow. For me, building this version with AI wasn’t just a way to ship something fast. It pushed me in ways I never expected despite frustrating me so badly. But I have gotten used to this being the way I work now.

P.S. I am aware there are some bugs, I’ve recently changed servers and I’m updating the content on my site.

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.

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

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.

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 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.

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.