2 added 36 characters in body
source | link

My advice:

DON'T!

Alas, what you describe is a nearly universal problem in any team structure that depends on wireframes as a source document for everything else.

IMHO, wireframes are meant to get ideas down on paper. It's a rough sketch. Easy to quickly modify early and get everyone's ideas folded in.

At that point, it's a baseline document for the UX team to begin the process of building out the product. I now consider the wireframes 'done' and any design changes going forward (there will be a lot of them) need to be handled outside of the wireframes for the simple reason that maintaining wireframes is a huge burden of time and organization.

In an ideal world, your team isisn't gigantic and is instead a manageable size and everyone can handle the updates as they go in an Agile process.

I realize that's not always the case and that it's inevitable that many of us are stuck on large organizations that are hell-bent on making copious amounts of paper documentation. In those situations, I agree with what others have said...ideally the wireframe is a web page that everyone accesses live. If it needs updating, that one location is updated and by default, everyone gets the latest version. If it's not HTML you run the risk of people taking the versions offline and then being completely out of sync.

Granted, for that to work, you need a UX team with some HTML skills which is another problem in a lot of organizations. :/

My advice:

DON'T!

Alas, what you describe is a nearly universal problem in any team structure that depends on wireframes as a source document for everything else.

IMHO, wireframes are meant to get ideas down on paper. It's a rough sketch. Easy to quickly modify early and get everyone's ideas folded in.

At that point, it's a baseline document for the UX team to begin the process of building out the product. I now consider the wireframes 'done' and any design changes going forward (there will be a lot of them) need to be handled outside of the wireframes for the simple reason that maintaining wireframes is a huge burden of time and organization.

In an ideal world, your team is gigantic and everyone can handle the updates as they go in an Agile process.

I realize that's not always the case and that it's inevitable that many of us are stuck on large organizations that are hell-bent on making copious amounts of paper documentation. In those situations, I agree with what others have said...ideally the wireframe is a web page that everyone accesses live. If it needs updating, that one location is updated and by default, everyone gets the latest version. If it's not HTML you run the risk of people taking the versions offline and then being completely out of sync.

Granted, for that to work, you need a UX team with some HTML skills which is another problem in a lot of organizations. :/

My advice:

DON'T!

Alas, what you describe is a nearly universal problem in any team structure that depends on wireframes as a source document for everything else.

IMHO, wireframes are meant to get ideas down on paper. It's a rough sketch. Easy to quickly modify early and get everyone's ideas folded in.

At that point, it's a baseline document for the UX team to begin the process of building out the product. I now consider the wireframes 'done' and any design changes going forward (there will be a lot of them) need to be handled outside of the wireframes for the simple reason that maintaining wireframes is a huge burden of time and organization.

In an ideal world, your team isn't gigantic and is instead a manageable size and everyone can handle the updates as they go in an Agile process.

I realize that's not always the case and that it's inevitable that many of us are stuck on large organizations that are hell-bent on making copious amounts of paper documentation. In those situations, I agree with what others have said...ideally the wireframe is a web page that everyone accesses live. If it needs updating, that one location is updated and by default, everyone gets the latest version. If it's not HTML you run the risk of people taking the versions offline and then being completely out of sync.

Granted, for that to work, you need a UX team with some HTML skills which is another problem in a lot of organizations. :/

1
source | link

My advice:

DON'T!

Alas, what you describe is a nearly universal problem in any team structure that depends on wireframes as a source document for everything else.

IMHO, wireframes are meant to get ideas down on paper. It's a rough sketch. Easy to quickly modify early and get everyone's ideas folded in.

At that point, it's a baseline document for the UX team to begin the process of building out the product. I now consider the wireframes 'done' and any design changes going forward (there will be a lot of them) need to be handled outside of the wireframes for the simple reason that maintaining wireframes is a huge burden of time and organization.

In an ideal world, your team is gigantic and everyone can handle the updates as they go in an Agile process.

I realize that's not always the case and that it's inevitable that many of us are stuck on large organizations that are hell-bent on making copious amounts of paper documentation. In those situations, I agree with what others have said...ideally the wireframe is a web page that everyone accesses live. If it needs updating, that one location is updated and by default, everyone gets the latest version. If it's not HTML you run the risk of people taking the versions offline and then being completely out of sync.

Granted, for that to work, you need a UX team with some HTML skills which is another problem in a lot of organizations. :/