It's easier to create new behaviour by creating conditions by yourself than using plain willpower.

Creating conditions is much more effective than (delusionally) thinking that you can do everything by your willpower. Your brain energy is limited, therefore plan its usage smartly.

Some examples:

• To be progressive, surround yourself with progressive people.
• To run, join a club.
• To focus, go to a library.

Surround yourself with people you would like to be - intellectual superhumans can do heavy lifting for you.

It's interesting that this also works for the opposite - when you want not to do something. This occurrence has its roots in Greek literature:

• Ulysses deliberately arranged to be tied to the mast by his comrades so that he could listen to the sirens without falling victim to their trap.

By creating special environmental conditions, as in the above examples, you "outsource" your behavioural motivation to your surroundings, letting it work as a lever for your willpower.

It's bad to outsource activities that are valuable on its own (like thinking, parenting, reaching out, writing or even planning your day). -Andy Masley, the lump of cognition fallacy

Consider, for example, communication. Communication is not only about the information being exchanged; it's also about the relationship between the communicators, formed but who we are and how we express ourselves. This is also relevant to the written material that is conveyed to the larger audience.

This is why we should not outsource our communication, nor our writing to LLMs: We will melt down, become greyed-out, become average, submissive to LLMs predictive statistical model and eventually - invisible by using machine "writing" for us. We quickly lose our identity and humanity.

Using LLMs for writing is the same as using permanent training wheels on a bicycle. It prevents us for growing and learning new, better, different way of expression. A LLM soon becomes replacement instead of help, depriving us of the opportunity of discovering our own voice, and who we can be and become when we stand on our two feet.

The tool's aim is to make us stronger. LLMs are doing exactly the opposite. They are making us weaker, not stronger. What is happening with the rise of LLMs is the erosion of trust. LLMs lowered the threshold for participation, but in order to be better in writing, you need to write. Same goes for thinking.

-Inspiration from Outsourcing thinking by Eric Johannes Husom, with added thoughts and considerations

A designer, anticipating a commentary for design she previously sent, suddenly gets the message which reads like this:"I don't like the placement of the main call to action button. Also, the whole layout looks crowded. Why the customer email is written in third person? And I expected our agent's voice to be female, not male!"

This is the typical feedback that designers get when they send their work for review with little or no explanation. What happened?

The designer likely assumed that stakeholders would interpret the design exactly as intended. Alas, this rarely happen: stakeholder goals, motivations and internal models of thinking are different than designers'. They rarely see the design from the same perspective as designers do.

The core issue is in the fact that many designers think that their job is only to produce design artefacts. However, this is just one segment of designers' job. When we step back and look at the big picture, a designer's real job is communication:

• Communication with business stakeholders how the product generates business value.
• Communication of the product value to the users
• Communication the design decisions to the developers

Our design got misunderstood many times

As in previous example, designers are often surprised by how they misunderstand our design. They get many questions with "obvious" answers and requests for clarification where it's "unneeded". It's because the our design is subjective: We assume, incorrectly, that everyone will understand our design in the exact way we conceived it.

An even worse situation that can happen is the misinterpretation of our design, without providing the necessary feedback to us. As a result, teams often ship products that don't meet user needs and business goals because design ideas and rationales are not properly implemented.

Its also common for design managers to further explain your design to their bosses, which means that they interpret design in their own way. This is error prone and can lead to unsatisfying results. So the good idea would be that, whenever possible, present your design directly to decision makers.

Presenting: key skill in design

This is why presenting our design decisions is one of the most important skills in design. Be aware that not all these decisions are tied to design artefacts.

To be successful at communicating with stakeholders about our designs, we must always be able to answer these three questions about our work:

1. What problem does it solve?
2. How does it affect the stakeholders?
3. Why is it better than the alternative?

Impulsive design paradox: when designers do not think about their decisions

There is no "automaticity", "gut feeling" or "impulsiveness" when designing. Every design decision has its reasons. Design is not spontaneous: we think that we "intuitively" know what to put where, but it turns out it is a learned skill.

Designers lacking the ability to explain why they did what they did end up on the losing side of the argument. They are forced to make changes they disagree with simply because they were unable to clarify their design decisions, designing impulsively and making excuses such as: "I saw a similar approach in a competitive product", "these are established design patterns", "others are doing the same", "the boss ordered me to execute design like that" etc.

The most effective way to communicate design decisions

Conventional methods to convey design decisions are preparing clickable prototypes, doing product "real estate" tours inn design review meetings or storing design artefacts in standard team collaboration platforms. Apart from those techniques, I argue that video is the most effective way to communicate our designs.

If you ever need to explain your design artefact to someone, do it in video format with your own narrative. Show your approach to solving that problem. Talk about the reasons why you chose a certain design direction. Do it as you are presenting in person. At the end of the video explain clearly what do you need as a response. Ask for feedback, review, comment or a critique.

As a reminder, the bad way to present your design is to do "product real estate tour", which means talking about obvious things shown on the screen; rather, the designers should explain how their design decisions contribute to the overall product, to the business value and to the users.

The advantage of video is that it is universal. It easily conveys the story and communicates ideas. It is a great substitute for an in-person presentation since there is no need for yet-another-scheduled meeting. As a plus, the stakeholder would be able to review it asynchronously, when they are ready.

The preferred approach? Continuously working with stakeholders

The ideal workflow between development and design teams is a constant collaboration throughout the whole product lifecycle. When involved from the beginning, the developers will properly understand product goals, what the core idea is, what the motivation for a feature is, how it impacts the business and the users. From the business side, stakeholders get a sense of how the product will communicate its values to the users. This product development setup rarely leaves space for missed expectations.

The constant need for presenting design is even reduced when the product collaboration is constant, because developers and business stakeholders are aware of the every of design from the start. This is a nice side-effect and also a great time-saver for every member of the team; there is no need for back and forth messages, strict design reviews and similar rituals that can postpone product shipment and reduce its quality.

Throughout the history of digital product development, product leads developed various methodologies to improve communication between teams. Daily standups, pair programming, user stories, kanban boards, sanity checks, pre- and post-mortems and retrospectives are examples of these techniques. What is common for all of them is that they enforce team collaboration through artificial ceremonies, making it feel unnatural and compulsory. But when the work together is practiced from the beginning, there is no need for the introduction of rituals - the relationships are built naturally.

The most important component of design is communication. If possible, do it on a daily basis with the whole team, and the need for separate design presentation is reduced to the minimum. If you strictly need to present your design, remember to first communicate your rationales and design decisions and then show the design output. The best way to do that is in person, but if that is not possible - do it using video.

Further Reading

• Book: Articulating design decisions
• Essay: 13 ways designers screw up client presentations

Setting the alarm clock is probably the most common form of programming. It has existed in digital devices long enough that it should be a solved problem by now with a standardized, intuitive interface. Or is it?

I have recently set up an alarm to wake me up for a flight but my phone didn't wake me. Why did that happened?

I adjusted the alarm as usually during my evening routine. However, I forgot that my default alarm rings only on weekdays, and my flight was on Sunday.

My first reaction was to blame myself for this blatant mistake, as most people do when they encounter errors with machines. But let's look at this from a designer's perspective, questioning design decisions for the alarm interface.

Was setting the alarm easy? Yes to me, as I am using the alarm frequently. Was the alarm interface obvious and informative? No - I didn't realized that the alarm will not trigger.

As a product designer, I consider the notions of "being obvious" and "being easy" highly correlated. The alarm clock was easy to program because I used it frequently. And didn't notice when the alarm would actually trigger since it was easy and automatic operation. Maybe I would pay more attention had I been less familiar with the alarm clock - maybe it was actually my fault??

So the alarm didn't ring because I didn't realize when it would activate. And that was because I used it automatically, assuming that it would trigger as usually. So the interface wasn't informative, it wasn't clear. I conclude this was designer's fault.

"People always say 'it's me', but it's the computer design that's so dumb." -Jef Raskin, a pioneer of interface design

The alarm clock blunder example is one of many situations when users blame themselves for mistakes while interacting with machines. Good design can prevent errors, increase the efficiency of the operation and positively affect users' lives.

"Out of sight, out of mind" is one of the most important design principles. But when confronted with demands for more features, designers default to hiding important items under menus, forgetting about users' cognitive limitations.

"Obvious always wins" is a design heuristic derived from previous one. But screen space is finite. So designers must use it wisely, placing the most important elements in the most prominent locations. Faced with numerous feature requests, they compromise. In the case of the alarm clock, designers' decision not to include information about when the alarm clock would trigger was, at least for me, a poor choice.

And how to find out what is important? By conducting continuous research with actual users. Not using any predictive statistical model, such as LLM. Only actual users will tell the truth.

But here is the thing - did I mention that my 20-year old phone had a better alarm interface? After setting an alarm, it displayed exactly how much time remained until the alarm would trigger, eliminating any guesswork. Is this what we call progress in design?

Unpopular opinion: Tools that you use in the design process do not matter. What matters is the user response to the product. No LLM can fake that.

I met a lot of designers who obsess about their design process, about the toolset, about the latest and the greatest "AI" tool they employed. All of this matters to designers only - but not to the users.

The users do not care about the tools you use to build the product. Whether you use pen and paper or the computer is not relevant. They care about the experience and the utility of the final product.

And you can only know about the user response when the product is shipped. Before that you can only anticipate and guess. This the reason why the shipping is the crucial part of the product lifecycle: it triggers users' response. Only then you will find out: does that product work for them? does it solve their problems? is it efficient? does the user like the product?

This came as a comment to John Cutler Linkedin Post, with analogy about restaurants and product teams:

Imagine if a restaurant behaved like your average product team.

The kitchen is packed. Everyone is moving. Every station is busy. Prep lists are long. Meetings are constant.

There is always something to do.

Chopping, rearranging, documenting, planning, replating.

But plates rarely reach customers.

When they do, they’re late. Or wrong. Or cold. Or oddly disconnected from what the diners said they wanted. Yet the kitchen isn’t “failing,” exactly. It never looks like a crisis. No one storms out. No one flips a table. Diners don’t riot. They just lower their expectations and stop coming back.

Inside the kitchen, though, the staff feels productive. Everyone is exhausted. Everyone is “at capacity.” Everyone can point to a dozen tasks they completed. They can even argue those tasks were important. And in isolation, many of them were.

But restaurants are not judged by how busy the kitchen is. They are judged by how consistently they deliver great food, on time, to the people who ordered it.

Product development is strange because this feedback loop is muted.

There is no instant revolt.

A team can be unbelievably heroically busy without producing much that actually moves the needle.

That’s the trap: in software, effort is easy to generate, activity is easy to justify, and impact is surprisingly easy to avoid.

User perception is everything; no tool can fix a product that feels wrong to users.

I've recently come across a special branch of sustainable technology, called permacomputing. It is a philosophy and an (indie) movement that proposes alternative, non-consumerist thinking about technology, specifically computers: it tries to ask and to answer a question:

Is it possible to make a long-standing, repairable computing machine, that actually strengthens ecosystems and has emancipating impact on humans?

Here are my notes from the resources I had collected.

Eiríkr Åsheim: Uxn: Permacomputing & Roguelikes

Mantra: do more with less or better: do less with less.

The goal of permacomputing is to reduce ecological footprint of hardware and software, minimizing complexity for distribution while maximizing the relative usefulness to the users.

Permacomputing is by definition future-proof: perma==constant.

-Notes from Uxn Youtube talk

LGM 2025 - Permacomputing: Fermenting Regenerative Aesthetics

Permacomputing is about accepting and embracing limitations and constraints. Those two words have negative connotations (in terms of, i.e. impact to freedom) despite that the real life is full of constraints. However, artists and crafts people always work with constraints!

Modern device have "you buy this thing, you will be free" promise of the contemporary consumerism.

-Notes from LGM 2025 Youtube talk

Permacomputing 101

Computation should be used responsibly, and only if it has strenghthening effects on ecosystems. That which cannot be repaired is already broken.

Sufficiently advanced technology is indistuingishable from nature.

Tech should be emancipating.

The software should be built extremely efficient. It should be built with offline first approach using "file over app" mantra.

-Notes from Permacomputing 101 Youtube talk

More links

• http://viznut.fi/texts-en/permacomputing.html
• https://100r.ca/site/permacomputing_101.html
• https://permacomputing.net/
• http://viznut.fi/en/

Writings

• https://ploum.net/2022-12-03-reinventing-how-we-use-computers.html

When asked about my profession I simply reply "I am a product designer". My answer often triggers an association with product aesthetics, kind of "oh I see - you are making software look simple and pretty" answer.

Traditionally, design was always connected with how something looks, with the emotional experience. This relates to product design as well.

But this was not my intention. I wanted to convey that the discipline I practice is broader. That designers' work starts before any sketching of the interface, before any prototyping. It begins with analyzing a problem intended to be solved. Designer then thinks about optimal solutions, and about implications of those solutions. Then "traditional" design work takes over: drawing user flows and journeys, sketching wireframes, prototyping interfaces.

I want to find a word that illustrates the wider, if not complete, meaning of the product design profession. The closest words to my intention could be "conceiving" or "devising".

I am sure that "product conceiver" sounds awkward. I came up with a compromise: instead of calling the profession with an aesthetic-oriented name, I now briefly explain what I am doing, sort of: "I am conceiving/devising digital products."

UX outcome tries to answer a question: When we deliver great designs, how does it improve someone's life?

By asking this question, we no longer consider what the solution should look like (in terms of UI or other artefacts) - but what is the impact of the resulting product. We are talking about the overall quality of the solution as well.

An outcome is hardly to measure before the product is released and put in the hands of users. It is defined as "how the product affects lives of our users after they started using the software". Are their lives really changed? Can they live without the product afterwards? How hardly?

Users don't want output like: number of lines of code released, the number of tasks finished, or number of artboards drawn; what they want is to get the job done and for the product to change their lives - to make them better and their lives easier.

Users might sometimes want certain features in order to get things done, but what they actually want is to update and improve their life. In an ideal world, product does not exist - only desirable outcomes exist.

So designers' goal is to change the world. To maximize outcomes and impact with their designs.

Faced with tight schedules and focused on shipping product, designers rarely think beyond the product's core goal: to fulfil user needs while providing necessary business outcomes. This reductionistic approach in design overlooks the impact of the product beyond its intended scope. However, in many cases a product affects the user and the environment long after the product is out of use.

Here are some real-life examples of how unintended outcomes negatively affected the product, its performance and caused unplanned side effects:

• Airbnb landlords rose overall rent prices because they converted their properties from long-term rent to short-term rent, causing the scarcity of properties - thus raising the prices
• To reduce commute time couple of minutes, Waze routes the traffic through quiet and narrow streets, causing them to became dangerous for pedestrians and living in those streets uncomfortable
• Electric cars seem eco-friendly while in use, but their batteries and sophisticated electronic components have a dramatic negative impact on the environment - both before and after the vehicle's lifespan.

The standard part of design practice should be thinking about long-term consequences of the solution. The designer should imagine how the product will impact the users' life other than what is planned? What are secondary and tertiary impacts on users' life? What is its impact to the environment and on third parties who never intended to interact with it?

Then comes the obsolescence. What is products lifetime? When the product will become obsolete? What happens after that? Is there a elaborate strategy for product disposal, be it digital or physical?

One way to overcome unintentionality in design is to conduct premortem sessions, to think about the possible consequences and edge cases and bad things that could happen after the design has been deployed. In some cases, you can even think one year after the deployment, or five years after you have deployed the project, and brainstorm bad outcomes.

A premortem proactively identifies the project risks and addresses them before they happen.

Evergreen design prioritize long-term consequences over short-term gains.

The way agile is implemented in organizations has eroded the quality of products: 2-week sprints are often focused on outputs and not on understanding. The resulting outcomes are then less likely to deliver desired value to the customer. Products are shipped without understanding of users' mental model, their intention, their goals, their contexts of use, their journeys. It's easier to focus on outputs, we have many tools to support that. But that's not better.

Product design process should start with abstraction layer.

Believe it or not, this chart from "Elements of user experience" is more than 25 years old. The original idea holds strong: you cannot design without understanding. First build conceptual knowledge. Only then you move forward with outputs.

Alas, most of "popular" design methods ^[1] are focused on processes, workflows, pipelines. There, output conquers understanding and becomes the primary building block for design.

Focusing on drawing tools for design is wrong. A designer conceive a solution before opening design software: on a meeting with a stakeholders, when reading research papers, in his head while thinking about solutions, during flow sketching. Design tool is meant for documenting design decisions. Design actually happens earlier in the pipeline.

It's design fundamentalism to lament that only one tool is worth working in, that anything else is bloat.

Design is a manipulation. Here is one example: Texas highways have speed limits of 70 mph. To reduce car accidents, the authorities employed architects to devise a solution. They decided to change the perception of a speed during driving. First, they designed lines across the road that gradually got closer together, making drivers feel like they were speeding up; next, they planted more trees next to the road, that gave the impression of narrower lanes and higher speed than actual.

All this caused drivers to slow down, resulting in 46% decrease in crash rate.

In this example, a designer cleverly manipulated drivers' cognition to make them aware that they were speeding.

Alas, not all design manipulations are for a good cause. Look no further than casinos where whole buildings and surrounding areas are planned and built for exploiting mere humans.

I frequently hear about doing "guerilla research" by intercepting random strangers in cafes, offering them a drink in exchange for the conversation about your very product. This is wrong on many levels:

• There is a low probability that the stranger belongs to your target user group (except if you are developing next social network or search engine that will rule the world - which you, probably, are not doing).
• Assume you are testing a consumer mobile app and need a feedback. The real context of usage is not interrogation in a cafe and simulating some "user tasks", fully concentrated. The more likely usage is with divided attention under suboptimal conditions, with the smudged screen filled with notifications while listening to loud techno music.
• It's even worse if you are researching B2B app. The real B2B context of use is in the open office, where your fellows are calling you on the phone, someone is tapping you on the shoulder asking for a favor, urgent emails are arriving at the pace of instant messages and you have your laptop docked to two large monitors while one doesn't work.
• And - let's be real: what is stranger's motivation for a sincere and deliberate response, beside getting a free flat white?

I should put /s at the end of this rant so you got the point. But with or without sarcasm the research IS expensive, and the research outside the real context is BOTH expensive and pointless.

There are better ways to understand your users and their use cases. Shadowing. Mental models. Follow-me-home research technique. Think-aloud. Contextual inquiries. Diary studies. And many more! All of them require effort and direct human to human communication. There is no substitute for it.

No LLM will replace research with real users.

Nor a casual, comfortable interview in a shiny neighbour cafe.

Designers frequently under-appreciate the factor of speed in the overall user experience of their products. But in my career I have never seen any user complaining that their site or product is too-fast.

However, vice versa is true: you can design the most elaborated user flows and detailed UX screens in the world, but if the product is generally sluggish then you are screwed. Slowness erodes the overall experience and gives the impression of a low-quality product.

Computer manufacturers understand this well. They push mandatory operating system upgrades specifically to force users into buying new computers, since "old" computers become intolerably slow. But we already know that a computer cannot slow down spontaneously.

The users develop high expectations with every generation of digital products. What once was "normal speed" is today considered "slow", even "unbearable". It's easy to get used to better and become intolerant of any friction.

There is one catch to this rule, though: the product should always signal its current internal state, especially when the operation performed is critical, such as "document is saved" or "security check is done". The user sometimes misses important system notifications because the operation finished immediately. In this situation, they become suspicious of the system's accuracy, which reduces the overall experience of the system. It is a rare case of a user doubting because the response was "too fast".

So when in doubt, build for speed while keeping user informed! This is a no-brainer.

Here is a video of a presentation about UX and performance, organized by Practical UX Meetup group: How performance affects UX of the webpage and what we can do to improve it? -Practical UX Meetup #16 (Youtube)

As designers, we are faced with subjectivity every time when collecting feedback. This is default and natural human behaviour.

This is also a sign of us asking for product feedback in a wrong way.

Customer feedback is an opinion; it is not a demand^[1]. The final decision about which feedback should be implemented into a product is a task for a product designer.

Everyone express their opinion when using the product. This is a natural human behaviour, because the interface IS the product for most of the users. Also people frequently judge design by aesthetics and believe that visually attractive products are also easy to use.

It's on designer to ask for exact, structured product feedback. To provide a corrective framework for useful, constructive responses that contribute to the research, rather than just collecting opinions.

So how do we do that? The basic example is to ask "How does (X) deliver value to the customers?" instead of "What do you think?" The idea is to aim for a reflection rather than for the opinion.

Another way to go is to develop a culture of stating hypothesis, and to try to disprove it during collecting feedback, in the same way as scientists do. It is not easy to establish this ritual, but it pays off in the long run; you will harvest high quality, structured and constructive feedback.

And what if we doubt the stakeholder answer? The more continuous research we do in a project, the more accurate answers will eventually pile up.

Your audience has the answers you need, not the ones you want. Your goal is to recognise the difference, and to distinguish between those two.

This note is inspired by those authors:

Designs without user feedback are just expensive art projects. -Jon Balboa, LinkedIn

Opinion is the weakest form of user data. -Jared Spool

Design without feedback is theater. -Pavel Samsonov, Product Picnic

Your audience has the answers you need, not the ones you want. -Rob Fitzpatrick, Author of "Mom test"

Customer feedback is an opinion; it is not a demand. -Jason Fried, It doesn't need to be crazy at work

Here are some common issues in the design process from my career:

Stakeholders not included a designer (me) in product-related discussions. "In a product startup, every conversation is a product-related discussion," some may argue. This means that every conversation is important, which is not true. I am talking about something different; the substantial product decisions should be debated with the whole product team. However, many business stakeholders cannot easily distinguish what is important from what is not. The aftermath is that designers are frequently excluded from the conversation around crucial product decisions.

I miscalculated time needed needed for a design project. This happened A LOT of times. Either I did not spent enough time on a discovery session, or I underestimated the scope of the project, or some other project instantly appeared on my schedule... It was all mine fault, without discussion. There is a common saying among project managers that final project estimation should be always doubled; I may adopt it, who knows?

Changing the scope in the middle of the project. "Can you put the garage where we planned bathroom to be?" is a commonly quoted joke among architects. It could be easily applied in digital product design. Some "quick adjusts" that client devised during morning coffee could easily extend the project timeline for months, if not indefinitely.

I worked alone instead of working with the whole product team. Frequently I drained my energy, losing momentum and only working from meeting to meeting, without continuous pace. Instead, the model that I accepted is working through half-day or whole-day workshops, building understanding the problem statement together with the team, making stuff together. Daily team working sessions would help, at least for a couple of hours.

"My computer is slowing down!" - I frequently hear that from my friends. This is also a common theme among computer service technicians, across tech support teams, and on the internet forums.

The complaint is reasonable. The perceived speed of the system, the responsiveness, waiting for boot - everything seems to be slower after a while.

But, let's make a parallel: imagine your TV set deteriorate over time, making the picture smudgy or pixelized or just less bright over time? Or your oven cannot bake as it used to do before? Or your car just reduce maximum speed by 10% after each year of use?

Now, this must be irrational. Machines cannot automatically decline over time! Their characteristics stay the same (except if there an obvious malfunction). Machines cannot rot!

The truth is that a computer cannot magically slow down overnight. The processor frequency maintains the same number of ticks per second. It's software that is faulty. It's the constant updates, the need to support both new and legacy hardware, the tech debt, the support for older operating systems: those are the real culprits.

There is also another strong motive by companies, a need to deliberately slow down software, to fabricate the need to buy new software and hardware. So the consequence of "My computer is slowing down" is "I need a new computer". This is simply not true.

These are the computers used on the space station. Their software could not be updated, except maybe through periodical manual installations through external disc.

You might think of this as an extreme example; but the guys working on those machines are professionals that need their job to be done. They do not need expensive over-the-air updates that make a burden on their computers. They use local computer storage to store and load data, as it was meant to be when computers were invented. If they can successfully operate their computers without updates, why can't we?

Computers are already overpowered; it's the deliberate decision of software makers to slow them down with each update, eventually considering the machines obsolete. For example, a typical lifecycle of the corporate laptop is 3 (three!) years. You then throw away your "old" laptop and get a newer version with fresh installation, forgetting that each laptop has half of the periodic table's rare elements inside it, that will go into landfill.

Keep your computer with you as long as possible. Install free software, such as Linux. You will be surprised how stable and quick your "obsolete" suddenly becomes.

Design interview questions that test problem-solving, not tool proficiency

I recently wrote about design interview questions and how the proactive designer should first respond with questions, rather than just start drawing rectangles. I also addressed why doing fake design projects is a bad idea.

Here are some ideas for design interview questions which should spark candidate's creative thinking, and get them out of their comfort zone of drawing with mouse or prompts; they are tool-agnostic, focused on understanding, problem solving and thinking process, rather than on pure decoration:

• Design the interaction for navigating the map on a smartwatch. The constraint is that only two physical buttons are available on the smartwatch for desired task, and there is no touchscreen.
• Design a conversation flow for booking the hospital appointment for use with a voice chatbot. The target users are elderly people, not familiar with technology, who are expected to anthropomorphise the chatbot.
• Design space-efficient packaging for the desk components, and step-by-step user manual for assembly the work desk. The expectation is that users are not familiar with manual assembly, and that components should be taken out of the packaging in the certain order

These are really real world design examples. Now the designer counter-argument would be: "I will never face those kind of tasks in my career!" - but we quickly realize this commentary is irrelevant.

The point of these exercises is to understand candidate's thinking process and creative problem solving, which is actually what design is all about.

Advise to aspiring young designers: stop doing fake projects. Putting yourself into imaginary business situation with fictional users and personnas will do little good for you. In my opinion, doing fake projects is a wasted time.

This trend started with design bootcamps. The typical design bootcamp project starts by assigning the fictional business case to the designer, usually in the area of food delivery or real estate business (make new and beter Airbnb!) or inventing a new taxi application.

Yet another food delivery application. Yet another taxi booking system. Yet another real estate renting platform.

I wonder why course authors chose such boring tasks, the problems that already solved by many great designers before? Why don't the course authors be more creative, and give some interesting tasks, such as reinventing digital classroom system, or helping elderly people explore new theatre performances, or reduce waiting in hospitals ? How about helping small business moving their offers from offline to online? Or take any area of accessibility and improve it? These are all real world problems, not fictional ones.

If the young designer do not have ideas for real-world products, I recommend doing product teardowns instead. Take any product on the market and reverse engineer it. Investigate it. Find out what were decisions and compromises made during product construction. What was designers intention. What was her thought process.

Product teardowns are part of the regular practice of the professional designer. It's done intensively during competitive research, as a part of a design project preparation. So doing it as a ritual will provide a double benefit to young designers: they will develop a "thinking eye" for design details and recognize design excellence; they will sharpen their analytical skills and improve their critical thinking.

The advantage of digital products over physical products is in their fleeting nature, their impermanence, that they could be continuously improved and become increasingly better. Digital products are the perfect creations that could be upgraded incrementally; after the change, a designer can test the results, apply the learned principles in the new version, and repeat.

The advantage of incremental design improvements over one radical redesign shot is best illustrated by the example of engineer Paul MacCready. In 1977 he triumphed in a competition for making a human-powered airplane. He made the vehicle out of aluminium tubing, plastic foam, piano wire, bicycle parts, and a polyester foil - within only six (!) months of experimenting. It's worth noting that he was the first to win the competition: no one won the competition for 18 years. He figured out that the problem was the design process itself: every other engineer was preparing and testing only one prototype for the competition, whereas MacCready usually tested multiple prototypes in a day, checking the outcomes and improving the design. We can notice a similarity with the digital design process here.

As digital designers we should appreciate the luxury of the medium. It has the potential of neverending improvements of our work, exactly the opposite from a goldsmith or a stone cutter. We can infinitely update, iterate and improve the quality of our digital creations.

"You push the button, we do the rest". This was once the slogan of the famous Kodak company. They wanted to convince buyers how easy their devices were to operate.

The first button was invented to trigger mechanical devices, and then its application evolved toward electric and digital machines. It is such a powerful invention that abstracts and hides all the complexity of the device mechanism, making people feel powerful and augmenting their capabilities. At the same time, it conveyed the illusory idea of simplicity.

When the button-operated devices reached a wider audience, in the early days people were projecting about catastrophical global human atrophy since everyone would just push buttons and not do much more. There was also concern that making a technology "invisible" - a "black box", so to speak - would make repair impossible. Alas, this is exactly what is happening now. We don't even try to fix our tools anymore, whereas through history humans were making and fixing their own tools.

Certainly, there is a strong argument that early human tools were primitive and without the many layers of abstraction of contemporary devices. However, my standpoint is that we can reconcile those two extremes: simple tools with little or no maintenance with modern complex devices. There are companies that make electronic devices repairable and user-maintainable, and they represent a computer as a barebone mechanical motor, making it more understandable. They offer longer warranty, use widespread spare parts, even provide maintenance training and service manuals.

The big reason why simple but hard to fix devices prevail is because of current market conditions. "Simple but wrong" is always an easier sell than "complex but right". For example, in the 70s Apple computers had special "Dealer mode" that made computers act differently in the showroom than in the buyer's home. It's easy to set up computers to do that. But early adopters eventually figured out the complexities of the computer interface due to their enthusiasm and recognition of the potential of the computer.

When interviewing for a design position, I expect a candidate to ask many questions before starting to go into solution.

Focusing on output too early in the design process usually leads to a suboptimal solution, a "local maximum" so to speak, given the designer's limited knowledge about the business problem.

Designers love the romance of the medium. Yet the designer's first duty is to go find out what to design by performing just enough research.

My favourite definitions of design is by Jared Spool: "Design is rendering of intent". But how would you render the intent if you don't know what it is? A design starts by getting enough information: call it "research", "product discovery", "open conversations", "questionnaire", "design workshop" - do it remotely or in direct conversation, use Zoom, Slack or smoke signals. It doesn't matter, as long as you collect enough information about the problem.

And you know you've collected "enough" information when you present your understanding of the problem to the customer. It can be in an hour, in a week, in a month or longer - depending on the complexity of the problem. Only after that do you start to design. Slow down earlier to speed up later. Otherwise you will come up with the perfectly crafted product that no one will use since there is no utility nor value in it.

At the end of the day, design is communication, not decoration.

That morning I learned: The best meetings start with a disaster you barely survive.

It was one of many sunny days in San Francisco, more than 10 years ago. I went to a UX conference nearby and used the opportunity to meet with a client.

I walked into the lobby and asked for the person waiting for me. The receptionist told me that she would come in a couple of minutes. It was a pleasant sunny morning; the building was on the main street with a great landscape view. I took a selfie there.

And then - the catastrophe happened. While waiting for the manager, I accidentally spilled my half-liter coffee all over the desk and the floor. You cannot imagine how it looked - it was all clean until then, and suddenly the smell of coffee filled the room. And the manager was coming in a minute!

I was desperately looking for a solution, a quick solution... Eventually, I found a pile of paper towels behind me and started to quickly wipe away the coffee, nervously tossing the used towels in the basket.

...I saw her approaching through the glass window near the room, but luckily she was looking at her phone and the room was looong - I was halfway done cleaning the whole room. I sped up, and when she opened the door, I had the last bit of sweeping to do, hid my hand behind my back, and at the same time - held out my other hand to shake hands and introduce myself.

She was at the time responsible for the product we'd worked on together and was the decision maker. I was just one of many contractors, working with her for the first time. There was simply no room for mistakes, especially not an accidentally spilled coffee all over the entrance area.

Luckily for me, I managed to clean up my mess in time. Doing that distracted me from thinking about what I had to say and how. I was speaking from the heart and straightforwardly, with my heart pumping strongly. I was impressed by the product, talked enthusiastically, and I think I made a good impact. That was a good start. They decided to work with me, and continued for many years to come.

I love drinking coffee. It helped me focus that day, just not the way it usually does.

She only commented, "Can you smell coffee in the air?" while we were leaving the room... ✌️

September 3, 1967 was the day every Swedish driver had to relearn how to drive. Here is how the streets looked on the day when Sweden switched from driving on the left side of the road to the right side of the road:

This is what radical redesign looks like in practice. This confusion is inherent to how humans process change.

The big redesign ruins functional layer in customer eyes in case it is done all at once.

But not every redesign should be revolutionary, nor dramatic. For example, recent Wikipedia’s redesign is barely noticeable, and that’s the point.

Most redesigns nowadays are trying to be "innovative", "different" - just because they are called "re-design". But this misses the point: successful redesign is supposed not to be substantial. It should lean toward the functional aspect of the product, toward "tweaks" and fixes, rather than "complete overhaul".

When you redesign, you force users to change their habits. And people hate changing habits, because it is hard. If you force people to change their habits, it results in a mess.

Don't redesign for the redesign sake - solve business and user's problems instead.

Here is a powerful example where adding a feature actually leads to a positive outcome for the users. This one comes from a real-life case that relates to a non-digital product. It's a strong lesson in product design.

The other day, I stumbled upon the mess in front of my garage door that led to the car elevator. There were three cars waiting to enter. The car elevator is slow, and the street is narrow with no place to park. As a driver, you wish your car elevator to be instantly present so you don't have to wait on the street when you park.

The issue is that the elevator usually takes one minute to lift up from the underground.

I called the maintenance technician, complaining about the issue. He proposed a fantastic yet simple solution:

"Why don't we program the elevator so that it lifts up automatically a few minutes after the car is parked in the garage? By doing that, drivers won't have to wait for it on the street. This will solve the issue."

I agreed. Guess what? The jam on the street disappeared on the day when this simple "feature" was added to the elevator operating system.

Lesson learned: A well-planned feature will actually improve users' lives. It could come from research, from tacit knowledge, from experience, but it could never come from a business stakeholder wishlist.

When designing a product, try to map every feature to user value (or better, to multiple values). Features are means, not ends. They fail miserably when features become the goal themselves.

Provocative ideas about humanizing technology

• Why can't I put margin notes to myself on a webpage, PDF, or any other kind of document that I read?
• Why can't I annotate ANY file?
• Why can't I put comments in a YouTube video directly?
• Why can't I tag webpages, emails, files, everything on my computer, in the same manner and in a single place? I want to be able to centralize my activities and to search all artefacts and activities on my computers through tags.
• I cannot connect two windows. For example, I would like to draw a line between one window and another window.
• There is no global UNDO function in the operating system.
• I cannot customize nor change the interface of any of the applications, nor the operating system, in the way I want.
• I cannot interchange data from application to application. I am actually a prisoner in each application. I want applications to disappear. It's confusing to have a text editor containing a simple graphics editor sitting next to a graphics editor containing a dumbed-down text editor.
• Why can't I see immediately if a person is on vacation when starting to compose mail, or when calling or texting him/her?
• Why cannot software remind me of useful features I'm not using? For example: I browse a lot, and having 4 browser windows with 50+ tabs each easily becomes a mess. My browser should observe my behaviour and suggest another, better way to organize my tabs e.g. to pin certain tabs, based on how frequently I open the same sites every day, or use "stackable" web pages if I have more than 3 tabs opened for the same website.
• Why can't I connect my supercomputer to a monitor and keyboard? By supercomputer I mean my iPhone. I have a supercomputer in my pocket and I cannot connect it to an external keyboard and screen. Today everyone has supercomputers with them that are unable to connect to a keyboard and external screen.

A proposal for operating system that maximize human potential.

1. HumaneOS prioritise universal ethical values
2. HumaneOS respect human attention
3. HumaneOS utilize serendipity
4. HumaneOS supports all human attributes
5. HumaneOS utilise positive aspects of computers
6. HumaneOS is modeless
7. HumaneOs is non-trivial and anti-intuitive
8. HumaneOS is a second-class citizen
9. HumaneOS transparently pushes humans forward to the the values they choose
10. HumaneOS cooperate, not compete

Download Presentation Slides (PDF, ~40MB)