Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Reviewed the project plan for a redesign I'm working on which was put together by a project manager and not informed by a UX'er. The project plan asks for the site map deliverable to be documented first before wireframes. I just wondered if this is actually the case...in the past I've always had a high-level sitemap before I begin wire framing and then after wireframing I create a detailed sitemap? At which point should your site map be worked out?

share|improve this question
add comment

3 Answers 3

up vote 9 down vote accepted

Organizations are so hung up on deliverables that it turns a proper UX process into a deliverable process instead.

Which is bad UX.

The ideal is to educate the organization that UX isn't a step in the process with a set of defined deliverables, but rather it is part of the process itself, and the deliverables will change from project to project and even on a defined project, the deliverables will be living documents, not set-in-stone signed-off milestones.

UX is all about guiding the process rather than adding another layer of documentation.

To answer your specific question:

At which point should your site map be worked out?

The answer is, unfortunately: it depends.

In some cases, it's not worked out until after the first release and user feedback starts coming in.

share|improve this answer
add comment

It's a reality of the Internet that the sitemap for any given site is never "fully worked out"; websites need to be designed from the get-go to be scalable and to adapt to change, especially since most sites nowadays are driven by a CMS that allows people to add new articles and even pages as necessary.

For me the information architecture (IA) is designed as one of the first things after requirements (including personas) are established, since they help provide a skeleton upon which to hang things like wireframes and content inventory from.

It's important, though, to be willing to adjust the IA as requirements change, and to design it from the get-go to be adaptable to new pages being added. Sometimes that means your card sort (or whatever equivalent activity you perform) may not use the exact naming you use on the final website.

share|improve this answer
add comment

I would speak to your Project Manager and explain that the sitemap is a living document as stated above by DA01.

Site maps change constantly and never sit still, even during the development stage the site map can change, UX is about testing and refining so quite how they expect you to product a sitemap before hand is baffling.

A PM is all about deliverables which is where the arguments usually stem from, try to reason with them, if this doesn't work try and relate it to their job role. Ask them to provide a list of deadline dates that will not change at all throughout the whole design & development process. When they turn round and say, "hmmm things change so they the dates may change over time" simply reply with "exactly"

Saying that, there is nothing wrong with creating a high level sitemap at the start of a project, personally I will create a rough sketch of the sitemap as this allows me a basis to work from, I know the key components of whats to be contained within the app; homepage, contact, downloads, blog. I just build onto these as I go through.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.