[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-dashboard-that-gets-used-en":3,"blog-adjacent-dashboard-that-gets-used-en":29,"blog-related-dashboard-that-gets-used-en":58},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":13,"readingMinutes":14,"featured":15,"tags":16,"category":19,"seoSettings":28},7,"dashboard-that-gets-used","Making Dashboards Actually Used: Three Design Principles","Dashboards usually fail not because the data is wrong, but because they only answer what happened and never answer what should I do now.","\u003Cp>Almost every management system has a dashboard, but few are actually used day to day. The reason is usually not inaccurate data. The dashboard answers what happened, but never answers what I should do now.\u003C\u002Fp>\u003Ch2>Principle one: one screen answers one question\u003C\u002Fh2>\u003Cp>Putting sales, inventory, footfall and satisfaction all on one screen means nobody can see the point. A better approach is to split by role: store managers see today's operations and exceptions, regional managers see store comparisons, and owners see trends and structure.\u003C\u002Fp>\u003Ch2>Principle two: put comparisons in the same line of sight\u003C\u002Fh2>\u003Cp>A single number means little. Year-over-year, month-over-month, target completion and comparison with similar stores help users judge whether a number is good or bad. Comparison dimensions must stay stable so the definition does not change every time the page opens.\u003C\u002Fp>\u003Ch2>Principle three: provide the next action\u003C\u002Fh2>\u003Cul>\u003Cli>When stock falls below the safety line, provide a replenishment entry directly;\u003C\u002Fli>\u003Cli>When conversion is abnormal, allow drilling down to the specific channel and page;\u003C\u002Fli>\u003Cli>When complaints cluster, allow viewing the related orders and handling progress.\u003C\u002Fli>\u003C\u002Ful>\u003Cblockquote>The value of a dashboard is not how much data it displays, but how much faster it helps users make one correct decision.\u003C\u002Fblockquote>\u003Cp>In projects we usually review a week of old reports with frontline users first, identify the few things they actually check repeatedly, and only then start designing. Dashboards built this way are used far more often.\u003C\u002Fp>","","blue","佳益方圆团队","2026-08-15T09:00:00+08:00","2026-10-18T15:58:14.731+08:00",1,false,[17,18],"Data Products","Business Analysis",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":10,"kind":26,"sortOrder":27,"count":21},2,0,"product-thinking","Product Thinking","Requirement analysis, user experience and product design methods, plus the thinking from business problems to product solutions.","lightbulb","article",50,{},{"previous":30,"next":41},{"id":31,"slug":32,"title":33,"excerpt":34,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":35,"updatedAt":35,"readingMinutes":14,"featured":15,"tags":36,"category":40},55,"empty-states-in-b2b","Empty States in B2B Products","The first thing a user sees is not a feature but a blank page. Empty states decide whether they can start.","2026-08-16T14:05:00+08:00",[37,38,39],"B2B","UX","Empty States",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":10,"kind":26,"sortOrder":27,"count":21},{"id":42,"slug":43,"title":44,"excerpt":45,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":46,"updatedAt":46,"readingMinutes":14,"featured":15,"tags":47,"category":51},75,"dashboard-adoption-retro","Retrospective: A Dashboard Nobody Opened","The dashboard looked great and leadership applauded. Three months later its open rate was close to zero.","2026-08-14T14:05:00+08:00",[48,49,50],"Retrospective","Dashboard","Retail",{"id":52,"parentId":21,"slug":53,"name":54,"description":55,"icon":56,"cover":9,"tone":10,"kind":26,"sortOrder":57,"count":21},3,"project-retrospective","Project Retrospectives","Real project records from zero to one, covering problems, solutions, lessons learned and final outcomes.","clipboard-check",40,[59,70,80],{"id":27,"slug":60,"title":61,"excerpt":62,"content":9,"cover":9,"tone":63,"author":11,"publishedAt":64,"updatedAt":64,"readingMinutes":14,"featured":15,"tags":65,"category":69},"grading-requirement-confidence","Grading the Confidence Behind Requirements","Treating requirements as facts is the most common cause of delay. Requirements differ in how reliable they are.","indigo","2026-10-15T09:00:00+08:00",[66,67,68],"Requirements","Product","Risk",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":10,"kind":26,"sortOrder":27,"count":21},{"id":20,"slug":71,"title":72,"excerpt":73,"content":9,"cover":9,"tone":63,"author":11,"publishedAt":74,"updatedAt":75,"readingMinutes":14,"featured":15,"tags":76,"category":79},"vertical-product-rules","The Watershed for Vertical Products: Writing Industry Defaults into the System","Vertical is not a new industry label on a generic product. The real barrier is understanding and carrying the default rules that practitioners take for granted.","2026-10-09T10:00:00+08:00","2026-10-18T15:58:14.661+08:00",[77,78],"Industry Products","Product Design",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":10,"kind":26,"sortOrder":27,"count":21},{"id":81,"slug":82,"title":83,"excerpt":84,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":85,"updatedAt":85,"readingMinutes":14,"featured":15,"tags":86,"category":88},51,"mvp-boundary","Drawing the Boundary of an MVP","Minimum viable is not the fewest features; it is one complete business loop running end to end.","2026-10-03T10:13:00+08:00",[87,67,66],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":10,"kind":26,"sortOrder":27,"count":21}]