User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I usually create a site map and wireframes as delivery but what is the best way to add info about what content (text, forms, images, videos etc) that should be included on the individual pages?

Do you do individual wireframes for every page on the web site or do you use Excel, referring numbers on the site map or something else?

I'm looking for an effective way to communicate this to the stakeholders and the content providers.

share|improve this question

The deliverable should be a working site. UX can and should create any necessary working documents, but what is 'signed off on' as a deliverable should be the site itself.

Wireframes, prototypes, content plans, interaction specifications, technical specs, etc are all key elements, but no one type of documentation deliverable can possibly adequately address all of those requirements.

I'd suggest reading up on Lean UX:

http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/

The basic premise of Lean UX is Agile methodologies with the ultimate goal of delivering more working user experiences and less paper based documentation.

Why?'

"I'm looking for an effective way to communicate this to the stakeholders"

That's why. Axure. Wireframes. Etc...these things can't communicate the full spectrum of details that are needed to fully understand the UX to stakeholders. It's fine to show them these things along the way, but realize that they can't communicate the full spectrum of variables.

UPDATE:

For a specific answer, what we've done in the past:

  • wireframes for site flow/architecture
  • component library for UI interaction specifications
  • PSD files for design documentation
  • content indexes to map all the necessary content to the above.

The problem is that I've never seen all of those mesh in the end when it comes to actually building the site. So, I tend to see those as popular solutions, but not necessarily efficient solution.

share|improve this answer
    
I get your point. But sometime tje waterfall model works better and sometimes you need a web site disposition in order to get people start working with writing the content, doing the design, doing seo stuff (meta descriptions), taking photos etc. That is also in line with agile developement. – Tony Bolero Feb 7 '12 at 19:55
1  
I've never seen the waterfall process work in terms of leading to a good UX at the end. I understand waterfall is deeply entrenched in a lot of orgs (including mine). Getting people to start writing content is a bigger process issue. Content should be driving the UX, not the other way around (though I realize that's not often the case, unfortunately). – DA01 Feb 7 '12 at 20:41

I use Axure as an "all-in-one" for some clients.

Will create individual pages (using templates and widgets) with interactions and referenced notes. Then generate a tree from the pages. The tree can be edited and changed around after generating.

The output can be as PDf or interactive HTML, or a combination including the interactions and notations.

Often use the notes and the numbers they generate to map to my functional specs or user stories.

Can also do options/alternatives quickly using this method for comparisons/alternatives - and it's easy to continually adjust.

share|improve this answer
    
Dammit! I've just spent my bucks on Omnigraffle but it's Axure I needed obviously... – Tony Bolero Feb 7 '12 at 12:59
    
@Tony Axure has a large fan base. It also has a lot of detractors (myself included). – DA01 Feb 7 '12 at 19:17
    
Worth pointing out as well that Axure can also generate annotated reports and wireframes showing annotations for interactions etc - for the developers I work with, they often code with the annotated prototype site in 1 window and the developing site in another. – Peter Feb 7 '12 at 19:19
2  
The problem I have with that is for a developer to have a fully documented prototype that addresses all the points of interaction, they need a highly detailed prototype. If UX is creating highly detailed prototypes (as they should) I argue that they should be learning HTML, CSS and JS rather than Axure. Why learn a facsimile of the medium when you can work directly in the medium? (I realize there are places where Axure makes sense...it's just I see it used all to often INSTEAD of HTML, CSS and JS) – DA01 Feb 7 '12 at 19:22
1  
Because it's quicker and easier to prototype in Axure than to create directly in the medium - at least for sites up to a certain size (I've created sites of 40-50 pages in Axure, but probably wouldn't want to go much beyond that). Using Axure is easy. Using Axure well is a bit more difficult, and uses many of the same skills as effective software development. – Peter Feb 7 '12 at 19:32

Try Wireflows for building rapid prototypes which will showcase the items, features or sections of what goes inside the page, this is quite lo-fi when you compare it with wireframes. Wireframes will have much more details when compared to wireflows, which means that wireframes are good for interaction but wireflows are best in depicting the task flows, page features effectively.

Read the book Undercover user experience to find details on wireflows.

share|improve this answer

Yes. Your information architecture can be presented as wireframes or prototypes that show the particular pictures/elements you will be using (this will be medium fidelity)

If you only have a little time before the first meeting, it's ok to show a tree diagram for the information architecture and then explain what to the stakeholders what to anticipate for the next meeting.

Also, since you are so concerned about information architecture, consider how the information architecture may be different on the mobile as opposed to the desktop.

share|improve this answer

Content is one of the biggest headaches on any large website, and especially in large enterprise environments with multiple stakeholders.

Document until it stops saving you time

This means putting a lot of time and manpower in to doing something that you are always being told NOT to do, so expect to be challenged and questioned.

Decision
If it's an existing site, look at the defect log & identify how many defects could be solved in the short term by more detailed documentation. This will give you enough info to know if you're doing the right thing.

Approach
Assign unique identifiers to every widget of copy, and every wireframe. Create a sortable spreadsheet that references each widget

Disclaimer
I'm not suggesting this is the most efficient way to deal with copy. I'm just saying that there are occasions when spending time on detailed documentation is more efficient & ends up with better quality product. It's sticky tape and glue.

share|improve this answer

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.