Design & UX
By Alex Walker

Information Architecture – Why the First Page Comes Last

By Alex Walker

The home page, the cover page, the landing page, the site root. Whatever you call it, it’s generally core to the way your users perceive you, and central to how your site operates. Clients are always obsessed by it, and when you begin designing a new site, it seems easy and intuitive to start by banging a logo in the top left and continue laying out your home page below it.

Easy, yes. Intuitive, maybe, but not necessarily useful for achieving your design goals

As Derek Powazek points out his new IA article on ALA, it’s the deepest ‘atomic elements’ of your site — the units of content like the articles, the news, the search results and the product pages — that provide the best bedrock from which you can build up towards your home page. In reality, I think these ‘deep pages’ are usually the easiest to get started with because they have a clear purpose and goal from the start.


In thoeory, as your content pages take on a more solid form, the decisions you make automatically start to feed into the way the category and/or home pages will work. In some ways they design themselves.

If you already work this way, this short article won’t be rocket science to you, but I get the impression that simple IA approaches like this are less well understood than they should be.

It’s great to see this kind of thinking on display to a large audience. Nice article, Derek.

  • DavyT

    I agree, and this is become the way I design my sites. When I first started it was from the home page down but now it’s the database first, followed by db driven pages and the home page last. It works so much better and it is easier for the home page to reflect actual content.

  • LiQ

    Nice to see that I’ve been on the right path all along. Since I moved from static HTML to dynamic ASP.NET (PHP previously as well) I’ve allways designed the database and business-objects first. The first page remained only “Welcome to site X…” for a long time before the other content was finished.

    Good reading.

  • Never thought designing a site this way, oddly. Thanks for opening my eyes here. Will definitely try this out the next time as it – when put into words here – definitely seems like the smarter way to approach the design process.

  • Anonymous

    well done
    i learn new technice never thought of it this way
    thanks Alex Walker

  • 10.0

    Great post, this makes so much sence. As Johan stated, thanks for the eye-opener. This could also be a great way to explain to a customer why it is so important to get their content before starting any work on the project. You need to know where to lead the visitor and why.

  • solutionpoint

    good info. can you share some more related links.

  • My personal approach is more iterative – user interface way before database. How?

    Identify the most important pages in the website (e.g. trouble ticket submit form or shopping cart checkout) and cycle through these UI designs with the client to nail the business requirements and functionality. The more you learn about these critical pieces the deeper your understanding of the greater picture.

    Next, start building outwards from the key pages to determine what relationships (data, content, forms) are needed to support their technical features/information. Eventually you’ll end up at the homepage/index but you’ve started with the most important components first.

    Honestly, I cringe at the thought of writing highly abstract db queries before you even know what type of functionality you need to build towards. It may work with small projects, but that’s a death wish for larger sites or apps.

  • well, my approach earlier was sort of like this. I actually made a skeleton homepage first & then the rest of the site, & then went back to homepage to re-model or refine it. but then I saw the light & started doing the homepage in the end!! :)

  • svanpoeck

    This may be an interesting approach -although I personally agree more with Geof Harries’ approach- if you’re not designing in the perspective of obtaining a contract from a client.

    Indeed, most clients ask you to come up with two or more frontpage designs before they make the final decision to which company they’ll hand out the contract.

    So, from a business-only perspective, you can simply not afford to spend the time building your site bottom-up…

  • svanpoeck, I agree that this is an issue, but I wouldn’t under-estimate your clients. As long as take the time to explain the motivation behind your decision, most can appreciate your thinking.

  • asmictech

    Buy the idea also. I see it going inline with the “wire frame your site”. That is , you have static pages indicating aims of each page. then the design proper follows.

  • Honestly, I cringe at the thought of writing highly abstract db queries before you even know what type of functionality you need to build towards.


    can’t write the queries until the functional requirements are done (i.e. what does a visitor do on the site), but you certainly can start to design the database (if only in your mind, eh)

    queries won’t be needed until you actually build the pages, and to mock up the home page, you need only know the functionality, and perhaps a general idea of the permanent data that must reside in the database

  • anty

    Why have I never thought this way? I want to join the party which says thank you for the eye opener ;) thank you!

  • Pingback: | Weblog und Homepage von Christoph Hörl | Webdesign - Das Beste kommt zum Schluss!()

  • Great article!

  • glenngould

    I think, here we have the two main currents of design theories in art history. What you advice may be called the “baroque” approach contrasting with the “classical” one. Both have ups and downs.

  • Good stuff, I’ve been doing it similar to this way for the past few sites I’ve done and it works great!

  • creatweb

    Speaking to the client and finding out what they do and what is their most important service / product – and who is their most important client – this will help you guide into the right direction for your site structure.

    If a company deals mainly with architects for example, having a link called “architects” on the homepage will greatly please any architect that visits their site, because they immediately feel welcome.

    The website structure has to be discussed first before you start developing the site. For industry sites for example – the smaller the number of clicks to the information the visitor wants the better. Your website visitors don’t have any time to look for the information. Give them the information they want – fast.

    The most common mistake some companies still make is plastering lots of content on the homepage which is about the company and not about their products. This puts the company in the center rather than the client. I think this should be avoided and a summary of the services and/or products you offer should be highlighted on the homepage.

    Websites follow the same structure as authors who write books: They write the book first and then they write the introduction – the first page.

    Best thing is to test-drive the site with web visitors who know nothing about the product/service you want to offer on the site.

  • creatweb

    Forgot to say – once you have written your DB queries for your deep content pages, you can limit them and only extract a few results and display them on the homepage as snippets – this also invites the visitor to look further and hopefully raises their attention.

  • Matt

    Yep, this is exactly how is doing theirs. The site looks half empty right now, but their database, I’m sure, is 90% done.

Get the latest in Design, once a week, for free.