The Internet is just a pile of information. Some of that information is text, some of it video, some of it audio and so on. Some of the information is easily viewable by everybody and some of it is hidden away — either behind passwords or technically embedded in the Web software itself.
To make stuff for the Web, it helps to organize it a bit before you get into the expensive task of coding the software. If you organize well then you’re more likely to have what you need when the coding is done.
Information architecture document
The information architecture (IA) document usually looks a little like your company org chart. There are a bunch of boxes, arrows, lines and maybe a couple of icons.
The goal of the IA document is to help establish the scope of the information you’re putting in your digital project, and the relationships between bits of information.
For smaller, simpler real estate websites the information architecture is pretty straightforward. If you imagine having fewer than 10 things on your website or app, you might be able to skip this and just use a prototype (see discussion below).
One serious advantage of preparing an IA document is that it helps you, as the owner of a website or app, to get your ducks in a row. It forces you to comprehend the entirety of your project so you don’t end up with a bunch of surprises later on.
Another advantage is that you don’t really need anyone’s help to make your own IA document. You can do this yourself.
And if you do it yourself, prior to asking developers to bid on coding your project for you, the bids and timescales will be more reliable. In fact, I’d be willing to wager that all bids and time estimates made without an IA document are hocus-pocus numbers that are just made up.
Something to watch out for with "wireframes" — which depict a website’s page design and layout — is that they make your home page or screen seem very, very important. Perhaps this schematic shows that the home page is linked to at the top of every page, and every element in the IA document is connected to it.
While your home page or screen is important, your audience will likely spend far more of their time interacting with all of the other pages and screens in your digital project. So make sure you don’t get lured into thinking the home page is important when in reality the audience wants to be using a piece of functionality (like a home search or neighborhood descriptions or whatever).
Also, sometimes IA documents are mistakenly called site maps. A site map is simply an index of every page on a completed website — something that is made after your website is complete. IA documents should be done before you make your website.
Wireframes
Wireframes are simplified drawings of each type of page or screen in your project. There should probably be at least one wireframe document for every box on your IA document. In my experience, wireframes are the least understood and most abused kind of preplanning document.
Wireframes get abused for two reasons:
- the project owner (probably you) is anxious to see something that looks "pretty," so the development vendor (that’s the person you’re probably paying) makes the wireframe look pretty; or
- the vendor simply doesn’t know how to make a wireframe.
A wireframe should not be judged on its beauty. It should, instead, clearly denote what kind of functionality is on a page. It should also show what kind of content is to be displayed on a page. There may be some very light layout and element arrangement (the navigation at the top, a sidebar, an area for content). But in no way should it be styled or "sexy."
Wireframes help you make certain that you do, indeed, have room and a place for your content. They also make certain that you do, indeed, have some sort of navigational structure to get from one piece of content to another. They also help you stay focused on the project goals. One of the elements on your wireframe might state something like "Conversion form" or "Link to Conversion page." That element should probably be on every one of your wireframes.
Prototype
Unlike the previous two items, a prototype is coded. This means that changes to the prototype can sometimes be more time consuming (aka expensive) than editing an IA document or wireframe.
On the other hand, a prototype can give a far greater sense of how a digital project "flows" than an IA document because you can click and tap your way through it. A prototype can also give you a clear idea of how crowded your design will end up being than a wireframe if you include placeholders for things in your prototype.
For many real estate websites, a simple prototype put together in WordPress can give a clear understanding of how a project will work, how much content is needed, and also identify any gaps or misunderstandings about how information is being organized by the digital project.
The problem that occurs with prototypes is, like wireframes, the temptation is to make them designed and "sexy." If you approach a prototype as a piece of design then it won’t work.
If you can’t look at a plain website and identify if it has the right functionality for you and your audience, you’re better off skipping a prototype — you’ll need the extra time and budget for a more extensive and expensive design process.
When a prototype is complete and functions right, then a graphic designer can apply all the style and "sexy" you need for your site to work well.
Getting from start to done, quickly and inexpensively
One way to get a solid digital product developed with minimal heartache is to do the following:
- Prepare your own information architecture document before you find a vendor.
- Get your vendor’s input on your IA document (the vendor may have some good edits) but make sure your project’s business goals remain represented in the document.
- Skip wireframes and go straight to a simple no-design prototype (my own website, linked below, is a simple no-design prototype). Do not worry about the design until all bits of content and functionality from the IA document are present in the prototype.
- Let a graphic designer loose on the prototype. When he or she is done, double-check again that all content and functionality from the IA document are on the site.
If you can’t do these things, and some people really can’t, be prepared to take more time, pay more money, and be a little bit more confused about how/why your digital project works a certain way.
