Published on <a href="https://blog.prototypr.io/using-axure-as-a-single-source-repository-of-client-deliverables-7f1e79d07b93?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Matt Drazin 
How we evolved our design process to better leverage our tools and eliminate client confusion.
For UX professionals, Axure is an extremely versatile tool. We know it can be used to create anything from simple wireframes or diagrams to really complex prototypes and interactive demos. At Isobar, Axure is one of our main UX tools and recently we’ve been using it a bit differently. We adapted Axshare (Axure’s Cloud Prototype sharing platform) to be the single source of all of our work, eliminating deliverable version distribution issues, “update blindness” and general client confusion to what’s final, in progress and what has been approved.
In past projects, we followed a traditional process. Simplified, yes, but detailed design process generally follows — make wireframes, review with the client, document wireframes, hand off to visual design, hand off to developers. You know… Waterfall. On large projects, this methodology can get ugly quickly and while I’m not going to get into the details of Waterfall vs Agile, our goal is always to make high quality work that the client approves of and that developers can build, and of course, users can use.
In actuality, while most of our projects are Agile in spirit and intention, we often end up with a “deliverable soup” consisting of versioned PDFs of the wireframes with annotations, sitemaps, keynote files with visual design artifacts, style guides with their own versioning and no good way to keep track of it all. In an effort to simplify and control all of these issues, we tried something different. In the end, we created a comprehensive and contextual ‘living document’ that was not only well received by our client and our developers but makes for a great case study.
We were set on using Axure as our main design tool, as we wanted to leverage and iterate on existing source materials that were created as a deliverable from a previous phase. The goal of our next phase was Detailed Design, for which we needed to create a full suite of pages, designs, interactions and annotations for every possible edge case and permutation of the design system.
First things first, we set up a structure that worked for both the UX and Visual Design teams. We settled on a ‘page by page’ breakout approach where we isolated all the major pages of the site and worked on them in sprints. This allowed us to break out chunks of the site and tackle them individually. We also settled on a shared numbering and naming convention with the Visual Design team. This allowed the quick identification and maintenance of individual states throughout the design.
As a way to organize and present the We included up an Introduction section where we housed things like a Title Page, Site Map, TOC and leveraged Axure’s ability to link pages together. One of the main benefits of using Axure, is it’s ability to create a contextually linked network of documentation as demonstrated in the Table of Contents below.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*F_FlH6I_bR1ePa6td3juBg.png">
We outlined the remaining sections and redefined our process for populating them: Review existing wireframes to assess what was still valid, evolve wireframe within Axure, review new direction with client, apply visual design styles, publish visual designs to Axure, replace and archive wireframes, annotate visual designs in Axure, provide Axshare link to client for their review and to get sign-off. This new process allowed us to optimize the output of client-friendly deliverables and marry them with functional annotations with minimal inconsistencies and less parallel deliverables.
As we refined this new approach, we discovered doing certain things would make the end product more comprehensive and easier to consume for the client and developers. We identified all common components of the pages, isolated the global elements and broke them out to the Framework section of the document. Here we could go into detail about the interactions, without worrying too much about context, giving us a place to write detailed documentation and contextually link back to this framework section when the components appear on the individual pages.
In breaking out the framework, we essentially created a design system as we went along. As we populated each individual page, we wrote detailed annotations and were able to use Axure to add references and link back to other pages in the document, adding the needed context to make this a comprehensive living document. We needed to focus on controlling what and when the client saw artifacts with annotations. While we know Axure has its own built in documentation system, it’s not exactly client friendly. Our client was used to a traditional documentation style and delivery methods, so we needed a way to use what was familiar to them, but evolve it in such a way that alleviates some of the process pain points.
<img alt="" src="https://cdn-images-1.medium.com/max/1008/1*jsNWFhj4geBwM38DsfUREg.png">
The living document became the single source for all of our final client-facing deliverables. This solved a lot of problems for us as we were able to give the client access to the password protected Axshare URL for viewing published pages on the web . We fully controlled the access and the client only got to see the latest of the materials. What they saw was completely controlled by us.
Now, this is not exactly paving new ground. Other teams have done similar things at Isobar. One had created a custom CMS to post deliverables to a password protected site to get around some very strict security requirements, and while the idea of what they created was a good one, the execution was a bit cumbersome. They had to use an HTML editor to copy and paste code snippets to create new pages for new features, take screenshots of Axure designs, associate the visual design comps to the wireframes and upload it to the CMS to be published.
The final product was a page by page breakout of each page of each section displaying full final Visual Designs with the UX team’s written annotations.
Next time we deploy this approach to design, we’ll be sure to change a few things within the Annotation section. One issue we’d hope to resolve is the alignment of the markers as currently the text would occasionally be misaligned due to some font rendering issues on the client machines. While it always looked the way we wanted on the designers’ machines, the kerning would be off on client machines with different operating systems, browsers and devices.
Second, the contextual links back to other pages had to be entered and maintained manually. That said, if those page names changed, we had to go in and change those too. Checking links was part of our QA process and next time we’ll create a variable with the page names of every page and reference it via code.
Lastly, the manual nature of placing, moving and maintaining the Visual Design images in Axure isn’t a seamless experience. We didn’t know it at the time, but there is a way to reference a image file stored in say Dropbox or somewhere online and have Axure display that image. Doing this would allow us to just make the image reference once and then update the image file as many times as needed. It should display properly in Axshare when published as its grabbing the latest version from the web.
In addition, we would have liked to be able to leverage Axshare.com’s check-in notes to create a change-log of sorts. While the Axshare History section contains all check-in notes, without copying and pasting there is no way to leverage the data.
Along the way, we learned a lot…
Page numbering and naming conventions are important to consider early on when making a project of this size and scope. Having separate teams with separate source files (Axure, photoshop and pngs), adhering to a universal system helps keep everything in sync, therefore streamlining the replacement of wireframes with images for our final deliverable.
Working in tandem with another team who was developing visual designs in Photoshop, the UX team was responsible for maintaining, replacing and error checking the visual designs in Axure. This means that every time there was a minor fix for spacing, color or other design elements, we had to update every affected page. However, since the naming conventions were in sync, it was easy but time consuming using Axure’s image replacement process.
The most common question about this approach is “would you do it like this again and is there another tool worth using?” The answer is yes, to both. There are, of course, a few things that moving forward would change, but overall the process has been incredibly helpful and productive. Here are a few pros and cons:
Pros • Great starting point for new projects, with or without existing materials • Eliminates version confusion • Leverages the Axshare cloud hosting for deliverables • Naming and numbering conventions save a lot of time if planned early
Cons • Difficult to include clients in the process (likely not Axure users) • Axure is not a Visual Design tool and all visual designs need to be imported • The manual nature of some tasks such as importing and updating files is tedious
We are always looking for new ways to refine and rethink processes to benefit our clients and are always happy to pass on the insight!
Feel free to <a href="http://gmail.com">reach out to me</a> for more information on this topic.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=7f1e79d07b93" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/using-axure-as-a-single-source-repository-of-client-deliverables-7f1e79d07b93">Using Axure as a single source repository of Client Deliverables</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using Axure as a single source repository of Client Deliverables

Top Stories