I have this mantra. It's called, "If a schedule is long, it's wrong. If it's tight, it's right." And I've just, basically just go recursive improvement on schedule, with feedback loop. "Did this make it go faster? OK. If it didn't, we're going to need to fix it." If the design takes a long time to build, it's the wrong design. This is the fundamental thing. Over and over, the tendency is to complicate things. And I have another thing which is, the best part is no part. The best process is no process. It weighs nothing, costs nothing, can't go wrong. So, as obvious as that sounds, the best part is no part. The thing I'm most impressed with, when I have the design meetings at SpaceX, is "What did you undesign?" Undesigning is the best thing. Just delete it. That's the best thing.
So step one, make your requirements less dumb. Step two, delete the part or process step. If you're not deleting a part or process step at least 10% of the time, basically if you're not adding things back in 10% of the time, you're clearly not deleting enough. And then only the third step is simplify or optimize. The third step. Not the first step. The reason it's the third step is because it's very common, possibly the most common error of a smart engineer is to optimize the thing that should not exist.
Well, everyone has been trained in high school and college, that you've gotta answer the question. Convergent logic. So you can't tell a professor, your question is dumb. You will get a bad grade. You have to answer the question. So everyone is basically without knowing it, they've got like mental straight jacket on. That is, they'll work on optimizing the thing that should simply not exist.
Finally, you get to step four, which is accelerate cycle time. You're moving too slowly, go faster. But don't go faster until you've worked on the other three things first. If you're digging and you're grave, don't dig it faster. Stop digging your grave.
And then the final step is automate.
I think currently manufacturing is underrated and design is overrated. So people generally think that, like this Eureka moment, like you come up with this idea and that's it, now it it's good. But the design like this, literally a thousand percent, maybe ten thousand percent more work that goes into the production system than the thing itself.
If people have not been in manufacturing, especially manufacturing of something that's relatively new, then they don't understand. And they think the design is the hard part, and they think production is like a copier or something like that.
Humanity will become a multi-planet species, if we get cost per ton to orbit to the point where we can afford to become a space race civilization and a multiplanet species.
All designs are wrong, it's just a matter of how wrong.
First make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you. It's particularly dangerous if a smart person gave you the requirements, because you might not question them enough. ... Everyone's wrong, no matter who you are, everyone's wrong some of the time. So make requirements less dumb, then try very hard to delete the part or process. This is actually very important. If you're not occasionally adding things back in, you are not deleting enough. The bias tends to be very strongly towards, let's add this part of the process step in case we need it. But you can basically make in case arguments for so many things.
Whatever requirement or constraint you have, it must come with a name, not a department. Because you can't ask the departments, you have to ask a person. And that person who's putting forward the requirement or constraint must agree that they must take responsibility for that requirement.
“Get in over your head as often and as joyfully as possible.”
How well we communicate is determined not by how well we say things, but how well we are understood
Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.
“The soul never thinks without an image.”
“We are what we repeatedly do. Excellence, then, is not an act, but a habit.”
For example, when designing digital forms, using button and input fields patterns will improve familiarity and consistency, without a doubt. However, there is no magic formula for the order in which questions on a form should be presented or for how to word them. To best solve for a user’s needs, an understanding of their goals and constraints is essential. Patterns can even cause harm without considering a user’s context and the bearing it may have on their decision-making process.
A design pattern library can range from being thorough, trying to cover all the bases, to politely broad, so as to not step on the toes of a design team. But patterns should never sacrifice user context for efficiency and consistency. They should reinforce the importance of the design process while helping an organization think more broadly about its users’ needs and its own goals. Real-world problems rarely are solved with out-of-the-box solutions. Even in service design.
“Recognizing the need is the primary condition for design.”
“The details are not the details. They make the design.”
I don’t know how my mind dysfunctions. But most of the time when someone gives me a rule, I automatically question it or try to break it. This isn’t always true. Early in my career, I would follow the rules of UX to a tee. I didn’t know any better and was too green to have experiences where the rules didn’t work or to know they weren’t applicable to the situation.
Christensen also cites the importance of "purpose branding"—building an entire brand around a particular job-to-be-done. Quite simply, purpose branding involves naming the product after the purpose it serves.
“Design is more important than technology in most consumer applications.”
It is not enough that we build products that function, that are understandable and usable, we also need to build products that bring joy and excitement, pleasure and fun, and, yes, beauty to people’s lives.
I have complaints about the education our designers get. There are two ways of approaching UX design teaching, and neither of them is satisfactory. One, you come out of a traditional design school, and those are typically art based and concerned about beauty and emotional impact. That’s very important, but they don’t learn the underlying theory and understanding of people’s behavior that’s so necessary. The other school comes from the field of human-computer interaction. Today, it’s mostly computer scientists, and they do understand the fundamental theory, but they’re not very good designers. Most are not capable of making an emotionally pleasing, delightful experience. They can make things that are understandable. What we need to do is combine these new skills, or at least have them work as a team. Designs are not done by single people, they’re done by teams. You need to work with others who bring in different points of view and skills. Watch people do the task you’re trying to support, and support the whole task. If I support the task well, and I don’t do some of the details well, or a bit clumsily, it’s okay. It’s far better to support the task and mess up a little on the details, than it is to get all the details right and not support the task.
Poor discoverability can affect both of these gulfs. When users can't easily find or understand features, the gulf of evaluation widens. Similarly, when the means to execute actions are not clear or discoverable, the gulf of execution expands. This can lead to user frustration, inefficient use of the system, and potentially, abandonment of certain features or the entire system. Moreover, as we saw earlier, discoverability is not just about initial use but also encompasses how easily users can find new features or information they haven't previously encountered. This ongoing process of discovery is crucial for users to fully leverage a system's capabilities over time, continually bridging both gulfs as they explore and use the system.
Learnability: While often discussed alongside discoverability, learnability is a distinct concept. Discoverability focuses on how easily users can find and recognise features or functionalities within a system, both during initial use and ongoing interaction. Learnability, as described by Grossman et al. (2009), refers to the ease with which users can understand how to use discovered features and become proficient with them over time. In essence, discoverability is about finding what's possible, while learnability is about mastering what's been found.
“Design isn’t crafting a beautiful textured button with breathtaking animation. It’s figuring out if there’s a way to get rid of the button altogether.”
“Any intelligent fool can make things bigger and more complex. It takes a touch of genius—and a lot of courage—to move in the opposite direction.”
“Any product that needs a manual to work is broken.”
As AI expands the number of ideas a team can generate, taste becomes the editor, the sense of discernment that’s innately human. AI can follow rules, enforce consistency, and even spot visual irregularities, but it can’t weigh which of two technically correct solutions creates the most trust or delight.
Taste is knowing what to prioritize when time is limited, like the Duolingo Math team did by polishing core interactions instead of adding extra features when testing new math games. It’s knowing when to stop tinkering and ship it—even if it feels like there are endless refinements you could make. As Sarah puts it, “Real taste hurts. If your ‘taste’ doesn’t cost you something, it’s not taste. It’s preference.”
Every practice has a set of rules which governs it. Mastery occurs with the realization of these rules. Innovation occurs at the point of intelligent and creative rebellion against them.
“There’s the whole Buddhist thing about the essence of a bowl being its emptiness—that’s why it’s useful. Its emptiness allows it to hold something. I guess that means that design must talk about something else. If you make design about design, you’re just stacking bowls, and that’s not what bowls are for.”
You don’t think your way to creative work. You work your way to creative thinking.
No. I don’t think the Empire had Wookiees in mind when they designed it, Chewie.
Flat design, especially when combined with strategic minimalism, can be a powerful aesthetic tool. It can convey a sense of luxury or trendiness, and in some cases can be used to appeal to young adult users. It’s a lightweight UI, and can be easier to support across a range of device sizes.
Unfortunately, flat design has a major flaw: it often leads to click uncertainty and decreased user efficiency. When designers flatten the UI, they tend to remove many signifiers that normally tell users where to click.
Users often leave Web pages in 10–20 seconds, but pages with a clear value proposition can hold people's attention for much longer. To gain several minutes of user attention, you must clearly communicate your value proposition within 10 seconds.
Here are the questions you can use to qualify new features: Does this feature serve your exact ideal customer, or does it make your product interesting to new customer categories? Does this feature serve the user’s big goal, or does it add other goals to their plate (even if solved successfully)? Does this feature facilitate the user’s most important daily tasks, or does it add other tasks to their plate? Does this feature breed new objects to be managed with the app? Does this feature solve a pain, or does it merely add an extra layer of polish? What are the development and support (!) costs of building this feature? Can this feature be easily replaced by building an integration with another software product? What part of the existing user base will benefit from this new feature and start using it immediately?
Product Managers and Product Designers glorify our process for building products on Twitter, podcasts, and at conferences — but we should remember something important. Customers don’t actually care about how we build our products, or our process. Customers do not care about our Slack debates, our Jira tickets, or the compromises we make to our roadmap along the way. Customers only care about how our products feel in their hands, and nothing else. That moment when customers first open our apps and escape their reality for a few minutes as they discover something new — that is the moment that matters if you build products. We need to focus less on glorifying our process for everything we ‘product people’ do and focus more on what actually matters. What matters is that we build products that make customers smile and realize something new about themselves. What matters is that we build products that make life more fulfilling for billions of people by giving them access to education and new ideas. What matters is that we build products which make customers say: I honestly can’t imagine my life before I downloaded that app. We Product Managers spend our days writing specs, filing Jira tickets, and editing roadmaps. Process. Process. Process. What else could we have created instead of that perfect Gantt chart? Are there easy wins in our production apps that we could have discovered instead of seeking the perfect process? Can we think less about our perfect Product Manager workflows and think more about simplifying our products? Our job is to delight customers through the projects we build. Process is important, but do not forget that customers judge us on one thing. The product.
“Content precedes design. Design in the absence of content is not design, it’s decoration.”
The place to start the implementation is to list exactly what the user will do to achieve his or her goals and how the system will respond to each user action.
Because starting with copy focuses you on the customer and the dream product you’re creating for them. You’re not worried about which font you should use, the border radius on your dialogs, or the interaction convention of the week.
“The work you do while you procrastinate is probably the work you should be doing for the rest of your life.”
“Good design is obvious. Great design is transparent.”
When people don’t know what’s hidden in the nav they scroll the page to see if they can find what they’re looking for first. Opening a nav is a commitment. And what if when I open it I don’t find what I’m looking for? Research shows users would rather take their chances and scroll the page before diving into your hamburger nav.
There’s this fallacy that floats around the UX world telling everyone that less clicks means a better experience. And if users don’t have to click, well, then the person that created it must be some sort of UX god. Well, here’s the truth: Users won’t mind extra clicks as long as they’re meaningful.
It sounds counterintuitive, but you can reduce complexity by adding in a few extra meaningful clicks. Each tiny bite is much less of a cognitive load for your users than if you push everything on them up front. Make your experiences contextual-based and digestible, and no one will notice that it took them a few extra clicks—because it felt necessary.
Too many apps try to use animation as a band-aid for the poor experience they’ve created. Remember that animation is there to help explain what is happening, not entertain. You’re not making a Disney movie.
Design everything on the assumption that people are not heartless or stupid but marvelously capable, given the chance.
I have several times made a poor choice by avoiding a necessary confrontation.
“Simplicity is about subtracting the obvious and adding the meaningful.”
“As we decrease uncertainty, we give ourselves permission to increase fidelity.”
Why Hidden Navigation Is Less Effective Why does hidden navigation have these effects? Throughout the article, we hinted at several answers: Low salience: A small icon is harder to notice on a large screen size (and even on a smaller mobile one). Low information scent: The menu icon or label doesn’t usually tell people what’s inside it, so they have no idea if they’ll find what they need by clicking on it. Extra work: To figure out what’s inside the menu, people must expand it. That increases the interaction cost for users and makes them less likely to do it, or, if they do it, they may take longer. Lack of standards: Hidden navigation is implemented in different ways by different sites. Some sites use it, some don’t. On mobile, patterns are starting to form, but on desktop there is a lot of variability and inconsistency in the placement and the labeling of hidden navigation. Low familiarity: Especially on desktops, hiding navigation is not a common pattern and people may not expect to find global navigation under an expandable menu. Some people may also still be unfamiliar with the hamburger icon that is frequently used for such menus. This low familiarity is exacerbated by the lack of standards which reduce long-term learnability (as further discussed in our course on The Human Mind and Usability, learning is facilitated by repeated exposure to the same pattern.)
We can’t afford to do months of work only to find out the feature isn’t valuable to our customers. Doing customer research up front and then testing small feature rollouts allows us to tighten the feedback loop and make small adjustments to features before they’re complete.
“The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.”
Instead of thinking of design as a phase, which is mostly completed before you begin construction, you look at design as an on-going process that is interleaved with construction, testing, and even delivery. This is the contrast between planned and evolutionary design.
“A user interface is like a joke. If you have to explain it, it’s not that good.”
Styles come and go. Good design is a language, not a style.
Some design activities are for creating knowledge for the designer, other activities are for creating understanding for stakeholders, and others are for evaluating assumptions. Sometimes it’s better to hand dig and pan for gold before bringing in the bulldozer. What is the right method? Again — it depends on the project and how much investment you can afford for the results you need.
This first law is simply a question which sets a foundation for designers to intentionally choose a “design way” that is best for their organization: When do you pay for knowledge, and how much will it cost when you pay for it?
Where do new ideas come from? The answer is simple: differences. Creativity comes from unlikely juxtapositions.
“Less is more work.”
Should a logo be self-explanatory? It is only by association with a product, a service, a business, or a corporation that a logo takes on any real meaning. It derives its meaning and usefulness from the quality of that which it symbolizes. If a company is second rate, the logo will eventually be perceived as second rate. It is foolhardy to believe that a logo will do its job immediately, before an audience has been properly conditioned.
A logo does not sell (directly), it identifies.
I haven’t changed my mind about modernism from the first day I ever did it…. It means integrity; it means honesty; it means the absence of sentimentality and the absence of nostalgia; it means simplicity; it means clarity. That’s what modernism means to me…
Simplicity is not the goal. It is the by-product of a good idea and modest expectations.
“Practice safe design: Use a concept.”
If you think good design is expensive, you should look at the cost of bad design.
“Leave it better than you found it.”
“More interface” does not fix “bad interface”… it amplifies it.
The faster your product can show users that this is where they can find a path to a better version of themselves, the faster they integrate your product into their lives. This is why it's worth paying attention to how you order the steps in your onboarding flow. When you front-load it with user value, it can pay major dividends.
Momentum is a state of mind in which you feel that things are unstoppably going your way. Psychologists actually refer to it as a power -- when athletes feel it they perform better, when gamblers feel it they take bigger risks, and when you feel it doing household chores, psychologists Iso-Ahola and Dotson have observed, your home sparkles a little more. Momentum is built in wins. At least two in a row. Two consecutive wins, and you're on a "hot streak": the task you're performing suddenly becomes easier and smoother.
The problem is that losing momentum feels terrible and is even worse for performance than no momentum. A task that the user has to "restart" is more demanding and difficult. And oscillating between losing and gaining momentum exponentially increases frustration. The idea, in essence, is simple: success breeds success — so if you want to set users up for success — get them there fast and keep the wins coming. If 10 steps make up your onboarding flow, how many quick wins are you giving users in the first five? Or the first three? How many can you cut out? How many can you postpone?
A rule of thumb that's proved useful in the past is this simple question: is the user actually better off for having made it through the onboarding flow?
If the user could see what their future would be like on the other side of your onboarding before they started signing up, would they want to switch places with that future self?
Activity and achievement are two different things. User actions only add value if they bring the user closer to what they're seeking. Put those steps first, and let their momentum carry the rest.
The difference between simplicity and ease Is difficulty a momentum killer? No. Maybe users have to do something difficult to find value, that might just be the nature of the problem you’re solving. The funny thing is it's difficulty that makes achievement feel good, so a challenging onboarding flow is okay!
The principle of gradual engagement suggests postponing registration or form filling to create a low barrier of entry into your product. Front-loading user value is coupling a low barrier for entry with an ordering of onboarding steps that builds momentum.
When you "prime" users for an ask, you're explaining two things: why you're asking for something and how responding will benefit them. Both have strategic underpinnings: Communicating why you need the access directs the user's attention to what you need from them to deliver value, building trust. Focusing on the benefit reminds them they signed up to receive that value, building motivation.
Asking for permission breaks up the onboarding flow. The more natural the ask, the less jarring it is.
Don't ask for permission to use the camera until you need to use it, in other words. If you wait to ask for access to the camera when the user is all set to take a picture, they won't think twice about giving it the go-ahead.
Success states have become synonymous with celebration, particularly in user onboarding. But the fact is that guiding a user through a complicated flow of actions with positive feedback is more than celebrating a milestone. It's expanding the first conversation that users have with your product.
In many workflows, a screen makes a demand of the user and when the user complies, the product moves on like nothing even happened. Taking a beat to verify that all is well can give the user 1) mental closure and 2) feedback that the product is listening and reacting.
Make them visual (confirmation and green go great together!) And immediate (don't wait until a user has finished filling out a form to let them know there's more password work to do.) Remember that it's a conversation (your user communicates in interactions, your product responds in success states)
A well-timed pat on the back can simply feel good to receive, especially when it's for a meaningful accomplishment. These success states are good ol' fashioned celebrations of progress.
Success states work best for achievements that are meaningful from a user's point of view—this way you're not celebrating their activity within the product, you're celebrating their taking another step towards a better version of themselves.
Save encouragement states for milestones. Empty praise usually erodes motivation instead of amplifying it. You can use success states to do more than one thing at a time: combine "encouragement" and "signpost" success states to celebrate users and steer them towards a follow-on activity.
“If you’re not prepared to be wrong, you’ll never come up with anything original.”
Inclusive design doesn't mean you're designing one thing for all people. You're designing a diversity of ways to participate so that everyone has a sense of belonging.
UI embellishments can only produce surface delight; deep delight can only be achieved in functional, reliable, and usable interfaces.
Deep delight is holistic, and is achieved once all user needs are met, including functionality, reliability, usability, and pleasurability. Users may have a poor experience on a site, and yet feel surface delight occasionally. But deep delight only occurs when the user has reached a state of “flow” — that is, immersed productivity without much distraction from the main task. In other words, deep delight is experienced when the interface behaves like a surgeon’s knowledgeable assistant: it hands all the right instruments exactly when they are needed, without getting in the way.
Accessible design isn't charity; it's just good design that benefits absolutely everyone.
Suddenly, all those design decisions that seemed reasonable when you had the eyes of a hawk feel like personal attacks on your dignity.
The beauty of accessible design is that it strips away the unnecessary complexity that users constantly get annoyed by, but generally put up with all the same. Adhering to these principles forces designers to think about the core functionality of the product or services, to prioritise what actually matters, and to create interfaces that work for humans rather than showing off how clever the design team is. Turns out, designing for seniors means designing for humans as a whole. What an utterly radical concept.
“I would be happy to learn just half the stuff I already thought I learned.”
Permission priming can help solve this problem by: Directing the user's awareness: Users know that a photo editing app needs camera access. Evidence shows that a reminder, directing the user's awareness to this fact, prepares them for the ask better. Tying access to value: Users sign up to do something specific. Let them know that you're only asking for access to help them achieve their goals.
The time it takes to make a decision increases as the number of alternatives increases.
Most design leaders, like John Maeda in his Design in Tech Report, argue that designers need to code in order to survive. But if you’re a young or aspiring designer, I’m here to tell you, to beg you, to ignore these people. Design is about people, not technology. In order to design great products, you need to understand not just what you’re making, but why you’re making it. You do that by empathizing with your customers to feel their pain, and designers are effective only after doing so.
The parallels between writing and designing are strongest when it comes to building context. Both require sensitivity to every plausible situation. Like writing, the design process considers varying levels of complexity in the context of use:
How does someone feel when they are using your product— not just during, but before and after.
Whether it’s in the form of personas, storyboards, journey maps or even a plain old written narrative, great designers start with clear, compelling narratives about the context of the customer’s problem they’re solving for.
Like storytelling, every design project has one or more protagonists, a setting, a plot, a conflict and a resolution.
What companies need now and in the near future are designers that are writers and storytellers. Good writing skills enable designers to tell a strong narrative of the customer in a holistic, memorable way. The result is thoughtful design; creating products that people love and can’t live without.
“ If we want users to like our software, we should design it to behave like a likevable person”
"Everything should be made as simple as possible, but not simpler"
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
“ Know the user, and you are not the user”
“ Like all forms of design, visual design is about problem solving, not about personal preference or unsupported opinion”
“ I prefer design by experts - by people who know what they are doing”
Photoshop is a privilege, not a right.
I love deadlines. I like the whooshing sound they make as they go by.
Good design must be defined by appropriateness to audience and goals, and by its effectiveness, not by its adherence to Swiss design or the number of awards it wins.
Our Heads Are Round so Our Thoughts Can Change Direction
I believe that everything has a grain, including the web.
“ You can use an eraser on the drafting table or a sledge hammer on the construction site”
Everybody’s a web designer until, you know, they actually try to do it.
Being a graphic designer gets you used to rejection of your brilliance. So it’s good practice for dating.
"If I asked people what they wanted, they would have said 'Faster Horses'."
If something’s hard to do, then it’s not worth doing.
Sometimes there is no need to be either clever or original.
People are on the Web not to enjoy your Web design, but to get something done.
We don’t get hired to make pretty things or win design awards. We get hired to solve business problems.
If you pay peanuts, you get monkeys.
Client: “My wife doesn’t like it”; Designer: “Well then, I don’t like your wife”
Great, I’m glad your UI doesn’t use tables. So what? Who cares if it still doesn’t let people achieve their goals.
Content precedes design. Design in the absence of content is not design, it's decoration.
“ As far as the customer is concerned, the interface is the product.”
Designing for clients that don’t appreciate the value of design is like buying new tires for a rental car.
If your UI even vaguely resembles an airplane cockpit, you’re doing it wrong.
I don’t care if you like it! I want to know if you understand it.
“Good” design means it is a) valuable: you’re solving a real problem for people b) easy to use: people find it understandable, accessible and fast c) well-crafted: the entire experience feels designed with thought and care.
If you cannot get a group of people for whom your product is designed for to generally agree that your design is good, it’s not good.
If you cannot get a group of designers to generally agree that your design is easy-to-use and well-crafted, then it isn’t.
The greatest frustration is feeling like you’re getting too much criticism from too many people (which, according to #2, means your design is not yet good). This is either because a) you’re working under too many constraints b) you’re not exploring solutions broadly enough, or c) the problem is beyond your current skill level.
Obviousness comes from conforming to people’s existing mental models. Don’t waste time reinventing common UI patterns or paradigms unless they are at least 2x better, or you have some critical brand reason to do so.
Better design does not mean more design. Often, the most obvious designs are invisible.
The Fire Department has traditionally considered architecture a priority only when it’s burning down.
The moment clients realize that revisions are not an all-you-can-eat buffet, suddenly they realize they are not hungry.
“Start your designing where users start their using.”
At the end of the day, pretty colors make people drool.
The 15 Rules Every UX Designer Should Know 1. UX is not (only) UI User Interface is a part of User Experience 2. Know your audience User research is a natural first step in the design process 3. You are not the user Testing with real users is an essential part of the design process 4. Adapt design for short attention spans Don’t overwhelm users with too much information 5. The UX process isn’t set in stone Adapt your design process for the product you design 6. Prototype before you build a real product The design phase for digital products should include a prototyping stage 7. Use real content when designing Avoid Lorem Ipsum and dummy placeholders 8. Keep things simple and consistent The hallmark of a great user interface is simplicity and consistency 9. Recognition over recall Showing users elements they can recognize improves usability versus needing to recall items from scratch 10. Make design usable and accessible Design for a diverse set of users that will interact with your products 11. Don’t try to solve a problem yourself Design is team sport — don’t work in isolation 12. Don’t try to solve everything at once Design is an iterative process 13. Preventing errors is better than fixing them Whenever possible, design products to keep potential errors to a minimum 14. Offer informative feedback An app or website should always keep users informed about what is going on 15. Avoid dramatic redesigns Remember Weber’s Law of Just Noticeable Differences
Because every person knows what he likes, every person thinks he is an expert on user interfaces.
Any system that sees aesthetics as irrelevant, that separates the artist from the product, that fragments the work of the individual, or creates by committee, or makes mincemeat of the creative process will in the long run diminish not only the product but the maker as well.
Know the ways that your users misinterpret your intent. Know that, to them, it is not misinterpretation.
For UI elements, being understood beats being sophisticated every time!
Design is like a mom, nobody notices when she’s around, but everybody misses her when she’s not.
If you dig a hole and it’s in the wrong place, digging it deeper isn’t going to help.
Bad design shouts at you. Good design is the silent seller.
Design is so critical it should be on the agenda of every meeting in every single department.
“ The joy of an early release lasts but a short time. The bitterness of an unusable system lasts for years”
"Never blame the user for what goes wrong"
In regards to User Experience - "Just because a website is usable, does not mean customers will use it."
I have this mantra. It's called, "If a schedule is long, it's wrong. If it's tight, it's right." And I've just, basically just go recursive improvement on schedule, with feedback loop. "Did this make it go faster? OK. If it didn't, we're going to need to fix it." If the design takes a long time to build, it's the wrong design. This is the fundamental thing. Over and over, the tendency is to complicate things. And I have another thing which is, the best part is no part. The best process is no process. It weighs nothing, costs nothing, can't go wrong. So, as obvious as that sounds, the best part is no part. The thing I'm most impressed with, when I have the design meetings at SpaceX, is "What did you undesign?" Undesigning is the best thing. Just delete it. That's the best thing.
Missing Reference