结构层主要包含的是交互设计和信息架构
交互设计和信息架构强调的是，将各个将要呈现给用户的元素的“模式”和“顺序”。
交互设计关注影响用户执行和完成任务的元素；信息架构关注如何将信息表达给用户的元素。整体结构层最本质的其实是要求如何去理解用户和用户可能发生的行为——思考用户的工作方式、行为和思考方式，这样可以为用户提高产品体验
模型概念
交互组件怎么工作，取决于软件是否把某个特性处理成用户所熟悉的某个概念，规划好概念模型能够帮助你做出一致的设计决定
模型概念在我的理解里面而言是属于某个特定场景下的常规性操作，常规性操作是用户不需要思考，顺其自然的一种操作行为
如：【购物车】，购物车首先是个容器，这个东西的添加和删除可以通过【编辑】来搞定，当用户推着【购物车】离开超市之前，必定是要有一补【结账】，而结账的载体就是【收银台】
使用人们熟悉的概念模型可以减少用户的思考成本，但是常规化的场景也不能完全放在线上，书中有例子指出，国外有一款叫做slate做的是一个网络杂志，它将所有的现实世界都搬到了网上，这样用户会觉得很混乱，用户可能已经被一些已有的模式教育的很好了，所以考虑场景线上化的时候，不必凡事都有
总的来说就是两点：减少用户思考的时间成本；可以复用现成体系化的框架流程来做一些东西。不要【过分运用】某些概念就好
错误处理的方式
1、不要【让用户发生错误】的设计
2、避免错误的方法就是使错误难以发生（吐槽下很多APP进入页面都会去关闭一个弹窗，其实真的是影响了我的使用，并且有可能会让我们做出错误的【确认】）
总体思路是：预防——改正——恢复，尽量将每个级别的错误降到最低，以确保用户能有积极的体验
党有一句话说得好：预防为主，防治结合，综合治理！
以前认为在用户点击某个确定之前一定要做一个提示框，或者在用户做了某个操作之后，会给用户保留一个【撤销】，虽然【撤销】这个动作可以挽回用户的动作，但是使用的时候一定要根据用户实际操作的场景应用，和操作环节，没有必要再每个环节都展示出这样的东西，一定确保把用户的操作成本降到最低
【又想吐槽弹框，每次打开应用都出现弹框，也不代表我一定会点击去，点击去也不代表我一定会完成这项任务，都是人民，何必相互为难】
信息架构
结构化内容
信息架构主要是设计组织分类和导航的结构，一定是设计出让用户容易找到信息的系统，我们可以通过由上而下或由下而上的方式来建立分类体系：
由上而下：根据战略层分析，按照主次分许，建立主要分类和次级分类的层级结构，就像一个个空槽，在里面按照顺序填满“内容和功能”
由下而上：根据范围层分析，根据已有的“内容和功能需求的分析”而来，先将所有的资料放在最低层级，然后将他们按照归属来由下而上的进行结构分类
自我思路迭代——
以往的思路是：计算用户完成任务所需要的步骤，或者说计算用户到达某一个节点的点击数
应有思路：用户是否认为每一个步骤都是合理的，当前这个步骤是否自然的延续了上一个步骤中的任务
网站/APP应该是具备【容纳成长和适应变动】属性的，前提都是为了满足企业目标和用户需求，比如新闻类网站，开始类目较少的时候可以按照时间顺序来进行分类，当网站类目和数量逐渐增多的时候，就应该按照主题组织来对新闻进行分类了
结构化方法
信息架构的基本单位是节点，节点可以对应任意的信息片段或组合——可以小到一个数字，大到一个框架
信息架构其实就是在应用中设立一个最小的节点，这个节点也是可以进行分类的，比如按照业务和活动进行区分，这就是两个类型的分支，分支中每个子业务就是一个子类，再往下每个流程的过程中进行区分，那么每个小的流程可能就是一个节点，这个节点既可以复制，也可在这个节点和下一个节点中间进行增改，这样建立一个金字塔式的结构框架即可，这样无论如何变化或者组合将是非常灵活多变的一种组织框架形式。
组织原则
节点在信息架构中是依据组织原则来安置的，组织原则其实就是我们决定哪些节点在一个组，哪些节点需要保持独立的一种思考
一般来说，产品最高层级使用的组织原则应该紧密的与“网站目标”和“用户需求”结合在一起
比如网站的首页，用户进来最希望看到的和网站最想表达的，结构的“塔顶”有可能都是需要表现出来的，当然最后一个点，具体是“塔顶/塔底”是要根据产品的类型、模式来定义，其实我们可以理解成为一个筛选条件，我们以及用户需要什么样的状态展示出来，那么我们就这么展示出来即可。
你并不孤单，我们一起在努力的道路上并肩前行！
