I'm working in a small project team as an interaction designer. The product is in development and not released to the public yet.

In the beginning all the product's features have been designed in wireframes in one document. In this case Powerpoint. The document includes enough information so the whole team understands it.

This is all working fine. Developers and designers take a look at the document, and design and develop it.

If the application is in a state that we can run some tests with users, we test it and of course after testing, some of the interactions need to be changed.

  • Sometimes I change it in the document itself, and tell the teammembers to pull a new version from the server.
  • Sometimes I fill a bug and a developer gets notified.
  • Sometimes I email 3 new slides to one person to work on that.
  • Sometimes I I share a change in person.

I keep coming across this situation and was hoping someone would have some tips on how to deal with this.

How do you keep you and your team members informed of the new changes? How do you communicate changes to your team members. How do you order your documents? Are there any tools that can help me?

  • Are you referring to a design bug or a code bug?
    – JohnGB
    Commented Sep 27, 2011 at 8:46
  • This sounds grossly inconsistent. What is the point in a central documentation for point 1 if you're going to subvert the system via points 2,3 and 4. See also this question about prototyping tools, but it seems to me you need project management style tools like Basecamp or similar to manage the overall process in a lovely cohesive and transparent teamly togetherness! Commented Sep 27, 2011 at 9:06
  • Design. Normally I will email out the following: Slides 3, 5 and 8 are changed, please take a look.
    – Wousser
    Commented Sep 27, 2011 at 9:09
  • @RogerAttrill yes you are right, it is very inconsistent. That's why I posted this question, to get some answers on how others are dealing with this. Thanks for your comment.
    – Wousser
    Commented Sep 27, 2011 at 9:11
  • @RogerAttrill So how would you manage this in basecamp? Would you make a new task to look at the (updated) document? Or Add a new task with some slides attached?
    – Wousser
    Commented Sep 27, 2011 at 9:12

5 Answers 5


Having a canonical place for wireframes is the best way to avoid confusion. I tend to split up wireframes into features. Im generally working on one feature / section of the site at a time, and that avoids the giant master document problem.

If you're communicating them to developers, upload the wireframe to the story the devs are working on. When you update the wireframe, update the story with the new one.

For the rest of the team, use something like basecamp or backpack to save and update them in one place.

We went a step further and use myBalsamiq, the hosted version of balsamiq mockups. They track changes in versions and have feedback from users. For me, that's been the best way to solve this problem. You can attach a particular version to a story and then keep working on the feature.

  • I'm accepting this as my answer. I am going to split up the wireframes per feature, and tell the team members if a specific feature is updated.
    – Wousser
    Commented Sep 28, 2011 at 8:15
  • Great! Let me know how it works for you. Im @alphacolin on twitter.
    – sudonim
    Commented Oct 4, 2011 at 20:00

My advice:


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. :/

  • I would agree that that the wireframes should be an early part of the design process. Beyond that point, you need other methods of change control. Commented Sep 27, 2011 at 17:02
  • "change control" is a great term! I agree. I think one method is to adopt a component library concept--though that is certainly dependent on the type of software/web product one is building.
    – DA01
    Commented Sep 27, 2011 at 17:34

When doing wireframes in Visio I use a script to auto-generate a table of contents. I then make a habit of tweaking the layout name to indicate minor/major changes by suffixing a "-" or "+". The script compares against the previous TOC and colour codes each line: small changes get green, big changes get blue, and new pages get red.

  • I am interested in how you use a script to auto-generate TOC for Visio.
    – Michael Lai
    Commented Jul 23, 2013 at 23:25
  • I dont have the script to hand (not on a PC), but I originally found the script via google.
    – Erics
    Commented Jul 24, 2013 at 14:24

We use 4shared.com to share files, and configure settings according to our need,if anyone update any document it sends the notification to the whole team.

  • And the team is going through 50 pages every time to find out what is changed? Or do you use some index to indicate what is changed? Sharing files is not the problem. Thanks for your answer.
    – Wousser
    Commented Sep 27, 2011 at 9:33

Process is more important than the tool! Communication and properly structuring the workflow will make it work regardless the tool you use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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