I got an invite on LinkedIn the other day that piqued my interest more than most: it wasn’t actually related to Salesforce at all. It was a Business Analyst and Information Architect position, which is sort of where my career started.
So, that got me thinking about some of the problems that I see in the Salesforce world when this stuff is disregarded.
Defining Information Architecture precisely can be tough: it’s not design, but it impacts design (and vice versa.) It doesn’t involve programming at all. It’s not creating content, but it can have a huge effect on content (and vice versa.)
The term Information Architecture was coined by Richard Saul Wurman according to most generally accepted accounts. Amongst the other things Wurman is notable for is founding the TED conference and designing the wayfinding signs for the 1984 LA Olympics.’
That last point provides some clues to what Information Architecture (IA) is, particularly from my point of view. It’s really about the structure of how content will be organized so that it can be found and used when a person is looking for it. Done properly, the visitor to a web site (for example) should be able to quickly develop a mental map of where things are instead of constantly searching.
Some examples from other fields? Encylopedias are generally organized by first letter or subject and then alphabetically; restaurant menus are broken into types of dishes (appetizer, entree, desert.) Some of these are so common as to seem second nature.l They aren’t always but that’s the point: IA makes information easier to find, and done well it seems like second nature.
I think there are a few reasons IA gets ignored in the world of Salesforce.
Your Tech Team Doesn’t Care
We’ve talked about not letting programmers design solutions, and the fact that Salesforce initiatives are increasingly being run by techs. For the most part, your tech team doesn’t care about the non-technical elements of the solution at all. They just ignore them.
BAs should should care, but often just focus on workflows and not the structure of how things are laid out because they’re not doing the building. The end result is two solitudes: the techs don’t care and the BA’s are providing guidance, so the IA of your solution gets ignored.
Salesforce Already Handles It
We all know the Salesforce layout: tabs across the top as a main menu, the body of the page in the middle. Consoles are a bit different, but still have a basic layout. So isn’t IA already handled?
Absolutely not: there are a huge number of things that can and should be considered beyond this basic grid. These include:
- Which apps do you need and what should be in them? You can create a different set of tabs and actions for Sales and Service
- How should detail pages be broken up including the user of headings and field grouping? You can’t just throw 100 fields at random on a page and say it’s done: that’s an unusable mess.
- Related lists, tabs and panels: since the advent of lightning we’ve been able to create robust, more advanced page layouts that can make like quite ab it easier if they’re used properly (e.g. allowing Account information to be edited directly from an Opportunity page.)
This is just the tip of the iceberg and you don’t have to solve all of these things, but they’re worth thinking about.
Salesforce is a Rapid Application Development Environment
Salesforce does behave like a RAD in many ways, but this isn’t an excuse for not considering the IA of your solution. Delivering a solution that’s good enough might be OK for a while, but incrementally improving it on an ongoing basis will get you a long way towards happier users and better data, both of which are important.
Is Information Architecture a Waste of Time?
Absolutely not. It can play an invaluable role in improving your Salesforce instance in many ways. It doesn’t need to be a dedicated employee, and it doesn’t need to be a dedicated line item on a problem plan–but you should be thinking about it as part the solution process all the time.