TransPort – Revisons

Overview

TransPort is an advanced translation project management tool that facilitates communication, secure document transfer and translation as a Business – to – Business(B2B) product. It enables organizations to request, store and manage translation documents.

Introduction

TransPort currently allows its clients users to upload documents of varying sizes and types to the system that they need to be translated. While requesting a translation the client selects the original language that their document is in and as many languages that they desire to have it translated into.

Below only shows the research and screens on the Client side UI. This project also has a Sales and Admin facing UI as well.

Tools

Omnigraffle, Sketch, Axure RP

Timeline

Team Size: 3
Timeline: 3 months
Constraint: Work within the current UI

Skills

Contextual Inquiry, Information Architecture, Wireframing, User Testing, Visual Design

Problem Area

Clients are unable to request changes to translated documents on TransPort after receiving the final deliverable. The system does facilitate these type of requests which impacts our on time delivery stats.

Sometimes emails are missed with clients requesting changes on a document. If this problem is ignored we may miss crucial client deadlines which could result in losing the client, and revenue but more so causing damage to our quality reputation.

solution

The best way to address this problem is to create a way for clients to request changes from within the interface of TransPort. We created a corrections option. This would facilitate making requests, tracking, and storing all versions of the delivered file.

Images are laid out in the order of functional task

Deliverables Screen with Revisions Feature

Deliverables – The client user is given the option to request a correction on a per file level.

Request a correction dialog modal

When the corrections feature is initiated, the client is presented with a dialog to specify the issue with the file along with any other details they might need to add. They are also giving the opportunity to attach a reference file.

File history view

Once a revision has been requested it creates a file history on the system which is accessed through this dialog.

Projects List – indicating if a revision has been returned to the client.

Feedback modal on deliverable screen

After a revision has been returned, we capture feedback from the client by adding a dialog for them to rate the work while having the opportunity to leave a detailed comment.

Digging Deep

We held contextual inquiries and user interviews with our production staff to get an inside view of the problem. We asked questions regarding:

  • workflows
  • the frequency of change requests
  • common departments
  • cost implications and more

We later interviewed stakeholder and client users to learn more.

Learnings

We found out that if the client had an internal reviewer they were more likely to request a change, also that certain types of documents were more prone to revisions than others.

We also learned that clients often requested changes based on different criteria such as grammatical errors, expiration of certificates, and cultural references. There is no timeline for the client to request a change, and this sometimes posed a problem in tracking revisions made or the last delivered version of the document.

Mapping the Flow of data communication from client users to sales and production
Identifying various causes for revisions, timelines or frequency patterns.

user testing

After going through rounds of wire-framing and user testing it provided more insights into how users typically request changes. Based on this input we added the categories for revision request rather than leaving it as an open text area. Since changes are made on a file level and are based on different factors such as change of instructions, work quality, certification or any other non-specific reasons it was added to the corrections dialog.

We were also able to test the terminology we used and listen to the terms our participants used when discussing making changes to a file.

Remote usability testing session
In-Person Usability Test

closing

This feature is being developed, so we are looking forward to testing it further post launch to observe user behavior on the platform. We began with an idea of the problem but learned much more that we expected. My biggest learning from this project is to take time to prepare a well craft discussion guide.