Curious to know the current strategies of peers in their working environments. Here are/were mine:

Now: Communication primarily takes place in person and on email. We use Keynote docs (stored in a shared location) for presenting design options, and put annotated screenshots on a github wiki for spec. No more work is done than needed, meaning, if a decision can be communicated in person once (e.g., "it should be 60% opaque"), it's not later recorded. This comes at the cost of having a 3rd party/QA unable to verify, but at the benefit of expedience. Frequent f2f meetings.

Good: lightweight, easy to iterate
Bad: storing in a document feels outdated, no documentation of f2f decisions

Before (Mint): Everything was highly spec'ed and documented in Confluence and Jira. Prior to making it to spec, there were ample sketches and ideas from other stakeholders (Putorti, Patzer, etc.). When I felt we really hit our flow was we'd create a problem statement, it would turn into a spec, and then we'd fill the spec in with wireframes. Those would later turn into actual screenshots. Small tasks would be the same, but just in JIRA instead.

Good: clear sense of progression, design decisions and comments were well-documented
Bad: definitely not lightweight, took some effort to manage.

At Digg, we had a couple different ways. As a developer, the most productive time was when the designers would give us PSD mocks that were actually somewhat built from our existing UI widgets (they still had all the freedom they needed but working off of existing designs ensured consistency and some useful limits). Moreover, I know Tyson was concerned about how text rendering differed between PS and browsers so he built a small browser tool to grab accurate screenshots for text.

The best thing was however sitting literally next to the designers during development which made it essentially frictionless to iterate on a design; whenever there was something ambiguous or that wasn't fully explored in the designs, we could ask the designers.

*To preface, we have 2 designers and 3 engineers. Designers do all the front-end development as well (minus JS optimizations by engineers)*

We use a combination of Gchat, Github, and Layervault (in order of usage). Gchat for 1:1 communication, Github when we are tapping the whole team/if we are in the stage where things are in a pull request, and Layervault when we're strictly in a design mockup stage.

Example github PR/issue for group notifications:

Github is awesome. It's team-wide, email-friendly, and allows easy browsing during and after building to see how we got to where we are.

Julius, thanks for sharing that. We're pretty big on IM/gChat too. Our contractors use Kickoff, a Campfire/HipChat/[Private IRC]-esque collab tool as well.

So you use pull requests for design decisions?

I haven't found anything perfect; the current gig I'm working has a frontend pattern library done in DocPad with a record of all the widgets designed. Doesn't help the PSD -> code workflow, but I hate PSDs and try to code everything myself :D

btw the biggest problem I've found with using Git is that your .git/ folder becomes gigantic with every commit.

@justin - yes we use GitHub pr and issues to discuss product, design, and engineering and make decisions. It's easy to put a bunch of screenshots up via grabbox/cloud app and show your thinking process. Even the engineers who are more involved at a later stage in the process can skim back to see the evolution and understand what we've tried and what we missed.

(We are a bit spoiled in that we don't have this mockup to code barrier since the designers do the HTML CSS and initial JS. )

@jon Do you find a common library of assets helps or doesn't? I've always felt them to be very confining. When you hire a new designer, there should be a certain 'onboarding' to get them to be aligned on style, but to give them a PSD with widgets feels very meh.

Does your library contain thoughts about why decisions were made, like why a certain color, or why this typeface, or even higher level reasons for the aesthetic?

Depends on the feature or issue. For new features, major changes, or items whose impact are mostly visual, PSDs are plugged into keynote decks for presentation. Once it's approved, the deck becomes part of the spec; usually there's a sidecar of pixel specs and cut sheets in Photoshop, and for behaviorally complex situations, there may be Omnigraffle docs with matrices or flows. All of this comes together on a Wiki page that tracks notes and changes and is almost immediately out of date.

For smaller problems or bug fixes, whiteboard photos or one-off specs attached to the bug report do the job.

I should add that I both love and hate the Wiki. It's a clunky, crufty tool that requires a lot of overhead to maintain, but it has simple versioning, anyone can use it, and there have been times where its out-of-dateness was oddly useful.

There are better tools out there for documentation, but if you are required to use something that is 100% internally controlled (servers, etc) you can do worse.

@Julius: do you like layervault?

@melissa — Layervault's got a whole buttload of features, and of those, the ones that make me a paying user are:

1. Version control — no more design_v1.psd, design_v2.psd, design_v3_final_final.psd... I just work off one file. This alone is the biggest reason to use it.
2. Shareability — In the web UI, I'll be able to hand pick the specific versions that I think are worth discussing, and share those. Also comes with built-in discussion tool where you can mark individual things on the mocks, but I don't really use that.

But it really only has a use when I'm in an early mockup-y stage of a large design project (e.g. the groups page, marketing pages), not smaller features (e.g. the groups indicator in the roster).

@Julius Thanks for that. We've been using SVN—it's better than no version control but is not really the right solution for design assets.

One thing that's not common knowledge is that Dropbox has version controlling as well. From the web UI, it's possible to view / revert to a previous version of a file. Granted, they delete the old versions after 30 days, but it's still pretty good for design assets.

Dropbox for Teams offers an even longer recovery period. We used that at Mint for all our design doc storage.

And oddly enough, Time Machine is also a great way to view revisions...

So nobody uses Adobe's design revision/storage service?

Oh, they had one? I just automatically assume if it's from Adobe it's going to be a pain to use. (Remember the time you accidentally launched "Bridge"?)

Hahaha...same here. The key word being "accidentally," that OH NO DAMMIT BRIDGE! moment.

My take on this: screenshots in Github work great when the product has progressed to the wireframe / mockup phase.

But I tend to make the most important product decisions while sketching and evaluating options on paper / whiteboard (refer to the "how do you go big picture?" branch). I share these thoughts when we have product meetings, and sometimes with engineering if they ask, but we never record them at that granularity.

These kind of higher level decisions are more important to remember in the long run; usually when we revise a piece in the product months later, we wonder "Err, why did we do that in the first place?". Then again doing a write-up for each and every thing would feel way too heavyweight.

I used Bridge a few years back. It was non-awesome. Lots of problems with version stomping.

My worfklow is pretty old-fashioned. As a freelancer I only communicate my designs to the client in person to make sure every design decision I made can be defended and will be understood the way I meant it to be understood.
Also, that way I make sure I receive the feedback I need.