Musings on Customization, Team Reactions, and More
Recently, Doug Brashear (a user experience designer at a client site that has adopted EightShapes Unify) asked the Interaction Design community about their reactions and implementations of the EightShapes Unify framework. Since my responses may be valuable to the entire community (rather than limiting the response just to our shared client stakeholders), here’s a stab at what we’ve seen.
DB: Did you modify the system pre- or post-rollout to better match your organization or clients? If so, would you mind sharing the reasoning?
NC: Reuse – rather than reinvention – is the spirit of the whole system, really, so clients aren’t interested in some generic set of wireframe templates that force them to recreate their own designs from scratch. Instead, they ask to “gimme what we’ve got so we can communicate what we’ve got and have a good foundation to innovate from.”
A wireframing library (specifically the wireframe template (.indt) and all it’s grid, typography, other styles and a complete component and page type library) is always fully customized to a client’s existing design system. Sure, common libraries like form controls, buttons, tabs, and a range of Yahoo patterns can be helpful. But it’s the specific design assets that their staff can use that are far more valuable.
On the other hand, deliverable document templates and their associated libraries have ended up being almost exactly the same across nearly all of our 12-15 documentation system engagements. Make no mistake, UX teams want to firmly stamp their corporate identity, if not their team identity, on deliverable templates. But only one group has significantly refactored master page layouts, color, and typography beyond simple tweaks that require only an hour or two.
That said, it’s not unheard of for teams to update or create new page patterns like a functional spec, creative brief, annotation standards, or even a full recipe for creating something like a competitive analysis. While the existing page patterns are extensive, each team has their unique style, facets, and depth with which they communicate. Those conversations around page patterns are really deeper around design communications in general, and how their own workflows support the authoring and consumption of such artifacts.
DB: What kind of reaction are you seeing from project stakeholders, developers and designers?
NC: Reactions vary widely, but some common themes include:
- From designers: InDesign is different and perceptibly harder (at first), but a system and deep set of reusable assets eases that transition and enables designers to have a higher level of forgiveness for that learning curve. That said, there are also later realizations that the learning curve wasn’t that InDesign was harder (than a Visio or Omnigraffle), but instead just different.
- From designers: Initial perceptions of creating more documentation that are changed later by inspirations of creating better or more specific documentation, and acknowledging that by separating design files (like wireframe screens) from deliverable documents creates opportunities for more lightweight and rapidly iterated “documents†in greater quantity.
- From developers (and actually, QA): An appreciation for greater clarity in annotated design screens, and (if embraced by the designer) better and clearer structure for those annotations. I’ve gotten no better feedback on my deliverable effectiveness than from a QA colleague who (unwittingly) participated in countless informal “deliverable usability tests.” By the end of the project, I’d used the EightShapes Unify approach to refine and deliver something that was completely tailored to what he needed. But, this is really a tough interpretation because every culture, workflow, and value placed on deliverables is different. Even today, I was exposed to a new workflow with different definitions for who within (and outside) a user experience organization actually own the communication of requirements to an engineering team. Interpreting such reactions is always highly dependent on the context of a team’s workflow and process.
- For stakeholders: Again, tough to say because the EightShapes Unify system and approach is highly dependent on context. That said, it’s not uncommon for me to obscure the ease of producing deliverable that appears so polished and that elicits unexpected reactions like, “Damn that’s a sexy project plan!” or, “How’d you change all those wireframes so fast?”
Do your designers use the InDesign wireframes as the basis for their comps, or start from scratch in their tool of choice?
I don’t endorse painting wireframes. That’s lunacy. But certainly wireframes are to serve as a lower fidelity inspiration and structure from which visual designers create final comps.
That said, there are design systems mature and stable enough, like Sun Microsystems (www.sun.com/webdesign/) that comps aren’t part of the workflow for many IA and content-based projects. Instead, the wireframes and their attendant mapping to the component library are sufficient enough for (a) stakeholders to understand the proposed design solution and (b) engineers and / or publishers to create the page. Visual designers are involved in reviews, but the bulk of their effort becomes more focused on evolving the visual system rather than comping nearly duplicative layouts that tread no new visual ground.
How do you manage your source files (e.g. dedicated file server, TeamShare or Basecamp site, true Doc Management Solution or other)…are you happy with the solution?
Context is really important, and some teams within even massive corporate structures don’t have access to version control systems (like Subversion) or even shared drives. That said, typical storage solutions cover the range of:
- Local drives and file swapping via email
- Share drives
- SharePoint / Basecamp-like project management systems (although I don’t recommend this for sharing anything except deliverables others consume
- Subversion, installed on your corporate network and supported by someone who gets it. If you have the infrastructure and the designer patience to learn the over-the-top processes for checking files in and out, nothing beats it. We’ve also succesfully used an online subversion application called beanstalkapp.com. That said, we go for subversion on a project basis only when the scale of collaboration warrants: if it’s an IA working in isolation then it’s unnecessary, but if you’ve got 4-5 IAs syncing frequently on a holistic experience design then it’s essential.
What online forums or communities do you use to connect with other UNIFY users (if any)?
Interestingly, the chatter on EightShapes Unify ebbs and flows, and like most collaboration within design teams, its more ad-hoc and peer-to-peer learning rather than via online, archived discussions.
I’m more than happy to respond to feature requests or even seemingly inane “How do I…” inquiries directed at my email address or twitter handle of @8sunify. Admittedly, most of the questions, endorsements, and shouts of “Eureka!” from our 5,000+ users that have downloaded EightShapes Unify come via Twitter.
Lastly, while we incorporate items like coaching time, “office hours”, brown bags, and even scheduled review sessions for our clients and colleagues to get help, its interesting that it’s the most underutilized service. Designers may lack confidence to ask questions, be too busy or distracted, or may simply not care enough about improving their skills in this area. But I’ve not done enough asking around to get to the root of that gap.