一、首先，引用一段有意思的历史介绍
比较有意思的是，信息架构这个概念最早是由一个建筑师提出的，他叫Richard Saul Wurman，1975年，首次提出了信息架构这个词，后来他的兴趣由建筑转向信息的收集和整理。第一次定义了信息架构的含义：“organising the patterns in data, making the complex clear”。
再后来，2个图书馆科学家Lou Rosenfeld和Peter Morville于1996年，在《 Information Architecture for the World Wide Web: Designing Large-Scale Web Sites》一书中定义了信息架构为：
1. The combination of organisation, labelling, and navigation schemes within an information system. 为信息系统做组织、分类和导航的设计
2. The structural design of an information space to facilitate task completion and intuitive access to content. 为信息空间做结构设计，以方便完成任务和访问内容。
3. The art and science of structuring and classifying web sites and intranets to help people find and manage information.巧妙合理的组织和分类企业内部网络，以帮助人们检索和管理信息4. An emerging discipline and community of practice focused on bringing principles of design and architecture to the digital landscape. 一类表现的规律和共有的使用习惯的提炼，形成了信息架构设计的原则。
而交互设计据说是有Cooper先生“造”出来的新词汇。（传说当时大家对他的调侃是：Cooper先生今天又造什么新词汇了？） 在软件里，交互设计关注界面间的交互和界面的表现。
根据人类发展的历史推断，信息架构科学应该演化于对书籍、信件、图纸等管理，因为早期的信息也是基于这些纸的介质而传播的。到后来图书馆的出现，使图书馆的管理成为一门独立的科学，图书馆的管理或许是信息架构的科学根源。一叶千鸟 提供下载的信息架构讲座里，基本都是以图书馆为例的，因为在图书馆里，信息架构是图书馆对于馆藏的分类、书架的摆放以及图书馆房间布局的整体设计。随着社会的发展，后人总结的定义为：“信息架构，即信息组织的方式和结构。”
二、谈谈个人对网站或软件的信息架构的一点理解
在网站里，信息架构是一个站点对内容进行分类，并且建立交互来导航这些内容的设计。那么对于一个工具软件，如果其本身并没有要共享的信息，但它可以提供共享信息的平台，这样的工具软件，我们是不是感觉不用做信息架构，因为其本身没有信息呀？我只需要把软件交互做了就行了吧？
我想咱们应该换一个角度来思考共享信息或处理信息的工具软件。比如：图书馆建筑在建设的时候，他只是建筑而已，但房子是用来为书和使用者服务的，房子的布局或许决定着藏书的布局，这时候图书馆的建筑就成了信息架构的一部分，是信息架构的根基，然后才能做具体的书的存放结构布局。至于在布局之间怎样交互，怎样让用户检索到，怎样提供给读者服务，这些我想都是交互设计要参与的。
软件技术的架构本身不是信息架构，但软件要做成什么样，软件表现的架构正是我们说的信息架构，信息架构的设计结果在某种程度上是概念设计。
去年在做公司产品的概念设计的时候，和产品老总一块讨论产品的组织结构，产品的表现形式等等问题，等整个的产品结构、组织形式和基本的交互方式定下来的时候，产品老总突然说了一句：“这就是信息架构”。由此我得出的理解为，信息架构的结果是概念设计的呈现，决定着产品的交互骨干。
说到这里或许让大家感觉有些迷惑的问：“信息架构、概念设计、交互设计这三个谁是谁呀？”，若大家有兴趣咱们作为一个话题私下探讨吧。为什么可用性、交互设计、信息架构这三者的概念，我还是没有看到一条清晰的分界线，或许因为他们之间是相辅相成的整体，只是角度和范围各有则重，其实为了同一个目的服务：让使用者以最快的速度，准确、方便的找到所需信息。
三、现实中，我们通常搅乱当初的信息架构。
在做软件或者网站的信息架构设计的时候，我们在没有科学数据分析和想明白是怎么回事之前就草草动工了，并每起名曰“抢时间，速度是成功的保障！”，但事实并非如此！这样的后果通常是“翻工”！一次又一次的“翻工”！一次又一次的改变产品的信息架构。更可笑的是，很多开发团队的领导认为这样的返工是必然的，并称之为“迭代式开发”，一种非常有效的开发方法。无奈之余，我们可以思索一下，为什么？信息架构的合理性本来就是要在信息架构的时候考虑好的，而不是简单的拍一下脑门就开始做界面交互，我不否认交互原型和定义可以清楚的表现出软件或网站产品的结构和可用性，但没有做信息架构就做交互设计，我们的交互设计依据什么？交互定位是否准确合理？
自己的一个经历就是一个惨痛的教训，是我负责设计的一个电子商务网站（个人承接），当时根据需求者描述，整理出了需求（当时是确认了的），并开始做交互界面。如果仅仅如此还不至于出问题，要命的是，新的需求和想法随之而来，并被需求团队论证为合理的，问起他们定位和目标导向是什么？ 其回答曰：“东方不亮西方亮，咱们多提供些内容。”明显是看别人有什么通通拿过来，要命呀！最终只好放弃！！！唯一的一次失败的案例，事后沉痛总结：1、运营者产品定位模糊，导致定位经常有变动。 2、网站信息架构在设计实施阶段变化 3、概念沟通时间过长（都开始实施了还非要讲大道理），施工时间施工一拖再拖。 以上三点不难看出，信息架构设计做不好或由此导致的经常变动是致命的，信息架构搅乱了，所有的前台工作可能全废，且导致无限恶化，实在不行就再重新组织做吧。（请问时间节省了吗？）
交互设计是可以把功能或信息按某种既定的方式组织的易用、好用，但组织什么样的功能和信息是否也应该坐下来好好考虑？也就是说我们是否应该首先来做信息架构？产品有什么功能构成、产品的业务逻辑和各部分的关系等应该由信息架构来做，交互是基于已有的信息架构做界面（接口）的交互和表现，并在用户的交互保证其可用性。我们再拿聊天工具思考一下：MSN、SKYPE、QQ、TALK等，这些都是我们常用的，也都是基本满足我们的使用需求，但他们各自的功能、结构、使用环境等是不一样的，甚至相差很大，不同的信息架构和姿态决定着交互也有比较大的差别。
那么我仍然以图书馆的信息架构，来简单的看看交互和信息架构之间的关系。图书馆是用来藏书和提供阅读的，也就是说它的很大一部分使命是提供阅读，上面我们说道“在图书馆里，信息架构是图书馆对于馆藏的分类，书架的摆放以及房间的布局的整体设计。” 这个整体结构的决定了用户找到书籍的路径或方式，即用户的基本行为是由此来决定的。这样我们就可以看出，信息架构设计为交互提供了一个基础，并对交互的姿态有着直接的影响，所以信息架构设计应该让交互设计师参与并征求交互设计师的建议，以便为后期的详细交互设计提供顺畅的基础。
