[{"id":"50559429-cc3f-41a7-968b-1745ac05c8e4","user_id":"5f89cef1-ab33-476b-b356-a26e67febbd8","question":"what is the empty state problem?","text":"The empty state problem is something every designer encounters - it's that moment when someone first opens your app or arrives at a screen with no content yet. The temptation is to just show a blank page or maybe throw up a tutorial, but that's often the wrong move.\n\n[When Vevo tested their intro tour, they found most people were just skipping through without reading any of the copy.](152ac583-79b8-45db-8738-64f94f1e3fdc) In a test with over 160,000 participants, getting rid of the tutorial actually increased the number of people who got into the app. More people completed sign-up too.\n\nThe real challenge is answering [\"What do I do now?\"](0653f3e7-5783-49be-984b-3756b7cfa5a4) for users while balancing their needs with business goals. Empty states shouldn't just be blank pages - they need to guide users on what to do next with a clear call to action, maintain context so people know where they are, and maybe use placeholder content to show what the page will look like when populated.\n\nThe key insight is you want to get people to your app's core value as quickly as possible. Instead of front-loading tutorials and explanations, teach in the moment when things are relevant. For example, in an app I worked on where you could vote on things by swiping, we only showed the \"swipe to skip\" tip after someone pulled up for more content - right when they'd actually use that gesture.\n\nEmpty states are really an opportunity. When designed thoughtfully, they can reduce confusion and encourage engagement with your product. But the goal is always the same: get people engaged with the actual product, not stuck in some pre-game show.","message":{"id": "50559429-cc3f-41a7-968b-1745ac05c8e4", "type": 0, "title": "what is the empty state problem?", "answer": "The empty state problem is something every designer encounters - it's that moment when someone first opens your app or arrives at a screen with no content yet. The temptation is to just show a blank page or maybe throw up a tutorial, but that's often the wrong move.\n\n[When Vevo tested their intro tour, they found most people were just skipping through without reading any of the copy.](152ac583-79b8-45db-8738-64f94f1e3fdc) In a test with over 160,000 participants, getting rid of the tutorial actually increased the number of people who got into the app. More people completed sign-up too.\n\nThe real challenge is answering [\"What do I do now?\"](0653f3e7-5783-49be-984b-3756b7cfa5a4) for users while balancing their needs with business goals. Empty states shouldn't just be blank pages - they need to guide users on what to do next with a clear call to action, maintain context so people know where they are, and maybe use placeholder content to show what the page will look like when populated.\n\nThe key insight is you want to get people to your app's core value as quickly as possible. Instead of front-loading tutorials and explanations, teach in the moment when things are relevant. For example, in an app I worked on where you could vote on things by swiping, we only showed the \"swipe to skip\" tip after someone pulled up for more content - right when they'd actually use that gesture.\n\nEmpty states are really an opportunity. When designed thoughtfully, they can reduce confusion and encourage engagement with your product. But the goal is always the same: get people engaged with the actual product, not stuck in some pre-game show.", "resources": [{"id": "0653f3e7-5783-49be-984b-3756b7cfa5a4", "url": "https://static.lukew.com/pageheirarchy_lukew.pdf", "date": 1167609600000, "page": 55, "type": 4, "title": "Web Application Page Hierarchy", "topics": ["Web application hierarchy", "Visual organization", "User needs", "Business goals", "Information organization"], "summary": "At Web Visions 2007, Luke Wroblewski emphasized the significance of web application page hierarchy for usability, priority reflection, and message communication. He highlighted the role of visual organization, interaction, and understanding perception in creating effective presentations. Wroblewski provided examples of good and bad hierarchies, and offered guidance on building effective ones and presenting data.", "filename": "pageheirarchy_lukew", "pageImage": "https://qrmsyiqritqdkspkjoqy.supabase.co/storage/v1/object/public/lukew-media/pdf-pages/pageheirarchy_lukew/54.png", "coverImage": "https://qrmsyiqritqdkspkjoqy.supabase.co/storage/v1/object/public/lukew-media/pdf-images/pageheirarchy_lukew.png"}, {"id": "152ac583-79b8-45db-8738-64f94f1e3fdc", "url": "https://www.lukew.com/ff/entry.asp?1906=", "type": 1, "title": "Design Solutions for New Log In Problems", "summary": "Third-party sign-in solutions like Open ID, Facebook, Twitter, and more have tried to fix some of the issues of forgotten passwords and accounts by cutting down on the number of sign-in details people need to remember across the web. However, with these new benefits come new problems as well. Most notably, people forget which account provider they used to sign up for a site, which makes them unsure about how to proceed. In an attempt to solve some of these new sign-in issues, Bagcheck has been experimenting with a few new login screen designs. The latest design requires people to enter their name (or email address) in order to sign in. Once again, instant search results are used to match them to an existing user. This time, however, the options they have for signing in are not revealed until they select their name or enter their email address.", "entities": [], "metadata": {"tags": ["Data Monday: Login & Passwords", "Data Monday: Top Three Passwords", "Web Application Form Layout", "forms", "login"], "title": "LukeW | Design Solutions for New Log In Problems", "author": "Luke Wroblewski", "longDate": "July 2011", "shortDate": "Jul 2011"}, "coverImage": "https://static.lukew.com/blog_signinbuttons_07052011.gif", "renderHtml": "

It used to be the biggest problem Log In pages faced were forgotten passwords and accounts. People would regularly forget the password or email address they used to sign up or mistakenly believe they either had an existing account or didn't have one.

\n\n

Just how bad was it? User Interface Engineering's analysis of a major online retailer found that 45% of all customers had multiple registrations in the system, 160,000 people requested passwords per day, and 75% of these people never completed the purchase they started once they requested their password. Ouch.

\n\n

Third Party Sign In

\"Single-sign on\" solutions like Open ID, Facebook, Twitter, and more have tried to fix some of these issues by cutting down on the number of Sign In details people need to remember across the Web. With these services, one account (usually consisting of email and password) can get you into many different Web sites.

\n\n

$\"Sign$

\n\n

Signing In is faster too. When someone connects their Facebook or Twitter account to a Web site, they simply need to click the Sign In with Facebook or Twitter button to log in. Of course, they need to be signed in with the account provider to have things work with one click. But since 50% of Facebook's 500 million active users log on to Facebook in any given day —odds are good one click is all it will take.

\n\n

So the Sign In screen on Bagcheck put one click login actions front and center to make signing in easier. It also allowed people to sign in using their email address and password if they preferred to (below).

\n\n

$\"Original$

\n\n

New Log In Problems

But with these new benefits come new problems as well. Most notably, people forget which account provider they used to sign up for a site, which makes them unsure about how to proceed. In the words of one of our friends on Bagcheck:\n\n

\"Whenever I have to sign into Bagcheck, I'm filled with anxiety. Not because I don't love the service, but because of the log in screen. I cannot remember whether I signed up through Facebook, Twitter or if I should know some special entry credentials.\"

\n\nThat's kind of the opposite of not making people think. Worse still, if someone picks the wrong provider instead of signing in they might end up signing up again and thereby creating a new account.\n\n

So while third party Sign In helps address some problems it also creates new ones. In an attempt to solve some of these new Sign In issues, we've been experimenting with a few new Log In screen designs on Bagcheck.

\n\n

Forgot How You Signed Up?

Our first design approach tried to keep things quick and easy for people who knew exactly how they signed up and also gave people who were unsure a way out. To do so, we presented a set of one-click Sign In buttons at the top of the Sign In screen and an input field that said \"Forgot how you signed up? Enter your name.\"

\n\n

$\"Version$

\n\n

When someone started typing their name, instant search results would show up highlighting Bagcheck members that matched what they typed.

\n\n

$\"Instant$

\n\n

Once you selected your name from the list, the page would hide any Sign In options that wouldn't work for your account leaving only the options that would. So if you could not sign in using Twitter, that Sign In button would disappear. We also included a little snippet of text that explicitly told you how you could Sign In. This was done to cover the case where someone could sign in using any provider since no options would be removed.

\n\n

$\"Hiding$

\n\n

While we liked the ability for people to recall how they signed up using the \"Forgot?\" text input, the rest of this design had some problems. It was strange how options above the text field would disappear and the fact we needed clarifying text to explain things told us the design was not there yet. Worst of all, we were still seeing people try to Sign In with accounts they had not yet connected to Bagcheck.

\n\n

First Enter Your Name

Our latest Sign In screen design is a bit more aggressive at preventing errors (at the expense of one-click sign in). In this design, people are required to enter their name (or email address) in order to sign in. Once again, we use instant search results to match them to an existing user. This time, however, the options they have for signing in are not revealed until they select their name or enter their email address.

\n\n

We allow people to find themselves using their email address as a way to cover multiple common names, and the off chance someone created an account with a variant of their name.

\n\n

$\"Version$

\n\n

In this design, people can no longer sign in with one click. But this may be a worthwhile trade-off because:

\n\n

We keep people signed in until they explicitly sign out. So hopefully people rarely need to go through the sign in process.
The amount of effort added to sign in is small —just start to type your name (or enter your complete email address), select a search result, then click a Sign In button. It's not one click but it's not a lot of work either.
It's no longer possible to try signing in with an account provider you have not set on Bagcheck because the login buttons don't show up until after you select your name.

\n\n\n

Design is Never Done

Though we've made some progress in tackling these new Log In issues, design is never done. Did we go too far toward error prevention? Is single-click sign in important enough to justify the occasional mistake? Are there other design options we should consider? We're happy to keep iterating so thanks for any ideas you have.

\n\n

UPDATE: Marty Moore created another design solution that also allows people to connect a new account or sign up using the same Log In screen.

", "textOnlyHtml": "It used to be the biggest problem Log In pages faced were forgotten passwords\nand accounts. People would regularly forget the password or email address they\nused to sign up or mistakenly believe they either had an existing account or\ndidn't have one.\n\nJust how bad was it? User Interface Engineering's analysis of a major online\nretailer found that 45% of all customers had multiple registrations in the\nsystem, 160,000 people requested passwords per day, and 75% of these people\nnever completed the purchase they started once they requested their password.\nOuch.\n\n\nTHIRD PARTY SIGN IN\n\n\"Single-sign on\" solutions like Open ID, Facebook, Twitter, and more have tried\nto fix some of these issues by cutting down on the number of Sign In details\npeople need to remember across the Web. With these services, one account\n(usually consisting of email and password) can get you into many different Web\nsites.\n\n\n\nSigning In is faster too. When someone connects their Facebook or Twitter\naccount to a Web site, they simply need to click the Sign In with Facebook or\nTwitter button to log in. Of course, they need to be signed in with the account\nprovider to have things work with one click. But since 50% of Facebook's 500\nmillion active users log on to Facebook in any given day —odds are good one\nclick is all it will take.\n\nSo the Sign In screen on Bagcheck put one click login actions front and center\nto make signing in easier. It also allowed people to sign in using their email\naddress and password if they preferred to (below).\n\n\n\n\nNEW LOG IN PROBLEMS\n\nBut with these new benefits come new problems as well. Most notably, people\nforget which account provider they used to sign up for a site, which makes them\nunsure about how to proceed. In the words of one of our friends on Bagcheck:\n\n> \"Whenever I have to sign into Bagcheck, I'm filled with anxiety. Not because I\n> don't love the service, but because of the log in screen. I cannot remember\n> whether I signed up through Facebook, Twitter or if I should know some special\n> entry credentials.\"\n\nThat's kind of the opposite of not making people think. Worse still, if someone\npicks the wrong provider instead of signing in they might end up signing up\nagain and thereby creating a new account.\n\nSo while third party Sign In helps address some problems it also creates new\nones. In an attempt to solve some of these new Sign In issues, we've been\nexperimenting with a few new Log In screen designs on Bagcheck.\n\n\nFORGOT HOW YOU SIGNED UP?\n\nOur first design approach tried to keep things quick and easy for people who\nknew exactly how they signed up and also gave people who were unsure a way out.\nTo do so, we presented a set of one-click Sign In buttons at the top of the Sign\nIn screen and an input field that said \"Forgot how you signed up? Enter your\nname.\"\n\n\n\nWhen someone started typing their name, instant search results would show up\nhighlighting Bagcheck members that matched what they typed.\n\n\n\nOnce you selected your name from the list, the page would hide any Sign In\noptions that wouldn't work for your account leaving only the options that would.\nSo if you could not sign in using Twitter, that Sign In button would disappear.\nWe also included a little snippet of text that explicitly told you how you could\nSign In. This was done to cover the case where someone could sign in using any\nprovider since no options would be removed.\n\n\n\nWhile we liked the ability for people to recall how they signed up using the\n\"Forgot?\" text input, the rest of this design had some problems. It was strange\nhow options above the text field would disappear and the fact we needed\nclarifying text to explain things told us the design was not there yet. Worst of\nall, we were still seeing people try to Sign In with accounts they had not yet\nconnected to Bagcheck.\n\n\nFIRST ENTER YOUR NAME\n\nOur latest Sign In screen design is a bit more aggressive at preventing errors\n(at the expense of one-click sign in). In this design, people are required to\nenter their name (or email address) in order to sign in. Once again, we use\ninstant search results to match them to an existing user. This time, however,\nthe options they have for signing in are not revealed until they select their\nname or enter their email address.\n\nWe allow people to find themselves using their email address as a way to cover\nmultiple common names, and the off chance someone created an account with a\nvariant of their name.\n\n\n\nIn this design, people can no longer sign in with one click. But this may be a\nworthwhile trade-off because:\n\n * We keep people signed in until they explicitly sign out. So hopefully people\n rarely need to go through the sign in process.\n * The amount of effort added to sign in is small —just start to type your name\n (or enter your complete email address), select a search result, then click a\n Sign In button. It's not one click but it's not a lot of work either.\n * It's no longer possible to try signing in with an account provider you have\n not set on Bagcheck because the login buttons don't show up until after you\n select your name.\n\n\nDESIGN IS NEVER DONE\n\nThough we've made some progress in tackling these new Log In issues, design is\nnever done. Did we go too far toward error prevention? Is single-click sign in\nimportant enough to justify the occasional mistake? Are there other design\noptions we should consider? We're happy to keep iterating so thanks for any\nideas you have.\n\nUPDATE: Marty Moore created another design solution that also allows people to\nconnect a new account or sign up using the same Log In screen."}], "openaiAnswer": "", "fromSuggestion": false, "backfillResources": [{"id": "29d912c2-fc80-49ac-af21-ebccab50093b", "url": "https://www.lukew.com/ff/entry.asp?2085", "type": 1, "title": "Chat Interfaces & Declaring Intent", "summary": "The article discusses the evolution of user interfaces (UI) and the role of AI in enhancing user experience. Initially, humans had to adapt to computer languages and commands. Google revolutionized this by introducing an open-ended search box, allowing users to express their intent. The advent of large-scale language models (LLMs) further expanded this concept, enabling information manipulation through chat interfaces. The next step was merging information retrieval with manipulation, as seen in applications like Ask Luke!, Perplexity, and ChatGPT. Today, AI models can find or even create the right action for a task, combining information and action retrieval and manipulation. Despite the complexity of these systems, the user interface remains a simple open text field. The author argues against adding more UI to communicate the possibilities of AI-driven systems, advocating for computers to understand human intent instead.", "entities": [], "metadata": {"tags": ["Early Glimpses of Really Personal Assistants", "Ask LukeW: Text Generation Differences", "Do All AI Models Need To Be Assistants?", "ai", "ai models", "user interface", "ai design", "chat"], "title": "LukeW | Chat Interfaces & Declaring Intent", "author": "Luke Wroblewski", "longDate": "February 3, 2025", "shortDate": "Feb 3, 2025"}, "coverImage": "https://static.lukew.com/google_textbox.png", "renderHtml": "

There's lots of debate within UI design circles about the explosion of chat interfaces driven by large-scale AI models. While there's certainly pros and cons to open text fields, one thing they are great at is capturing user intent. Which today's AI-driven systems can increasingly fulfill.

\n\n

At their inception, computers required humans to adapt to how they worked. Developers had to learn languages with sometimes punishing syntax (don't leave the semicolon out!). People needed to learn CLI commands like cd ls pwd and more. Even with graphical user interfaces (GUIS), we couldn't simply tell a computer what to do—we had to understand what computers could do and modify our behavior accordingly by clicking on windows, icons, menus, and more.

\n\n

$\"Google's$ \n

\n\n

Google changed this paradigm with a simple yet powerful way for people to declare their intent: an empty search box. Just type whatever you want into Google and it will find you relevant information in response. This open ended interface not only became hugely popular (close to 9 billion searches per day). It also created an enormous business for Google because matching people's expressed needs with businesses that can fulfill them monetizes extremely well.

\n\n

But Google's empty text box was limited to information retrieval.

\n\n

The emergence of large-scale language models (LLMs) expanded what an open-ended declaration of intent could do. Instead of information retrieval, LLMs enabled information manipulation through an empty text box often referred to as a \"chat interface\". People could now tell systems using natural language (and even misspellings) to summarize content, transform text into poetry, and generate or restructure information in countless ways. And once again this open-ended interface became hugely popular (ChatGPT has 300 million weekly actives since launching in 2022).

\n\n

The next logical step was combining these capabilities—merging information retrieval with manipulation, as seen in retrieval augmented generation RAG applications (like Ask Luke!), Perplexity, and ChatGPT with search integration.

\n\n

$\"ChatGPT's$ \n

\n\n

But finding and manipulating information is just a subset of the things computers allow us to do. An enormous set of computer applications exists to enable actions of all shapes and sizes from editing images to managing sales teams. Finding the right action amongst these capabilities requires remembering the app and how to access and use the feature.

\n\n

Increasingly, though, AI models can not only find the right action for a task, they can even create an action if it doesn't exist. Through tool use and tool synthesis, LLMs are continuously getting better at action retrieval and manipulation. So today's AI models can combine information retrieval and manipulation with action retrieval and manipulation.

\n\n

If that sounds like a mouthful, it is. But the user interface for these systems is still primarily an open text-field which allows people to declare their intent. What's changed dramatically is that today's technology can do so much more to fulfill that intent. With such vast and emergent capabilities, why do we want to constrain them with UI?

\n\n

We've moved from humans learning to speak computer to computers learning to understand humans and I, for one, don't want to go backwards, which is why I'm increasingly hesitant to add more UI to communicate the possibilities of AI-driven systems (despite 30 years of designing GUIs). Let's make the computers figure out what we want, not the other way around.

", "textOnlyHtml": "There's lots of debate within UI design circles about the explosion of chat\ninterfaces driven by large-scale AI models. While there's certainly pros and\ncons to open text fields, one thing they are great at is capturing user intent.\nWhich today's AI-driven systems can increasingly fulfill.\n\nAt their inception, computers required humans to adapt to how they worked.\nDevelopers had to learn languages with sometimes punishing syntax (don't leave\nthe semicolon out!). People needed to learn CLI commands like cd ls pwd and\nmore. Even with graphical user interfaces (GUIS), we couldn't simply tell a\ncomputer what to do—we had to understand what computers could do and modify our\nbehavior accordingly by clicking on windows, icons, menus, and more.\n\n\n\nGoogle changed this paradigm with a simple yet powerful way for people to\ndeclare their intent: an empty search box. Just type whatever you want into\nGoogle and it will find you relevant information in response. This open ended\ninterface not only became hugely popular (close to 9 billion searches per day).\nIt also created an enormous business for Google because matching people's\nexpressed needs with businesses that can fulfill them monetizes extremely well.\n\nBut Google's empty text box was limited to information retrieval.\n\nThe emergence of large-scale language models (LLMs) expanded what an open-ended\ndeclaration of intent could do. Instead of information retrieval, LLMs enabled\ninformation manipulation through an empty text box often referred to as a \"chat\ninterface\". People could now tell systems using natural language (and even\nmisspellings) to summarize content, transform text into poetry, and generate or\nrestructure information in countless ways. And once again this open-ended\ninterface became hugely popular (ChatGPT has 300 million weekly actives since\nlaunching in 2022).\n\nThe next logical step was combining these capabilities—merging information\nretrieval with manipulation, as seen in retrieval augmented generation RAG\napplications (like Ask Luke!), Perplexity, and ChatGPT with search integration.\n\n\n\nBut finding and manipulating information is just a subset of the things\ncomputers allow us to do. An enormous set of computer applications exists to\nenable actions of all shapes and sizes from editing images to managing sales\nteams. Finding the right action amongst these capabilities requires remembering\nthe app and how to access and use the feature.\n\nIncreasingly, though, AI models can not only find the right action for a task,\nthey can even create an action if it doesn't exist. Through tool use and tool\nsynthesis, LLMs are continuously getting better at action retrieval and\nmanipulation. So today's AI models can combine information retrieval and\nmanipulation with action retrieval and manipulation.\n\nIf that sounds like a mouthful, it is. But the user interface for these systems\nis still primarily an open text-field which allows people to declare their\nintent. What's changed dramatically is that today's technology can do so much\nmore to fulfill that intent. With such vast and emergent capabilities, why do we\nwant to constrain them with UI?\n\nWe've moved from humans learning to speak computer to computers learning to\nunderstand humans and I, for one, don't want to go backwards, which is why I'm\nincreasingly hesitant to add more UI to communicate the possibilities of\nAI-driven systems (despite 30 years of designing GUIs). Let's make the computers\nfigure out what we want, not the other way around."}, {"id": "824dbbf0-8138-49a0-a072-21b848fe0eb5", "url": "https://static.lukew.com/webforms_lukew.pdf", "date": 1199145600000, "page": 120, "type": 4, "title": "Best Practices for Web Form Design", "topics": ["Label tags", "Tabindex attribute", "Accesskey attribute", "Fieldset"], "summary": "Luke Wroblewski shares best practices for web form design, emphasizing its importance in online commerce, user participation, and data accumulation. He recommends minimizing the difficulty of form filling through smart defaults, inline validation, and forgiving inputs, and stresses the importance of context, consistent communication, information layout, label positioning, content groupings, and input affordances.", "filename": "webforms_lukew", "pageImage": "https://qrmsyiqritqdkspkjoqy.supabase.co/storage/v1/object/public/lukew-media/pdf-pages/webforms_lukew/119.png", "coverImage": "https://qrmsyiqritqdkspkjoqy.supabase.co/storage/v1/object/public/lukew-media/pdf-images/webforms_lukew.png"}, {"id": "8f8b19c3-0dc4-40e6-be4d-af2eaaca5383", "url": "https://www.lukew.com/ff/entry.asp?468=", "type": 1, "title": "Designing with Vision", "summary": "Product vision is a crucial discipline in the product creation process that has a profound effect on the outcome, is a source of innovation, and can override design quality. A solid product vision makes requirement gathering easy and gives clear guidance to design decisions. Vision is the selection of which problem to solve and a way to define a problem as a set of needs you are trying to address. The design pyramid, which includes design, requirements, vision, and understanding, is recursive and applies to each feature within the product. Disruptive innovation happens at the vision and understanding levels. Products that use the right best practices may turn out mediocre while those that break the rules may become runaway hits if they have a clear product vision. USN scenarios are used to understand the needs that build a vision and separate the problem from the solution.", "entities": [], "metadata": {"tags": ["User Experience Diagrams", "Design is communication. Use it as such.", "Design Vision: A Tale of Two Companies", "design vision", "strategy", "diagrams"], "title": "LukeW | Designing with Vision", "author": "Luke Wroblewski", "longDate": "March 2007", "shortDate": "Mar 2007"}, "coverImage": "https://static.lukew.com/design_pyramid.gif", "renderHtml": "

\t\n\n

\n \n

by March 8, 2007

\n\n

This week I caught a talk by Philip Haine from Obvious Design about Designing with Vision. Philip outlined how some products that seem to ignore the \"best practices\" of design turn out to be breakthroughs, while others that are designed by the book suffer from mediocrity. He also addressed why product design processes often suffer from have radically shifting requirements. According to Philip the answers lie in understanding product vision:

\n\n

Product vision is the missing discipline (marketing, design, development, etc.) in the product creation process. It has a profound effect on the outcome, is a source of innovation, and can override design quality.
A solid product vision makes requirement gathering easy and gives clear guidance to design decisions.

\n\n

Defining Vision

Vision is a loose term but its outcomes are quite tangible: better designs, smoother process, and break through products
Vision is a high-level requirement
Vision is the selection of which problem to solve. It means making a choice
Vision is a way to define a problem as a set of needs you are trying to address
Creating a vision is a design process
Every product has a vision whether implicitly or explicitly stated

\n\n

The Design Pyramid

Design: the only piece of pyramid that is visible to users
Requirements: the specifications of what a product must accomplish
Vision: the definition of a problem by which needs you are trying to solve
Understanding: research or intuition about those needs
It’s a pyramid because all layers above depend on what is below them
Design is hard because there is so much invisible stuff that feeds into it (requirements, vision, understanding)
For good design to happen you need the groundwork to be done
If you have a clear idea of vision & requirements, the design just kind of pops out or reveals itself
The design pyramid applies to functional design problems (not aesthetic issues)
Requirements shift so frequently because new insights come in at the understanding layer
The pyramid is recursive: it is set for a product but also applies to each feature within the product
Disruptive innovation happens at Vision & Understanding levels

\n\n

Bad Design

The right product vision can override the design layer, but it rarely happens the other way around
Products that use the right best practices may turn out mediocre while those that break the rules may become runaway hits
If they are missing the discipline of vision, even the best design processes can’t help.
Product vision & research is the driver (golf metaphor). Usability testing is the putter. [This was eloquently stated by Jim Leftwich on Functioning Form]

\n\n

USN Scenarios:

Used to understand the needs that build a vision
User: customer/stakeholder
Situation: or context or characteristic
Need: that results from user+ situation
Situation answers why something is needed and by whom
USN scenarios separate the problem from the solution
Need to be concise: necessary and sufficient

\n\n\n\t\t\t\n\n

\n\n\n

", "textOnlyHtml": "by March 8, 2007\n\nThis week I caught a talk by Philip Haine from Obvious Design about Designing\nwith Vision. Philip outlined how some products that seem to ignore the \"best\npractices\" of design turn out to be breakthroughs, while others that are\ndesigned by the book suffer from mediocrity. He also addressed why product\ndesign processes often suffer from have radically shifting requirements.\nAccording to Philip the answers lie in understanding product vision:\n\n * Product vision is the missing discipline (marketing, design, development,\n etc.) in the product creation process. It has a profound effect on the\n outcome, is a source of innovation, and can override design quality.\n * A solid product vision makes requirement gathering easy and gives clear\n guidance to design decisions.\n\n\nDEFINING VISION\n\n * Vision is a loose term but its outcomes are quite tangible: better designs,\n smoother process, and break through products\n * Vision is a high-level requirement\n * Vision is the selection of which problem to solve. It means making a choice\n * Vision is a way to define a problem as a set of needs you are trying to\n address\n * Creating a vision is a design process\n * Every product has a vision whether implicitly or explicitly stated\n\n\n\n\nTHE DESIGN PYRAMID\n\n * Design: the only piece of pyramid that is visible to users\n * Requirements: the specifications of what a product must accomplish\n * Vision: the definition of a problem by which needs you are trying to solve\n * Understanding: research or intuition about those needs\n * It’s a pyramid because all layers above depend on what is below them\n * Design is hard because there is so much invisible stuff that feeds into it\n (requirements, vision, understanding)\n * For good design to happen you need the groundwork to be done\n * If you have a clear idea of vision & requirements, the design just kind of\n pops out or reveals itself\n * The design pyramid applies to functional design problems (not aesthetic\n issues)\n * Requirements shift so frequently because new insights come in at the\n understanding layer\n * The pyramid is recursive: it is set for a product but also applies to each\n feature within the product\n * Disruptive innovation happens at Vision & Understanding levels\n\n\nBAD DESIGN\n\n * The right product vision can override the design layer, but it rarely happens\n the other way around\n * Products that use the right best practices may turn out mediocre while those\n that break the rules may become runaway hits\n * If they are missing the discipline of vision, even the best design processes\n can’t help.\n * Product vision & research is the driver (golf metaphor). Usability testing is\n the putter. [This was eloquently stated by Jim Leftwich on Functioning Form]\n\n\nUSN SCENARIOS:\n\n * Used to understand the needs that build a vision\n * User: customer/stakeholder\n * Situation: or context or characteristic\n * Need: that results from user+ situation\n * Situation answers why something is needed and by whom\n * USN scenarios separate the problem from the solution\n * Need to be concise: necessary and sufficient"}]},"created_at":"2025-10-09T20:55:52.773736+00:00","method":"reply","model":"claude-sonnet-4-5-20250929","additional_info":null,"context_retrieved":["ca09afb8-b333-468c-b0a1-971cabf27f9c","0653f3e7-5783-49be-984b-3756b7cfa5a4","29d912c2-fc80-49ac-af21-ebccab50093b","152ac583-79b8-45db-8738-64f94f1e3fdc","824dbbf0-8138-49a0-a072-21b848fe0eb5","8f8b19c3-0dc4-40e6-be4d-af2eaaca5383","16715186-a0cd-4596-98e3-e366ecbd0630","dbe59ba7-5a97-4765-9683-f075a39346a4","b2e88f73-33fe-4fb8-945c-91e9c7d70d60","83a63329-23f7-4b30-ab84-b185f15ccda9"],"context_all":[{"id": "ca09afb8-b333-468c-b0a1-971cabf27f9c", "locked": false, "source": "EMBEDDING_CHUNKS_SAVED_QUESTION", "similarity": 0.7200000000000001}, {"id": "0653f3e7-5783-49be-984b-3756b7cfa5a4", "locked": false, "source": "EMBEDDING_CHUNKS_PDF_V2", "similarity": 0.4}, {"id": "29d912c2-fc80-49ac-af21-ebccab50093b", "locked": false, "source": "EMBEDDING_CHUNKS_LUKEW", "similarity": 0.32000000000000006}, {"id": "152ac583-79b8-45db-8738-64f94f1e3fdc", "locked": false, "source": "EMBEDDING_CHUNKS_LUKEW", "similarity": 0.24}, {"id": "824dbbf0-8138-49a0-a072-21b848fe0eb5", "locked": false, "source": "EMBEDDING_CHUNKS_PDF_V2", "similarity": 0.24}, {"id": "8f8b19c3-0dc4-40e6-be4d-af2eaaca5383", "locked": false, "source": "EMBEDDING_CHUNKS_LUKEW", "similarity": 0.24}, {"id": "16715186-a0cd-4596-98e3-e366ecbd0630", "locked": false, "source": "EMBEDDING_CHUNKS_PDF_V2", "similarity": 0.24}, {"id": "dbe59ba7-5a97-4765-9683-f075a39346a4", "locked": false, "source": "EMBEDDING_CHUNKS_SAVED_QUESTION", "similarity": 0.24}, {"id": "b2e88f73-33fe-4fb8-945c-91e9c7d70d60", "locked": false, "source": "KEYWORD_CHUNKS_PDF_V2", "similarity": 0.24}, {"id": "83a63329-23f7-4b30-ab84-b185f15ccda9", "locked": false, "source": "EMBEDDING_CHUNKS_PDF_V2", "similarity": 0.16000000000000003}],"context_diversify":["ca09afb8-b333-468c-b0a1-971cabf27f9c","83a63329-23f7-4b30-ab84-b185f15ccda9","6a7ace33-79d4-42a7-881b-701dc2c7dc94","f26b7255-4b6a-44ad-8ccd-f11a32d71647","152ac583-79b8-45db-8738-64f94f1e3fdc","982ba1b7-e02b-4b6e-a430-501ec63a56a5","8a6093d9-a5a0-47e0-94e9-712fc4e3d058","2a66b596-a19d-4902-96f9-9f04642cf602","824dbbf0-8138-49a0-a072-21b848fe0eb5","8f8b19c3-0dc4-40e6-be4d-af2eaaca5383","abfc1457-a1a9-4c3c-acd3-037ef0228276","afa2d26f-e8f4-48d1-bdcb-7ef04f920669","0ca32f22-f270-4586-9e1a-065b7d3115dc","16715186-a0cd-4596-98e3-e366ecbd0630","16b52763-4a32-488b-a2a0-fc5ef9e7d6d7","13355966-48f7-45c1-b318-70a4e479cf8f","17bdf533-23af-4c89-a3fa-00ef8f261248","51899806-8845-4c91-bf3c-4bbf99884ce5","8b66ff2d-c245-45a0-94e4-e212c6c8eb0e","b347a8c4-3379-4698-a1e4-3db9cf387343","bae28b45-c12b-405b-b6ae-3c4d931714e2","ebdaa849-5228-485e-a111-d4bfca7ab102","b8d67cf9-4a96-4e05-aed9-20a9a6d55edf","892d506f-07bc-4c19-8c4c-52a57910f4b5","0653f3e7-5783-49be-984b-3756b7cfa5a4","dbe59ba7-5a97-4765-9683-f075a39346a4","979d7bcc-9113-400e-bba1-772287346274","f8f87c5d-ce27-46b2-ad08-a0e6a70bd62a","ba437532-d9d8-4ca5-8134-612d638132a7","071ec507-6d87-4d5e-9165-383c39595b84","7674f9df-a420-4b85-9dad-95d945e85a61","29d912c2-fc80-49ac-af21-ebccab50093b","b2e88f73-33fe-4fb8-945c-91e9c7d70d60"],"context_diversify_removal_details":{"02abf12e-0043-40e0-983b-663be3255aad": {"detail": "979d7bcc-9113-400e-bba1-772287346274", "reason": "similarity_diversity"}, "4726f77b-1222-478b-a619-13e11094d6bb": {"detail": "17bdf533-23af-4c89-a3fa-00ef8f261248", "reason": "similarity_diversity"}, "4ef5f293-3826-4030-a52f-552694dfa1ad": {"detail": "ba437532-d9d8-4ca5-8134-612d638132a7", "reason": "similarity_diversity"}, "58ad98fa-055a-4846-b898-8b932ca303b0": {"detail": "2a66b596-a19d-4902-96f9-9f04642cf602", "reason": "similarity_diversity"}, "66880414-b560-43c3-a775-d091644a6fda": {"detail": "17bdf533-23af-4c89-a3fa-00ef8f261248", "reason": "similarity_diversity"}, "74b31495-7ac9-468b-8853-602965faf148": {"detail": "bae28b45-c12b-405b-b6ae-3c4d931714e2", "reason": "similarity_diversity"}, "7725e2fa-3400-45f5-ac15-8a16ec1a56ad": {"detail": "17bdf533-23af-4c89-a3fa-00ef8f261248", "reason": "similarity_diversity"}, "824a0e6b-0d00-4d9d-b3f6-f91f45c7d679": {"detail": "b8d67cf9-4a96-4e05-aed9-20a9a6d55edf", "reason": "similarity_diversity"}, "8277f684-3d3d-4903-91ad-4d9ae72ca6db": {"detail": "824dbbf0-8138-49a0-a072-21b848fe0eb5", "reason": "similarity_diversity"}, "8c7400a5-469e-4fcf-807b-d656131e9695": {"detail": "bae28b45-c12b-405b-b6ae-3c4d931714e2", "reason": "similarity_diversity"}, "98584876-e939-4ba4-b0e9-fb2195507000": {"detail": "979d7bcc-9113-400e-bba1-772287346274", "reason": "similarity_diversity"}, "9b6bf67b-0868-4652-b5cc-c3e0fc23ac6d": {"detail": "bae28b45-c12b-405b-b6ae-3c4d931714e2", "reason": "similarity_diversity"}, "a43765aa-5e13-46b0-b952-ba755772e161": {"detail": "979d7bcc-9113-400e-bba1-772287346274", "reason": "similarity_diversity"}, "a71dfc35-38f6-4238-a410-f38413a70b0a": {"detail": "13355966-48f7-45c1-b318-70a4e479cf8f", "reason": "similarity_diversity"}, "a868875c-a734-48a1-9f26-62b859cb8dce": {"detail": "abfc1457-a1a9-4c3c-acd3-037ef0228276", "reason": "similarity_diversity"}, "a879c194-634a-4a2d-890f-5306fa9166bd": {"detail": "bae28b45-c12b-405b-b6ae-3c4d931714e2", "reason": "similarity_diversity"}, "be5af3b2-067f-48e1-a289-2bddfa1c7478": {"detail": "17bdf533-23af-4c89-a3fa-00ef8f261248", "reason": "similarity_diversity"}, "df9ba9b9-9e01-4a9c-91c9-18546e8c2dc4": {"detail": "8a6093d9-a5a0-47e0-94e9-712fc4e3d058", "reason": "similarity_diversity"}},"context_in_prompt":["0653f3e7-5783-49be-984b-3756b7cfa5a4","29d912c2-fc80-49ac-af21-ebccab50093b","152ac583-79b8-45db-8738-64f94f1e3fdc","824dbbf0-8138-49a0-a072-21b848fe0eb5","8f8b19c3-0dc4-40e6-be4d-af2eaaca5383","16715186-a0cd-4596-98e3-e366ecbd0630"],"context_replied":["152ac583-79b8-45db-8738-64f94f1e3fdc","0653f3e7-5783-49be-984b-3756b7cfa5a4"],"question_keywords":"empty state problem\n"}]

Here's some questions you can ask Luke Wroblewski

2027