边界设计:第二部分：在产品设计过程中，设计者对边界情况提出最佳的设计和看法。
Eugene Chen
虽然核心情况是关键，但是边界情况可以很容易的就购买到大量研发者的劳动成果和设计理念。边界情况管理是成本控制的重要组成部分。
可用性测试在反映边界情况时并不那么有用，因为通常用户没什么耐心，测试的时候只给少的可怜的时间。很多边界情况的结论都是在开发商别无选择时，不得不作出的结果，他们使用的是结合设计而不是我们给他们的设计文稿。开发商要从头开始检查设计，避免可能造成潜在边界情况的风险。
处理边界情况有两种基本的方法：1预防2支持。虽然有了选择，但是我还是愿意去预防边界情况，它使得设计最佳，避免通俗，然而，有些时候你无法预防，因为你不知道你的用户会用你的系统去做什么。
Google和许多Web2.0网站都尽力把expectations前置，这样可以节省用户进入界面的时间，直接达到目的。这些页面告诉用户这个装置支持什么，不支持什么。
当预防了一个边界情况时，这就可以视为为客户学习的机会。举个简单的例子，如果输入的内容有一定标准，设计会预先提醒客户，如果没有提醒，当客户输入的东西不可接受时，一条提示信息和其他小贴士就会跳出来，这种事先提示和事后提示的转变是十分有用的。
然而我们有必要考虑到边界情况，因为不要使它们控制了核心设计。我们应该处理边界情况，但是它们的影响应该是按比例测量的。设计不要容量太大，否则难以成为一个容易被人接受的设计。如果设计能提供一些核心情况那是最好不过的了，这样能在用户间引起反响。
Luke Kowalski
除了回答如何管理边界情况，我还要谈谈如何承担边界情况。两种说法可能表达的是同一种意思，但是一种可能是把额外功效放在一个更积极地层面。毕竟，一句俗语是对的：对于设计者来说是边界情况对于用户来说也是个棘手的东西。
公司软件中的边界情况通常是由制定人和顾客引起的。我们会时不时地推出一款适应广大顾客要求的设计。令我们自豪的是，我们的产品都是“可延伸的”。我们还会把公司的设备作为一个样本，而且如果你处于用户子群A，但是在B里只有7个域时，设备还有能力提供10个域。在商业逻辑中我们还有很多探索的余地，自动用户化美化了服务项目的个性化。
前一个例子表明了在核心布局发布后，我们该如何处理边界情况，我们还是运用常用的手段去设计功能。我们常常把UI分成2个或几个部分。一个用户可以使用边界情况或可选择域，把一个区域扩张。
最后开发商通常在某个形式中加入边界情况，但是他们不愿意去刁难设计者。这只是一种简单的对客户的回馈，或者是一种销售，结果所有的东西可能都会进入你的数据库，如果从调查、研究、用户（购买代理，终端用户，观展商，已有的或潜在的用户）那里得到这些数据的话，可能就有麻烦了，只有找到高效设计的平衡点才能解决发展路上的所有阻碍。
待续…
我们将给你带来更多关于边界设计的前景