鹤鹤 交互设计及用户体验
一份需求文档有了完整标题、用户故事、验收条目和界面草图，看起来似乎已经很接近可以开工。但内容生成得更快，不代表团队理解得更快。Cisco的Adrienne Moherek在11月11日分享PubHub重建过程时，谈到AI辅助需求带来的阅读与核对负担。这个经历很适合放到设计协作中讨论：当材料越来越充分，怎样让评审仍然围绕真正需要决定的事情展开？以下以原文少量事实为入口，补充独立的设计团队应用思考，不把作者经历写成兰亭妙微的项目案例。
AI进入客服后台后，页面里增加的往往不只是一条回复建议，还可能有摘要、情绪提示、推荐动作和相关资料。功能多起来，客服人员的视线会怎样移动，输入会不会被打断，值得重新看看。今天兰亭妙微分享 Ridwan Soleh 刚发布的 CareSync 设计文章，结合原作中的会话与工作台画面展开讨论。它展示的是UI套件，下文的工作场景和评审方法属于我们的延伸观察，不能作为原作使用效果的证明。
同样是一段对话，有的AI产品能够查找资料，有的还能生成草稿、调用工具或完成后续动作。NN/g近期由Caleb Sponheim撰文介绍Agent Harness，解释模型周围的软件怎样组织上下文、工具和执行限制。兰亭妙微借这个概念，分享对企业AI助手界面的观察。下文围绕“整理一份设备维护记录并形成工单草稿”的假设任务展开，四张配图均为独立AI概念示意，用来讨论产品如何说明能力、过程与结果。
打开一份需要签署的文件，用户往往同时关心三个问题，文件是不是自己要处理的，哪些位置需要填写，完成以后会发生什么。dpopstudio近期以AItentico为例，讨论了电子签署界面的状态与阅读关系。兰亭妙微借这个主题分享交互设计观察，下面的流程采用假设的企业文件确认场景。原文配图按实际画面说明，补充界面单独标为AI概念示意，具体签署规则与身份要求由真实产品流程决定。
AI聊天界面的变化很容易被看见：文字在生成，按钮在切换，侧边栏又增加了一次会话。但看到变化，不等于每个人都知道发生了什么。Eric Bailey在近期文章中，从可访问性角度重新讨论了沉浸式AI聊天体验。兰亭妙微这次把阅读视角放到企业助手的使用过程里：一个人提交材料、等待回答，再回到自己的任务，界面应该怎样接住这些动作。以下包含独立的应用示例与AI概念配图，不是对某款产品的实测结论。
鹤鹤 系统UI设计文章及欣赏
仓储调度页面常常同时放着库存、订单、车辆和异常提醒，信息很多，使用者打开页面却未必知道先处理哪一项。10月6日，dpopstudio用WareApp设计套件介绍了仓储与发运界面的组织方式。这次借它的真实UI配图，分享我们对任务、状态和上下文的观察，并补充一张AI调度界面示意。文中的仓库任务均为说明设计判断而设想的场景，不是对这套模板或已上线系统的实测。
地图界面很容易显得丰富：底图、路线、标记和侧栏都能往里加。真正难的是，当人带着一个具体问题看图时，能不能迅速找到线索。今天兰亭妙微分享 Figma 对 Lufthansa Systems 设计团队的访谈，原文讲到他们用更接近真实数据和行为的原型讨论复杂地图。对交互设计公司的方案工作而言，这也是一个很好的阅读入口。我们借此聊聊信息层级的设计判断，后文园区和物流场景为独立概念讨论，不是航空操作规范。
从打开筛选器到填写条件，再到对比结果，许多数字产品要求用户先学会界面，才能说清自己想做什么。Carrie Webster 的文章用几个产品画面讨论了另一种方向：让用户先表达目标，再由系统帮助组织结果。这给交互设计公司和产品团队提出了很实际的问题：省掉操作以后，用户还能否理解结果、调整选择并控制接下来发生的事？本篇保留少量原文案例画面，其余围绕这一问题展开独立的设计观察。
用 AI 整理一份资料，第一次结果看起来流畅，仔细读却发现日期不对。这时用户需要的，通常不是一句更热情的道歉，而是知道错在哪里、能不能改、之前的工作会不会丢。兰亭妙微这次分享 Tushar Deshmukh 关于算法错误与信任的文章。我们借这个问题，把注意力放到日常工具的界面上：下面的资料摘要和文件整理均为假设场景，讨论的是交互设计的补救方法，不涉及医疗、金融等专业决策。
设计稿里每一行文字都刚好，每张卡片都有数据，按钮点击后总能进入下一页。真正上线以后，长名称、等待、权限和失败才一起出现。兰亭妙微这次阅读 Pavel Bukengolts 的设计协作文章，关注其中关于设计意图在交付中流失的讨论。它提醒我们，视觉稿只是沟通的一部分。以下用一个假设的资料管理产品展开：如果要和交互设计公司或研发团队一起把方案做实，哪些细节值得在交付前讲清楚？
蓝蓝设计的小编 http://www.lanlanwork.com
