https://edeverett.co.uk/feed

Personas are great aren’t they? Everyone loves personas! (But ssssh! don’t admit that very few teams use them to their potential.)

This isn’t a post about creating good personas – there’s a lot written about that that by more knowledgeable people than me. I’d highly recommend reading Indi Young’s writing on personas if you haven’t already.

This is a post about what’s missing from personas and part of why they can be hard to use with complex multi-user products … and what we can do to make them useful again.

Personas are archetypes of users: representative traits and behaviours of groups of users that inspire us to design product that works well for that group. Personas often get more useful as their scope is narrowed, they need to be specific enough to for us to imagine the world through the eyes of that user archetype. This is personas’ strength. But that specificifity comes at the cost of broader context – not a bad thing, it just is.

When your your product is targetting a large range of users the necessary specifity of personas starts to be a weakness. Either you need hundreds of personas (that you don’t have time to make and no one has time to use) or you have just a few that leave large gaps. Those gaps create vacuums in understanding that get filled with unresearched assumptions and generalities – often bolted on to the personas that do exist, diluting them beyond usefulness.

A map of the personas landscape helps everyone see the gaps and differences that aren’t recorded in fully developed personas.

An simple example: When I worked at Thread – a utility asset management SaaS platform – a lot of our users were engineers in charge of maintaining the power line network. Inside Thread, “Engineer” was used pseudo-personas: “As an Engineer I want to…”. Some basic user research showed that ‘Engineer’ can be split into many different specialisms: Reliability engineers, Structural engineers, Electrical engineers etc. Each will have their own processes and needs for the data in our product.

That’s already more useful.

As well as varying in speciality, we knew that engineer users of our product spanned the many years of experience and seniority. From interns and juniors, to mid-career, team leads, and senior management. Each will have different needs and might have very different experiences of using the product. Interns often did a lot of data entry type work in our system, manager level engineers were more likely to be interested in high level risk analysis and reporting to regulators.

Now we have a reasonable map that unpacks the idea of Engineer, we could go into more detail but for us this was enough. It allowed us to name the different categories of engineer and speak about the variances and overlaps. Now when we spoke about ‘an engineer’ we had a shared understanding – a shared language – allowing us to be more precise as a team and organisation.

With a shared visual understanding of our engineer user landsacpe it gets easier talk about target personas, feature prioritiastion and roadmaps:

“Yes, that’s a great idea but it creates more value for structural engineers than reliability engineers and we aren’t targetting structural engineers in this release.”

“Reporting features aren’t on our roadmap for the next two releases so we are focusing on the needs of general engineers rather than management.”

And we can set out our product and design strategies more clearly: “We’ll start by targeting mid-career reliability engineers then… “

A map of the persona landscape allows everyone to see the totality of the user-space, and where our developed target persons sit, allowing the personas to deliver the meaning and insight they are meant to rather than be unwitting vessels for adjacent ideas that don’t have homes.

A map is not the territory, persona lanscape maps aren’t the personas. Each point on the map can have none, one or many associated personas. An example from Thread was linemen; linemen are the workmen who maintain electricity lines and poles. Linemen culture in the US is a whole thing in a way it isn’t on this side of the Atlantic (as far as I know), with all the differences and variety that entails. Different linemen had different attitudes to using drones for inspections; some linemen were very happy to use drones and work with professional pilots, others were unionised with a ‘no drones’ policy. Both occupied the same point on our persona landscape map but needed two distinct personas to model the different attitudes and behaviours.

Generally with user research and developing personas it’s the detail and quality that takes the time. (As it is with anything really…). Personas landscape maps don’t need detail and they don’t need to be perfect – the map’s job is to situate the detailed and developed personas so they can stand out and work harder – and this makes them quick.

If you have a complex user environment it’s nearly impossible to have 100% coverage of personas, but you can map the full persona landscape. The map defines helps define everything you target personas aren’t – adding essential context clarity – and allowing the personas to live up to their full potential.

Some misquoted aphorisms for tldr:

“We shape our products; thereafter they shape us”

“Culture eats everything for breakfast”

“Your culture is my opportunity”

• The “us” being shapped is not just us as individuals but us as a collective
• For modern SaaS products that collective is the teams using the products
• What’s being shaped is the team culture
• Products that enable great team cultures are loved and valued and become deeply embedded in organisations

I’ll stop with the misquotes now I promise, and I’ll write in full sentances to this doesn’t read like ChatGPT…

Slack and Teams; two business chat apps. Two very different experiences. Try telling a team that they have to give up Slack and move to Teams – more than just annoyance, the reaction you’ll get is people questioning whether they want to work at your company any more. It’s seen as ripping up the culture. Maybe “felt as” is more accurate.

It’s a tiny example – allowing users to create custom emojis – but it’s the sum of small stuff that matters. Custom emojis become powerful units of team culture. Creating, say, a customised emoji that celebrates someone’s success strengthens inter-personal bonds, demonstrating that that persons is seen by the team, and over time as it’s reused and takes on new meaning while weaving a cultural legacy within the team. Mini-memes that bond. Part of being a team is, necessarily, that others are not in the team and allowing the team to be a little different is part of that.

Teams, ironically, makes it harder for teams to be teams. The expression of emotion and culture is limited to the ways that Microsoft have deemed ok. Teams projects Microsoft culture rather than culturing team culture.

And this is a big reason why people love Slack and, well, tollerate Teams.

New B2B SaaS products are usually looking to change their industry, not just showing data in fancy new ways but changing how their customer organisations operate in some way. Multiplayer collaborative experiences are tablestakes for SaaS in 2026; well designed, these interactions can (should!) transform how teams work. We need to ask what it looks like for a team to interact with a product and how the product will make that team great, rather than just think about usability for individual team members

Product and design teams need to understand and design for the ways in which teams can build culture around the product. What are the social objects in the system and how can teams have the flexibility of expressions that allows atleast a little fun and creativity to creep in?

We have a Withings scale. It’s nice. I like it knows who the different household members are and automatically sends the reading to the right app for tracking. It’s a nice bit of product design. My wife also has a Withings smart watch, it looks good and works.

That’s kinda the limit of our relationship with the company.

Then a week or so ago I got an email saying my membership had run out or somethign. I was curious as I am generally curious about digital services because my job is to know about them. I clicked the CTA link in the email. That’s when I was surprised. It took me to a page that thanked me for updating my marketing preferences (or something similar). I hadn’t, I’d just clicked a link in an email. I was a bit annoying – I felt tricked – but whatever I’ll just mark any emails as spam.

This is the email:

Then today Withings sent an email apologising for the previous email:

“We value your trust more than a click”; looking at the r/Withings it looks like they have a lot of trust to build, but this is appreciated.

Links are GET requests and should always be idempotent.

I was asked what resources I’d point new designers to so they could improve their craft

They should study the history of their craft. Design is so rich and deeply bound with our cultures across millenium. Current fashions are a fleeting moment. If you want to find your way through the confusion and excitment of now understanding all the lessons learned by the people who got us here is invaluable.

For instance – if you want to understand typography better start with how type evolved. Serif letters evolved in stone Roman carving, probably as a stylisation of ways to neaten the end of the carved line. Roman inscriptions in stone where often commands from tyrannical demi-god psychopaths with the power of life and painful death over any readers. The ultimate authority. 2500 or so years later if you want our type to feel authorative we use serif typefaces.

It’s wild and extraordinary. It gives me butterflies just thinking about the deep of meaning embedded in everything we take for granted. This is our material as designers, we need to love it and study it. It’s culture.

And for UX: Know that understanding users didn’t start with a couple of blocks coining ‘UX’. Go back a hundred years and look at the pioneering work of Lillian Gilbreth using time and motion studies to understand how people actually used kitchens. The design of your kitchen is influenced by her work.

Planning user journeys? Marcia Bates and Berrypicking 1989

Pushing the limits of interaction across different devices? You need to study everything that came out of Xerox PARC

Etc. etc. There’s so much, go deep.

I think I was expected to point to newsletters, to tiktoks, a useful prompt, not turn around and pull a month’s worth of reading about type from my shelves

But design is too exciting and too deep to just look at the now

When I took over design at Thread our then product – UNITI3 – used colours haphasardly and confusingly. Everything status had it’s own colour, even if it was virtually indistinguishable from it’s neigbouring status’s colour. There’s was no clear meaning to the colours, no strategy for how they were used.

It’s not about looking good. Ok, it is a bit, but that’s a byproduct of clear and effective communication.

All design has a purpose and creates value for users and the business, and the primary purpose of visual design in a SaaS platform is communicating the information being displayed to users as clearly as possible.

Colour is an infinite scale. But our ability to percieve useful differences in colour is much more restricted. Rainbows contain the full visible spectrum but as any child how many colours are in a rainbox and it’ll be just 7 – red, orange, yellow, green, blue, indigo, and violet. And even then the last two are really just purple. These 6 or 7 colours and their shades – light and dark – are what we have to work with. There are physical, physiological, and cultural limitation on how we can use colour. Despite being infinite, in practice here’s really not that much to go around. And given how hard we ask colour to work in product design we have make sure we are always using it as meaningfully as possible.

Any mature design system will likely end up with several hundred colour tokens. Managing that gets very involved and can feel impenetrable with it hard to have a full overview for somone not versed in every single design and interaction. Adding new colours risks tripping over colours already used and creating sub-optimal experiences. Taking a step back and mapping colours strategically – and with meaning – makes sense of the ‘chaos’ and allows design decisions to be made faster and more coherently with lower risk of diluting the experience.

You know that thing where enthusiastic product manager or exec (you know who you are ) makes a perfectly reasonable mockup of a feature but uses colour in a batshit, inaccessible way and the designers back-channel face palm emojis to each other? They’ve tried hard and are attached to their clever solution. You then spend the rest of the meeting politely ‘debating’ colour trying to dig yourself out of a personal-opinion-hole back to good design.

A clearly communicated colour strategy communicates to all stakeholders how colour is used in an application and the meaning and purposes for each use. With a colour strategy discussion of colour becomes purposeful and focussed on function no opinions.

A colour wheen is your blank canvas. These are easy to knock up in Figma. It should go all the way to black at the edges but our app didn’t play in those spaces so I’ve left the darker tones off. (We’d have needed to go there for dark theme.)

First add the brand colours. Our primary brand colour was purple supported by aqua. Changing these was outside of the reasonable scope of product design so the are immovable pillars in our colour space. Brand color creep is always a challenge with a tendency for teams to over use brand colours. In our cse to stop the purplification of the product we needed a purple ‘no go’ zone. No colours in this space could be used. (We broke this rule twice and I regretted it deeply once.)

Next we added our core experience colours. These are the colours associated with the central experience of using the product. In our case we were an asset management platform and helping users understand the health of their asset flowed through pretty much every feature and journey. Asset health was a range from 1 through 5, the colours for each step were our core experience colours.

These colours deserve their own post, they needed to be colour-blind accessible and work on satelitte view map interfaces with basically any colour background. These colours took up a large swathe of the colour spectrum are were a defining part of UNITI4’s UI design.

After the asset health colours we needed to define UI helper colours. These were in roughly three parts 1) selected, focussed state, 2) success, warning, error colours 3) user defined label colours

We used our secondary brand colour – aqua – for selected states, check boxes, radio buttons, active menus and the like. So riffing of it’s blue-greeness we used various tones of light blue and green for the many combinations of selected, sorted, and focussed states we needed to support our data exploration interfaces.

Adding standard interaction colours for success, warning, and errors.

We had a feature where users could define their own taxonomies (tags) for various states of information. They could also choose a colour for each tag. At least for our first release of this feature I wanted to remove the risk of users creating colour combinations that were confusing when combined with other ways were were using colour, particularly the asset health colours. So for user defined tags we limited the colours to pastels with ‘pastel purple’ reserved for system-defined labels. (This was the one use of colour in the ‘brand purple defence zone’ that I didn’t regret!)

Finally! Finally, we had three extreme saturation colours used for miscellaneous data display on map satellite view. Not beautiful but reliable and effective.

Mapping the colour like this helped me manage colours and their functions in our product. I’m not sure I’ve not seen this done anywhere else like this so I thought it worth sharing.

Speed without structure and direction is like letting the air our of an inflated balloon. It makes fast progress but soon loses direction with unpredictable results and you hurt yourself knocking over a chair trying to jump out of it’s way.

This strained metaphor is about trying to get sustained speed from Gen AI design tools. Ok let’s try again…

A well run design function is sustainably fast with or without AI design tools. That speed comes from good Design Ops and following good design processes. With good processes and a working design system the gap between ‘confidently understanding the requirements’ and ‘ready to build’ approaches zero.

Design systems let you design without designing. At Thread, during our Beta phase we were still adding features. One feature that needed adding was the Conditions page. Thread is/was a utility asset inspection SaaS product where asset managers and others could view the state of all their assets. We started with the primary asset centric view of the information users to explore their assets. Each asset could have multiple ‘conditions’, things that are wrong with it. This was a powerful default, but soon users wanted to explore the informatoin in from condition centric view of the information – “Show me all the severity 3+ conditions on insulators reported in the last 6 months”. This needed a relatively complex new page.

Thankfully we had design system. In the design system we had:

• A data exploration page template
• A data table component
• All the possible table cells and how they supported different types of data
• Filters
• Action bar
• And more

Everything needed to build the page.

The design process involved adding a link to the top level navigation, then working with the product team to define the data that was needed in the table. That’s it. No high fidelity UI design. Not even a need for wireframes. This was design by specification, the requirements specced the information and behaviours, the design system specced the UI and interactions.

The design time could not have been much faster.

AI design tools are often premised on speed. But design speed isn’t usually the bottleneck in a delivery process. If design is the bottleneck then improving your design processes should be the first response, not accelerating and amplifying poor processes. Don’t just let go of the balloon and hope for velocity, even if it does feel fun.

The more you invest in good design practices and in particular design systems the more the time to deliver UI designs approaches zero.

Good process improvment isn’t exactly new. Each week, each sprint, each release, ask what’s the biggest bottleneck we have in delivering designs fast effectively and focus on improving that. Sometimes that will be best served by an AI tool, sometimes it won’t. And sometimes an AI tool can let you build a non-ai tool that improves that bottleneck. AI gives us a new repertoire of tools and abilities but the important thing raimains improving the design process – not using AI for the sake of AI. Design leaders should have a design delivery strategy, not an design AI strategy.

Identify and fix your bottlenecks one at a time, use AI tools where they are useful.

Tech debt and design debt are well known concepts in product development.

It’s ok to accept a reasonable amount of ‘less than perfect’ in engineering quality and delivered product design in exchange for being able to deliver faster. It’s understood that the debt will need to be repaid at somepoint in the future; it’s common practice to have dedicated sprints at regular intervals to pay back the tech and design debt. How much debt is acceptable versus the payback in quicker delivery is – hopefully – a strategic choice made by engineering and product leadership.

But there’s a third debt that isn’t usually spoken about: team debt. Team debt is the ‘less than perfect’ functioning of the delivery team – design, engineering. product, and others.

The qualities of high performing teams – trust, safety, clear comms, shared goals, continuous learning, etc. – take deliberare work. Practice, practice, repeat. None of this just happens, it’s team building.

But, when it’s decided it’s OK accumulate tech and design debt, when short-term speed is priorities, when the shit hits the fan and delivery goals are JFDI – all this takes a back seat. Processes are short-circuited. Teams retreat into a collection of silos and agile becomes mini-waterfalls.

Bad team practices develop, good team practices are not practiced. The team becomes less good at being a team. This is team debt. And it’s unsustainable if not corrected.

Probably no one, which is … not great…

For tech debt, engineering leadership should be able to say “There’s too cruft in this code, we need to refactor before we can deliver the next feature”.

For design debt, design leadership should be able to say “This important user journey is broken we need to fix that before we create build new features on it”

Who says “This team is not working well enough, we need to fix it before we deliver more”?

Large orgs might have someone, but probably not. Well functioning teams might have the space to reflect and call it. But well functioning teams aren’t the problem. In reality for most teams it’s no one’s responsibilty and no one’s accountability. It falls between the cracks and manifests as individual burn out.

Product, design, and engineering lead need accountabilty, and autonomy to collectively recognise that the team has built up enough debt that it’s functioning bellow efficiency and that that debt needs repaying.

We should normalise thinking of team debt as something that builds up and needs repaying and bake it into our delivery practices. Just as it’s a strategic choice how to use accumulate tech and design debt, it should be a strategic choice for how use team debt. We need to recognise it, then we use it strategically.

There’s been a lot written on good team building by people more expert than me, so I’m not going to make too many practical suggestions. Every team is different and there’s lots to get started with.

But! I would like to nominate observing users actually using the product as a very high impact activity to bring cross-functional teams together and build alignment. Having a shared understanding of users builds lasting bonds and strong foundations that will withstand a lot of JFDI.

A while ago Karen Hao was on Radio 4 while I happened to be in the kitchen I was half listening to a youtube interview with Karen Hao while I cleaned the kitchen. Funny how memory plays tricks on us.

Right… anyway…

Hao was explaining how the term ‘AI’ is a blanket for a large range of technologies. She was explaining that saying stuff like ‘we need more AI’ or ‘AI will make us more productive’ is as vague as saying stuff like ‘we need more transportation’. Like do we need more bikes? More cars? More ships? Planes? Rockets? You get the point.

It’s the same with the word ‘design’. If I tell someone ‘I’m a designer’ they won’t have a clue what I do. I need to be much more precise for people to understand. ‘I’m a designer and I work with companies to improve how thier digital services work by understanding their customer’s behaviour better’ is much more of a mouthful but it at least narrows down which bit of design I’m (usually) in. Design is a vast sprawling cultural landscape, it’s embedded in everything in hugely varying forms.

So when we log into LinkedIn or hear the latest expert/politician/hype-booster saying stuff like ‘AI is revolutionising design’ it’s like they are saying ‘transportation is revolutionising infrastructure’. Like great… but what are you really saying? Are you sure? Or are you just repeating stuff you don’t understand. It’s mashing two broad umbrella terms together and expecting to it to be meaningful.

As an industry are we working out the impact of AI tools and services. What’s real change, what’s mirage? What’s the future, what’s hyperloop?

Vague language that obfuscates the nuances of two complex interlinked fields is only going to harm us as we work to build the future that makes the best use of AI technologies.

Another in my occasion topic of unglamorous design strategies. See also Following as a design strategy

Design strategy is risk management. Delivering product is full of risk and how we design affects that risk.

The number one goal of an early startup product team has to be to deliver good (enough) product fast, get user feedback and iterate. Complexity, ambiguity, surprises, and cognative overload in the delivery process are velocity killers, we must design defensively to avoid them.

The deliver > feedback > iterate cycle should take precedence over better experience where better comes at a cost of slowing that cycle. Iterating will lead to better experiences and product outcomes. This means we are likely to design simpler, more easily deliverable, features than we could imagine.

The strategy is is to create the most deliverable designs, not the best. Or rather – the best designs with the least risk.

This will be very local to your team and product. The designer must know the skills of the delivery team and the likely technical challenges in implementing a feature. There are likely two potential pinch points 1) the quality of designs and the skills and capacity of the design team, and 2) technical complexity and the skills and capacity of the engineering team. Understanding both of these will help guide the ‘defensive constraints’ of the designs.

One example from my time with Thread is to avoid map interactions wherever possible. Thread’s UNITI asset management software is highly map-centric. With maps being a key interaction area, richer map interactions are likely to lead to the better user experiences. But we also know from hard experience that maps have highly complex interactions, are technically complex, and easily become a time-sink eating away at precious velocity and runway. So to design defensively we needed to keep as much interaction in basic HTML elements as possible, avoiding complex detailed map interactions. Slightly less intuitive, much less deliver risk.

Similarly we needed to make major updates to our inspection review tool – one of our key features, and a complex one. Users would spend hours working in the review tool, it’s productivity tool that needs to be learned. As such modelling it more like a desktop application with context-relevant panels and menus that appear where you need them is an obvious direction. But as a design team we had 8 days of one person to take our new user insight and create a fully refreshed design. Going the application route was beyond the capacity of our team. It would have left too much unexplored and carried too much risk of unknowns and surprises into production. We could iterate from something working, but only if we had something working – we couldn’t risk unexplored issues breaking our user’s productivity.

They say they don’t but they do. It’s not just leadership who ‘don’t get it’, it’s everyone, designers, developers, PMs, users. No one wants to work on an actual MVP for long. No one wants to deliver the minimum. It sucks. And it’s just draining to continuously discard so many good ideas from so many creative and inteligent people. It will rip teams apart from the inside if you aren’t very careful.

This is the risk of a defensive design strategy.

Ultimately, in a resource or capacity limited team being defensive in your design delivery strategy can mean you are able to be more ambitious in your strategic design and vision. You can move further faster.

But make sure you have a plan to deal with the things that you are defending against. Because it isn’t sustainable.

I’ve had this rattling around my Figmas for about 6 years and used it with just about everyone I’ve worked with since. It’s a small technique that can have outsized results. I wish I had a less macho name for it but this is what’s stuck in my head and I can’t get rid of it.

User: “I want a thing done”
System “Here’s a button that does the thing”
User: [presses button]
System: “The thing is now done”

This is the ‘extreme’ of design a service, as far as you can go.* It’s silly thought experiment, but also truth and a very real goal to strive for. If you could make everything work like this why wouldn’t you?

But really really why can’t your service work that well? Are you sure it can’t? But what if it could? Why can’t you fix the things that are blocking it? What would it take for you to make the experience that simply?

Keep asking “why not?” like a 4 year old on a Haribo fix. What services need joining up, what data needs to be available, what contracts need changing, what silos need busting? Good digital can do amazing things.

I often reference Jon Kolko’s post about the “simplicity on the other side of complexity“. His point it that you get to simple design by doing the hard work of working through the complexity of the problem. This is how design works.

But using ‘extreme’ service design is a cheat code for getting to the simplicity. You just start with simplicity. Work still needs to be done, but maybe less. Instead of trying to solve complex design challenges first work on making them go away. If you can it feels like magic. The hardest part is often helping others understand it isn’t.

There are things that can’t be fixed, can’t be imagined away. These are usually structural complexities outside of the scope of the current implementation.

One example might be regulations that legally require people to do certain things. I once worked on a global banking service transformation and there was one – technically automatable – step that in China required wet signatures with three witnesses and CCTV recording. Not much can be done about that. More recently in my work with Thread, we limited by regulations around drone use. We have have the technology and data to allow a fully automated ‘one click’ inspections using drones-in-a-box. But (quite reasobably) flight regulations demand that a qualified pilot with a remote flying waiver supervises the drone while it’s flying. We can imagine the service without this step but we can’t implement it.

Another example might be data stuck in legacy platforms that don’t have APIs. For now that means there may need to be a manual step in the process to check data or join things up.

Recognising these as structural complexities that prevent simplicity – rather than truths to be accepted – makes it easier to imagine fixes and improvements that tend the service back towards one-click simplicity. Maybe RPAs or AI agents can be used to patch the problem – maybe it won’t be straight-though-realtime-digital but it can get closer. If a person does have to be involved how do we create tools and experiences that simplifies their work and increases reliability to it approaches semi-automated

Mindset. Culture. Team motivation. Delivering product takes more than a design team – or design technique – and how we frame and approach design problems sets the tone for everyone involved.

Bottom-up service iteration is often achored in yesterday’s problems, yesterday’s bad decisions, yesterday’s technology. Stockholm syndrome to 10,000 inherited cuts.

Vision-first service design anchors thinking in the best it could possibly be. It might not be a perfectly finished brilliant-cut flawless diamond at first, but everyone can see it can and will be.

Organisations, teams, and customers are more inspired, more creative, more innovative, and more motivated when they understand they are polishing rough diamonds than when they believe they are polishing turds.

I’ve spoken about it as a ‘silly thought experiment’ or being childlike. It’s both and neither. As a designer working this way you need deep domain knowledge of the problems, complexities, conventions, and politics that will prevent simplicity, and the technologies and user needs and behaviours that will enable it. If you don’t you’re just fantasising. But you also need to be able set that aside and imagine ‘impossible’ new realities. A state of mind I think of as studied naivity – deep expertise with childlike wonder and playfulness. Naivety is a tool if you sharpen it.

Yeah, that’s the catch. You need to know with some confidence. You can’t shortcut being user-centred, you need to have done your research and know your users.

Using ‘extreme’ service design thinking effectively is powerful partly because you get others to buy into an exciting vision. If this vision is based on poor understanding of users you’ll build something the risk of delivering something bad is amplified. And the chances are you’ll waste effort and break trust with your team.

Let me know how if it’s helpful.

* I said at the top that this ‘one click and it happens’ model of service design is as far as we can go. That’s not quite true. It’s possible to be more extreme. It’s possible to anticipate a users needs and do it for them. But this removes agency from our users, and I’m not sure that removing agency ever leads to good service design.

Skeuomorphism is a design strategy where elements of a now redundant technology are included in the new technology to make it more socially acceptable. It smooths the transition to a new technology and is usually faded out at we become better acquainted and accepting of the new tech.

Early e-cigarettes where shaped like real cigarettes. Now vapes have evolved to take on their ‘form follows function’ shape. Notoriously Apple designed many early iPhone apps to have textured and interface elements similar to their physical counter parts. The note app had a paper feel etc. This emphasising the “touch” in their world-changing touch screen, and now – thankfully – the design style has moved on to various forms of more authentic flat design.

LLMs are designed to be anthropomorphised. This is a design choice by their creators. It’s a design chosen to easy the introduction of a radical new technology and make it more socially acceptable. It’s skeuomorphism. LLMs are designed to mimic the redundant technology they are replacing – people.

[I’m not going to get into the ethics of this. It’s too complicated and it’s nearly Christmas. There’s a lot to unpack, obvs.]

We’re in an early phase of the introduction of AI/LLMs and they haven’t yet taken their final shape. There’s a lot of evolving to too. A lot will change. And as designers we need to look beyond the anthropomorphised LLM systems of today.

• Anthropomorphism is hard to avoid. We’re basically programmed to do it; this makes it a powerful quality in a service.
• AI/LLM services are (almost universally) deliberately designed to be anthropomorphic.
• Designers are stuck in the middle looking both ways.
  • Anthropomorphism is a quality we can choose to design into the products and services we create.
  • And as we increasingly use conversational LLMs as component parts of what we create (infrastructure) we are on the receiving end of the anthropomorphism designed into the LLM.
• If we don’t counter it, the anthropomorphism designed into the LLMs will cloud our judgement and make it harder to make the critical and informed choices we need to make when using these technologies in our designs
  • This will may increase risk of harm to users or the organisation (designers over-estimating the tech) or increase the risk of under-utilising LLMs of not designing creatively with them ( designers pigeon-holing the tech)
    

It’s hard not to say “AI” when everybody else does too, but technically calling it AI is buying into the marketing. There is no intelligence there, and it’s not going to become sentient. It’s just statistics, and the danger they pose is primarily through the false sense of skill or fitness for purpose that people ascribe to them.

https://mastodon.social/@Gargron/111554885513300997

It’s peculiar that an organization (OpenAI) founded to worry about things like monstrously inhuman obsessive paperclip maximizers would choose to personify their text generator.

I mean, I mean, I know they worry about an AI so smart that it convinces us meat puppets to work to destroy ourselves. But they chose to frame *their* AI in a way everyone knows (or should know) makes humans less critical, more gullible.

https://mastodon.social/@marick@mstdn.social/111519139028927881

One thing we can do is to check the languages that we use when we talk about AI and LLMs. AIs are really just prediction systems. Describe a task and based on the system’s training it will predict an outcome.

When we find ourselves talking about the AI creating or writing try to rephrase it as predicting a desired output.

When we find ourselves talking about the system understanding or knowing try to rephrase it as has been trained on

An AI’s pronoun is the system. Avoid he, she, they etc. even it allows anthropomorphism to creep in.

And hallucinating is just predicting badly

I’m sure there’s more to this, this list is definitely not exhaustive. But starting is good.

A very interesting paper on anthropomorphism in conversational interfaces. A very good starting point.

Production of highly anthropomorphic systems can also lead to downstream harms such as (misplaced) trust in the output (mis-)information. Even if developers and designers attempt to avoid including any anthropomorphic signals, humans may still personify systems and perceive them as anthropomorphic entities. For this reason, we argue that it is particularly important to carefully consider the particular ways that systems might be perceived anthropomorphically, and choose the appropriate feature for a given situation. By carefully considering how a system may be anthropomorphised and deliberately selecting the attributes that are appropriate for each context, developers and designers can avoid falling into the trap of creating mirages of humanity.

https://arxiv.org/pdf/2305.09800.pdf

Interesting here on the implications of trust in anthropomorphised conversational UIs

You will default to thinking of it as a friend. You will speak to it in natural language, and it will respond in kind. If it is a robot, it will look humanoid—or at least like an animal. It will interact with the whole of your existence, just like another person would.

The natural language interface is critical here. We are primed to think of others who speak our language as people. And we sometimes have trouble thinking of others who speak a different language that way. We make that category error with obvious non-people, like cartoon characters. We will naturally have a “theory of mind” about any AI we talk with.

https://www.schneier.com/blog/archives/2023/12/ai-and-trust.html

The hype around these systems really serves corporate interests because it makes the tech look powerful and valuable because it distracts from the real issues that I hope regulators will be focusing on and because it makes the AI seem too exotic to be regulatable.

Designer as well as regulators!

https://medium.com/@emilymenonbender/opening-remarks-on-ai-in-the-workplace-new-crisis-or-longstanding-challenge-eb81d1bee9f

(I disagree with her characterisation of ChatGPT as fancy autocomplete, that doesn’t seem useful analogy.)

That AI tools radically changing the productivity of digital product designers feels obvious, but what is perhaps less obvious is that that the largest change will be procedural rather than creative. Once the hype dies down around generative AI creating content and we move beyond the showmanship, AI-driven tools that focus on productivity will emerge. These will run in the background and just get stuff done. They’ll enable new ways for us to interact with computers and digital services.

In the near future AI driven Sketch-to-UI design tools will radically simplify and speed up the product design process. They will do this by being able to interpret a designer’s sketches and turn them into production-ready interfaces using pre-designed and pre-built components in (AI-ready) Design Systems.

For organisations able to take advantage, this will reduce the product design and build phase from days and weeks to minutes. New design and research practices will emerge to take advantage of the new opportunities and design governance will become even more critical.

• Tesler’s law “states that for any system there is a certain amount of complexity which cannot be reduced” . Complexity is preserved.
• A hundred and ten years ago Ford created their famous production line. Complexity was moved from individual workers to the production line itself and defined processes. Building a car is no less complex (Tesler’s Law) but each worker does simpler jobs but the system of the production line is more complex. Ford invested in solving the hard problems once and the result was more cars being produced.
• Design Systems have done the same for designing digital products. Creating a Design System – a set of pre-designed, pre-developed, pre-tested components – is investing in complexity up front.
• They manage complexity in the design process, store it, and remove it from the day-to-day tasks of production designers. Production designers do simpler tasks, have narrower scope. The result is more design gets produced.
• It’s reasonable to expect this trend to continue and more efficiencies in the design process to be created. We should expect more of the complexity of product design to be moved up-front to systems, processes, defaults, and frameworks.
• AI tools are likely to enable a large acceleration of this trend. Product(ion) design will become much simpler while Design Systems will become correspondingly more complex.
• (And finally: beardy old men will continue to moan about the good old days when design was design)

This demo from the AirBnB design team – showing a computer recognising the intent of very simple sketches then assembling a user interface from the design system – deserves to be up there with the great HCI demos from the likes of Xerox Parc.

This is from 2017 – why are we still working like it’s 2016? 2017 was a long time ago in the digital product design profession, Figma was just emerging and design systems in their mature form were just starting to appear. AI has got cheaper and more widely available and design systems are pervasive. The conditions are right for picking up these ideas and running with them.

https://airbnb.design/sketching-interfaces/

6 years later, a demo of a similar process got attention on the socials. Ultimately this one feels less ambitious but demonstrates that people are interested in exploring the opportunities created by emerging tech in this space. And – powered by ChatGPT – it shows how off-the-shelf LLMs make hacking in this space cheaper and easier.

These demos are cool – and point to a near future where sketch-to-code is a real thing. Getting the AI to write the code is cool. But getting it to assemble components from a design system will be the key to using AI to generate production-ready interfaces. If the AI tools can only use carefully crafted, tested and already-deployed components to build the UI, the risks and quality concerns associated with AI code approach zero.

An AI-enabled sketch-to-code design process might look something like this:

1. Roughly sketch a user journey (On a whiteboard in a meeting with stakeholders?)
2. AI design tool auto-generates the interfaces by assembling components of the design system.
3. Use verbal prompts to suggest content
4. AI design tool generates content guided by the style guide
5. Adjust the designs by adjusting the component choices created by DesignAI
6. Deploy to live (or other testing/prototyping/research environment of choice)

We can move from days or weeks to minutes. We will be able to deploy to live before we’ve left the meeting*. This will be a wild step-change increase in designer productivity. This will both require and enable new design and research practices. It will put new importance on DesignOps, Design Governance, and the Design Systems that support this speed.

*We might not always want to deploy from a sketch, but the ability to do that opens up options

That’s a title I can’t start to fully answer! But here’s a starter-for-ten list:

• Organisations that can harness AI-driven design tools will reap large benefits in efficiencies and speed-to-market. But this will have costs in continued investment in upstream processes and design governance.
• How design works alongside product and engineering will change. New boundaries and ways of working will be created. (I suspect that design may lose influence here given our broad lack of ability to talk business).
• Using these advanced systems will become an increasingly specialised design role. It will be hard to move between roles that use them and those that don’t. This is a continuation of a current trend.
• Design systems will become more complicated and necessarily inseparable from front-end engineering. The increased complexity will make them harder to change. Building design systems to be consumed by AI-driven sketch-to-UI tools will become a highly valuable skill.
• The tools we use will change. Adobe’s $20 billion for Figma will be a distant memory.
• How we think about prototyping and user testing will change. If we can have have fully working journeys available instantly how will that improve how we test designs? If we can change prototypes instantly in response to user feedback how does change our design processes? (If we can change live products instantly response to feedback what does that mean! )

It’s gonna be fun/scary!

Yes. No. Both. AI enabled design tools have the potential to fundamentally change design processes. New design roles will be created, current ones will be disrupted. The role of designers in an AI-driven design future will be different. There is potential for this to be as big a shift in design ways-of-working as Macs and Photoshop were in 80s. (I don’t think it will be quite like that, but it’s plausible.)

• Yes – it’s coming for our jobs because design will be cheaper and quicker to create. So each ‘unit’ of design will take fewer designers.
• No – there’s not a fixed amount of design to be done in the world. If you make design cheaper it will stimulate demand and more designers will be needed to meet that demand. (This has been true of design in the last decade, as digital design has become more streamlined teams have got bigger not smaller).
• Both – at some point the efficiencies and demand will reach and equilibrium, if means more of fewer design jobs would be a wild guess. But my wild guess is more.
• Both – What I’m covering in this article is only one section of digital design – product(ion) design for largish companies with high design maturity. Design practices outside of that won’t be affected in the same way, and more product design being done may increase the demand for surrounding design jobs.

When you’re ahead one of the best strategies can be to follow. It’s one of those things that took a while to sink in but has affected my thinking ever since:

Sailboat racing offers the chance to observe an interesting reversal of a “follow the leader” strategy. The leading sailboat usually copies the strategy of the trailing boat. When the follower tacks, so does the leader. The leader imitates the follower even when the follower is clearly pursuing a poor strategy. Why? Because in sailboat racing (unlike ballroom dancing) close doesn’t count; only winning matters. If you have the lead, the surest way to stay ahead is to play monkey see, monkey do.

The Art of Strategy

If you have a lead and the the same wind and water as your competitors the best way to stay ahead is to make the same decisions as them. If their decisions are good you stay ahead, if their decisions are bad you stay ahead. Because you make the same decisions as them there is no situation where their decisions can be better than yours. And so you stay ahead.

It’s not very a very glamorous strategy to say we’re going to copy our competitors. We want to be cutting edge innovators pulling the future kicking and screaming out of our brains, heroes.

Original innovative design is hard work, expensive, and most teams don’t have unlimited supply of it. Teams should identify where original work will make the most difference to the product and focus on that. The rest, copy (carefully, sensitively, and properly researched).

We probably do this anyway but call it ‘being inspired by market research’ or something that saves designer pride. Owning up to what it actually is will allow teams to create more efficient processes and get the designs to market quicker. We don’t always need to design everything from first principles, we don’t always need both diamonds. With limited design brains it makes sense to prioritise original creativity in some places and efficiency in others.

1. Herbert Simon’s definition of design¹ as “to devise courses of action aimed at changing existing situations into preferred ones” means a lot of design must be done by non-professional designers.
2. Gorb and Dumas’s idea of Silent Design² gives this a label.
3. More Silent Design gets done in organisations than professional design.
4. Professional designers are already pretty good, but non-designers doing silent design are probably doing it not very well³.
5. Organisations that are good at design make more⁴ money⁵
6. There’s huge opportunity to improve the baseline understand of user-centred design methodology in organisations.
7. But very little focus on it.
8. Improving the quality of Silent Design is key for allowing organisations to achieve their full potential.

References

1. https://design.cmu.edu/content/herbert-simon-design-devise-courses-action-aimed-changing-existi
2. https://www.sciencedirect.com/science/article/abs/pii/0142694X87900378
3. https://servdes.org/wp/wp-content/uploads/2014/06/Junginger-S.pdf
4. https://www.designcouncil.org.uk/fileadmin/uploads/dc/Documents/TheValueOfDesignFactfinder_Design_Council.pdf
5. https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design