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.

I often work with teams that are both co-located and have team members, such as front end developers, in another country. If you work on high end projects what are the best practices in using online collaboration tools you have discovered to communicate requirements and to share things like interaction style guides?

Do you find a particular integration (mix) of tools works best?

I have worked with Agile story management systems and Wikis and have issues with important information being lost in a maze of pages. I often share prototypes to communicate to everyone how a project is going to work and have used online spreadsheets and design deliverable collaboration tools, like base camp, to keep everyone updated with aspects such as site structure, overall requirements and the lastest designs.

So, when working with stakeholders, designers and developers which format or setup of online collaborative tool has worked best for you? How has it worked for you within the course of your project? I am not just talking about the overall project workflow(s) including personas through to final designs.

share|improve this question
We can't recommend specific tools / sites etc, that's just a shopping request so you'll have to take that part of the question out, but if it is about the type of tool to use, the benefits of that type over others then that's more suited to this site. –  JonW Jul 11 '13 at 11:08
I think this question needs reframing, to query about a strength or deficiency of one kind of tool over another. –  New Alexandria Jul 11 '13 at 13:08
@JonW The difficulty here is that an answer of 'I use a Wiki' is less helpful than I prefer to use 'a Wiki and good wikis are X and Y'. So I don't agree it's a shopping request. For example if I was asking about prototyping tools then saying I use Axure would be helpful. –  Stewart Dean Jul 11 '13 at 16:28
It might be helpful to recommend specific products, but that's not what this site is for. It's a Question and Answer site, not a product recommendation site. Axure might be a good application today, but what if something better comes out tomorrow? Then anyone who has suggested Axure as the 'correct' answer and had that answer accepted would then be the wrong answer. That's why Stack Exchange sticks to problems and solutions not product recommendations. –  JonW Jul 11 '13 at 16:32
@JonW I understand what you are saying and have ammended my question to focus more upon the types of tools and how that tool fit within the process. I still don't agree but am happy to stick within the guidelines of the site. My main focus is on approach to tool and how they fit within the process, not the products themselves. The shopping request rule makes sense in many cases, in this case it's a not the main part of the question. I'll again edit to remove helpful examples of applications. –  Stewart Dean Jul 11 '13 at 16:41

2 Answers 2

I've had several gigs where the teams are heavily dispersed throughout the globe. That said, even when designers and developers are across the hall from each other, the same challenges exist.

In general, I suggestion:

Reduce Documentation as much as possible

The biggest burden is heavy documentation. Wireframes, design specs, sample code, content documents, flow charts, prototypes, research documents all floating in space between sharepoint sites, axshare sites, shared drives, email in boxes, google docs, etc.

Documentation is necessary, of course, but try to reduce whenever you can. Give documents an EOL.

If not in a formal Agile company, try to work 'agilish' unofficially

By 'agilish' I mean borrow as much as you can from some of the habits of good agile teams--namely frequent but short conversations. Have 15 minute daily standups. Use the phone and instant messenger to ask quick questions rather than long emails are huge meetings.

And get into code ASAP. The sooner you can throw away the wireframes and prototypes and focus on enhancing the actual UI that is being developed, the better. Spend time making good code, not extra documentation. ;)

embrace component libraries

The best way to smooth UX/UI and Front End Development is to try and borrow as much as you can rather than begin from scratch on every project. This is especially true in a corporate environment where you have one primary client.

If you need to indicate an accordion in your wireframes, for instance, don't re-invent it but just refer to 'use accordion component #2' that has already been built for the previous project and is now documented in a shared component library of some sorts.

share|improve this answer
I agree with your overall approach, although there is a danger about rushing to a solution if you don't have the overall problem nailed - flows should ideally come before interface sketches for example. What I was looking for is the way collaboration tools have made things like component libraries and style guides easier to share between, say, developers and UX people. –  Stewart Dean Jul 12 '13 at 7:39
Style guides, IMHO, is a good example of excessive documentation. Ideally the style guide is CSS. I know that's an idealistic solution, and not always achievable, but I feel it's something to strive for. –  DA01 Jul 12 '13 at 7:44
As many UX people don't do CSS that does make it harder to update. Also adding notes and rules is a central requirement in many cases. Plus many projects I work on aren't websites! –  Stewart Dean Jul 12 '13 at 7:54
@StewartDean well, like I commented earlier, how you do things is highly dependent on the teams you work on and the methodologies being used. Some teams still require the heavier documents such as style guides. I've found that they tend to get in the way of innovation (as development tends to fall back on it rather than pushing it forward) but that's just in my experience on the teams I've worked on. –  DA01 Jul 12 '13 at 15:58
I suppose I can sum up my philosophy in that I cringe when I see UX teams turned into documentation writers and maintainers. That all tends to get in the way of actually getting UX done. ;) –  DA01 Jul 12 '13 at 16:00

I find that a mix of approaches work the best, and this doesn't necessarily mean a mix of tool. In fact, sometimes this ends up being the same tool used in different ways. The problem I come across often is the distinction between high level and low level details, as sometimes developers want pixel perfect specifications while the design is still evolving, and if you provide low fidelity mockups and wireframes it is difficult for some to visualize the design and the interactions. Also, it depends on the people that you are communicating the information to and the workflow/processes that they employ. You certainly can't get away with just uploading screenshots and mockups to a repository, and you definitely can't rely on people reading or following the style guides (not to mention keeping them up-to-date).

Microsoft Expression Blend, Axure and Indigo Studio are some tools that allow you to use one tool for different purposes.

share|improve this answer
It will always be a case one size does not fit all and thanks for your thoughts. My issues is that often a repository can turn into more of a dumping ground rather than a communication tool, are there ways around this? For example automatic notifications help a lot. Is it simply a case of following up each update of output with reminders and telling people in, idealy, a daily standup? –  Stewart Dean Jul 12 '13 at 7:42
Well, this isn't really strictly a UX question, although it is commonly encountered in a UX team. I think it requires a common communication process combined with a shared vision/direction of the project. The problem with prescribing a particular process is that it won't necessarily work for some teams and projects. I would advice looking closely at the root cause of the problem before coming up with a solution. Dumping things into a repository can be a sign that there is too much things to do ahead of documentation, or that people are not really talking to each other, or any number of things. –  Michael Lai Jul 14 '13 at 22:41
It is directly related to UX process so, in my view, is more about UX than, say, asking what colours work best on screen. The amount of documents being produced is often not the issue as I'm adept at keeping these light but, at the same time, avoid the mistake of rushing to interface designs. So there needs to be a place where site maps, flows, user profiles and key style guides exist. Too little documentation can be as dangerous as too much with lean UX having the danger of leading to a 'quick fix' culture. –  Stewart Dean Jul 15 '13 at 7:27

protected by Community Jun 5 at 13:49

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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