Before information architecture.
Before information architecture, you should capture assumptions.
Step 1: Business Intent
Business intent helps you and the people you work with define what good is. Here, I made a simple matrix that you can use to capture business intent.
Meet with people, and help them use words so you can fill it out for everyones benefit.
Step 2: User Intent
User intent helps in the starting assumption of why you do what you will do.
It’s OK to start with assumptions, like the user, purpose, and context methodology, it’s pretty simple, and gives great common ground to teams.
Here, a simple matrix to help people define things in good ways:
A word of caution: you are not the user, and your knowledge of user intent will, can, and should change over time.
That’s what user research methods are for. To help you take action on your life long journey of learning about other people so you can help them better.
This gives you grandest of valuable opportunities to apply new learning to better define why you do what you do that impacts what you do and how you do it.
Step 3: Content
Before information architecture, there should be content.
Not information. Not data. Content.
If you have existing content, evaluate and assess it to understand if its information supports the intent that you now have.
If you don’t, work to create content that does fit the intent that you now have.
Is there too much, too little, or not the right type of information?
Whether evaluating existing content or creating new, if you have those business and user intents (and you do regular user research), you’ll see if there is too much, too little, or just not the right type of information.
What If I’m Not “Before”?
Didn’t do any of the above before information architecture?
Ask for help. Let people know that there’s a gap and you need “before information architecture” to do your job. To create a great product. To have a successful business.
Hope that people want your help. This type of help is typically seen as help that makes everyone “go back” to ensure that a quality product is actually being built.
You’d think ensuring a quality product is always a good thing to do as a moral obligation. I’ll tell you now that some organizational cultures disagree.
Such a situation is difficult for people facing those organizational cultures.
So good luck, and feel free to reach out to me on twitter if you need some guidance.