In this two part series I’ll be talking about some of the common challenges you may face when working on large scale projects as a UX team. In this particular post, I’ll be discussing wireframing as a team as well as the importance of version control and change logging.
Too many UX’ers spoil the broth
It’s an all too familiar situation in agency life; in order to meet aggressive client deadlines, timelines and resource plans dictate multiple UX designers will be working on the same project at the same (sometimes from different locations).
For those of you who have been in this position before, you’ll be all too familiar with the common challenges you experience when this happens:
Challenges
- C1. Making sure all team members are working off the latest version of the file.
- C2. Implementing version control to allow for rollback/disaster recovery when changes have been overwritten.
- C3. Keeping consistency throughout the project file, by re-using UI patterns, masters and consistent styling.
- C4. Catering for different team members with different levels of experience (keep it simple).
Below you’ll find some tips on how to overcome these challenges.
Working as one UX Team
Challenges Addressed
- C1. Making sure all team members are working off the latest version of the file.
- C2. Implementing version control to allow for rollback/disaster recovery when changes have been overwritten.
To tackle the first two challenges, you’ll need to ensure the wireframing tool you’re using on a given project caters well for multiple users working on the same file at the same time.
In my current role (agency) when I arrived, various tools had been used to create wireframes in the past from Balsamiq to Omnigraffle, with limited success. Each tool was perceived to have it’s own strengths and weaknesses, however, they all fell down on large projects when multiple users needed to work off the same file at the same time.
Being an advocate of Axure, I introduced to the team to the ‘Team Projects’ feature in Axure which allows multiple users to work on a the same wireframe file stored in a shared directory through a check in/out process.
In the past, I had always worked client side in smaller UX teams where all team members checked team projects into (and out of) a centralised Client Server location and accessed directly from the office or remotely via logging on to a VPN first. In this agency environment however, we needed a way to better cater for ‘remote working’ to cater for those ‘WFH’ (working from home) days and catering for freelancers.
After some investigative discussions with the Systems Admin team and Techies, we were able to create a repository on the organisations SVN to store our team project files. This provided countless benefits as team members no longer needed to be connected to the office network to check in and out their updates and pull the latest version of the team file allowing for greater remote working flexibility.
SORTED!
Update: Axure have integraed team projects into Axshare as part of Axure RP8 meaning you don’t even need to arrange for an SVN repository to be set up. Pretty neat right?
Version Control
I can’t stress how important version control is on large projects, it has so many uses:
Benefits
- Allows you to quantity time spent on jobs and the progression of outputs.
- Allows you to discuss and revisit ideas with clients to understand in/out of scope requirements.
- Allows you to recover/roll back changes where changes are accidentally overwritten.
- Allows you to quickly revert to a previous version where requirements change.
On large projects where you have a lot of pages and requirements, it’s not uncommon for some pages to go through 3–4 revisions before you get to final ‘sign off’. Consequently, on larger projects your wireframe document could easily contain 15–20 page wireframes, accounting for 3 revisions of each page that can be in excess of 45 wireframes. It’s therefore easy to see how things can become very messy, very quickly if you don’t have a revisions and archive process in place.
Again, it’s advisable here to understand if and how the tool you’re using to produce your wireframes can handle revisions and agreeing as a team how to handle revisions from the outset.
Another great feature of using the Team Projects feature in Axure is the way in which you can handle revisions as a team. As users check in and out changes they can provide a ‘check in note’. These notes and check in’s are then logged in the ‘Team Projects History’ feature which allows you to review information such as:
Visible Change Information
- When changes were made (Date)
- Who made the change (Author)
- What was changed (Check in Note)
In addition to the Team Project History feature in Axure I also do the following:
Nice to haves
- Create an archive folder to contain previous page versions (I append the date to the end of the file name i.e. ‘section-landing-page-24–11–15’)
- Keep a manually written client facing change log which keeps a record of date, author, page name and changes made (if possible reasons for the change)
Ensuring Consistency
In the next post we’ll look at how you can ensure consistency throughout you’re wireframes by undertaking component audits and using widget libraries.
Originally published on my UX Blog www.kyecass.com
Found this article useful? Please feel free to leave a 💬 or quick ❤️ to let me know your thoughts. If you want to start up a conversation send a little 🐦 to @kyecass ✌️
