0

My design team has been using MS Word via Sharepoint to deliver UX specs to our developers. Our documents include a section for: final visuals, content, wireframes, interaction notes, and business analysis flows. In short, these MS word documents are NOT short and are impossible to navigate as they are static linear documents. I would not wish these documents on anyone.

What my team needs (no compromises):

  • A design spec that contains IX, BA, Visuals, Content, & attached files
  • Simultaneous editing
  • Version control
  • A non-linear format with navigation
  • PC & Mac supported

What won't work: Axure, RTF docs & PDFs

What I heard others use: Zurb tools, Jira, a Wiki

What solution would you strongly recommend? Thanks in advanced for the help.

Improve this question
4
  • 1
    erm... HTML with a custom CMS? Universal, accessed from anywhere, and easy to maintain, backup, archive, etc.
    – Scott
    Apr 29, 2015 at 18:55
  • Hi Andrew, If you do not receive an answer, I would also try posting this question to softwarerecs.stackexchange.com.
    – AndrewH
    Apr 29, 2015 at 21:17
  • Hi Andrew, welcome to GDSE and thanks for your question. If you want to know more about the site, please see the help center or ping one of us in Graphic Design Chat once your reputation is sufficient (20). Keep contributing and enjoy the site!
    – Vincent
    Apr 30, 2015 at 7:11
  • or also try ux.stackexchange.com
    – Voxwoman
    May 1, 2015 at 20:25

1 Answer 1

Reset to default
1

My design team has been using MS Word via Sharepoint to deliver UX specs to our developers

Heh. I've been there. I sympathize.

The problem is delivering UX specs. That means you're stuck in a waterfall process that avoids collaboration. As such, you can't ever succeed.

For this to work in a waterfall model, UX needs to take ownership of the presentation layer code and actually create the interactions. This then becomes the specification.

Anything short of that will always have big lost-in-translations issues no matter how heavily documented. In fact, I've found the heavier the documentation, the more confusion that it can lead to as developers start referring to month-old specs that have been updated 3 times since.

What solution would you strongly recommend?

as you've probably guessed, I strongly recommend none of those. You're just setting your team up to be a documentation team, which no one wants, and no one really benefits from anyways.

The options that I've seen work to some degree (at least way better than the heavy documentation model) is:

  • Switch to Agile Development (Lean UX) and/or...
  • Have UX own the presentation layer and/or...
  • Communicate constantly with the dev team. Have a lot of the specs come from joint collaboration--not a 2 month old document.

UX should never be a documentation/specification factory. They should be facilitators and sketchers. (One could argue that's how all members of the product team should operate).

Improve this answer
12
  • Can you elaborate on "UX needs to take ownership of the presentation layer"?
    – Andrew
    May 1, 2015 at 18:16
  • @Andrew I'm a huge believer in the UX team being the ones that create the HTML, CSS and JS that influences the UI. I don't believe true interaction design can happen on paper or in Axure. It has to be crafted in the medium it will be used in. The most succesful UX<->Dev team relations I've been a part of have had people that straddle the two. Either the UX team has UI developers on their team and/or the UI Dev team has UX folks on their team. The deliverable is no longer a heavy specification document, but the actual product.
    – DA01
    May 1, 2015 at 18:46
  • Where I've seen it fail miserably is when UX is 'responsible' for UI, but at the mercy of an entirely different dev team--often a vendor. What happens is that UX gets blamed for things like "well, the spec document wasn't detailed enough". But the reality is that no UX document can fully address every single interaction and scenario and issue that will come up during the process of actually building something. So if UX is going to take the heat for the UI, they might as well own the UI.
    – DA01
    May 1, 2015 at 18:48
  • I see UX as contributors to thought leadership and driving designs/solutions based on a user centered vision. UX designers should own the creative process and solution design, not developing the solution as that would prevent designers from focusing on research and vision (there's only so much time in a day). As the dev teams are in their sprint, designers should be involved in the process to ensure efficacy. What you're referring to is not a UX designer IMHO, but an interaction developer. And I don't see how the addition of an IX dev eliminates the need for documentation.
    – Andrew
    May 1, 2015 at 21:04
  • @Andrew we have very different opinions on that. :) I certainly agree that there needs to be focus on research and vision. What I am arguing for is for UX to not be contributors but facilitators. An IX dev working with the UX team means they don't need a document to tell them what to build. They are a part of the whole creative process and solution design. Don't take away from UX work to do IX work. Add IX work to the UX work that's already being done.
    – DA01
    May 1, 2015 at 21:34

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.