6

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.

Improve this question
11
  • 1
    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 ♦
    Commented Jul 11, 2013 at 11:08
  • 1
    I think this question needs reframing, to query about a strength or deficiency of one kind of tool over another.
    – New Alexandria
    Commented Jul 11, 2013 at 13:08
  • 1
    @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
    Commented Jul 11, 2013 at 16:28
  • 2
    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 ♦
    Commented Jul 11, 2013 at 16:32
  • 3
    @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
    Commented Jul 11, 2013 at 16:41

2 Answers 2

Reset to default
1

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.

Improve this answer
7
  • 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
    Commented Jul 12, 2013 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
    Commented Jul 12, 2013 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
    Commented Jul 12, 2013 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
    Commented Jul 12, 2013 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
    Commented Jul 12, 2013 at 16:00
0

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.

Improve this answer
3
  • 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
    Commented Jul 12, 2013 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 ♦
    Commented Jul 14, 2013 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
    Commented Jul 15, 2013 at 7:27

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