THE WORK

Each iteration we begin with research. We would add user requirements based on the feedback we got from research or usability testing to those we received from product management for a story, feature, or enhancement. We begin ideating. We get informal internal feedback from the other stakeholders on the team, and we get feedback from our sponsor users. We iterate on that until we’ve designed to “80%”. We then share our wireframes and low-fidelity mock-ups with the greater team in a more formal playback. We make updates based on the feedback and we validate this with our sponsor users until we get it just right and then submit with specs to Development. You can learn more about our design process and how we developed it from the ground up here.

Research

At the outset, we realized our personas were outdated and our data was incomplete or incorrect. I realized I needed to once again validate our personas and determine whether they still adequately represented our sponsor users. As we didn’t have a user researcher, I assumed the role. Based on our personas I created a list of interview questions, and made arrangements with able sponsor users. I asked about their current scenario, pain points, and their hopes for a to-be solution.

I also set up and ran usability tests across the iterations to validate and collect feedback for stories already implemented, and for stories we were currently working on. For each, my co-designer and I put together prototypes using Sketch and Invision and presented them to our sponsor users. I would then watch and ask non-leading questions to determine what their expectations were for a particular interaction, and what confused them. We would use this information to inform our design for the next iteration. We would then submit specs with any necessary updates to the development team to implement on already deployed designs based on the feedback we received.

To give a better idea of our working process, the following are some of the features I worked on for this product:

VERSIONING

The problem was to solve how to adequately represent different versions of EDI documents so that a user could clearly track which documents were being updated with which.

When we first began running our feedback sessions, users told us they were confused by a design we inherited. At the time, what we called “related” documents were displayed in a drop-down menu. Separately, we displayed “versions” for each related document in a separate drop-down in the document details itself. However, under some conditions, related or versional documents could also be displayed in what we called the “milestone history” tab! It was no wonder our users were confused. In addition, to even determine what changes were made between versions, the user would have to switch between each and decipher the changes for themselves. It was cumbersome.

oRDER VS COMMIT

To even touch versioning, we had to figure out the relationship between order documents (850s), change orders (860s), and acknowledgements (856s).

The original design was separated into what we called milestones (the icon indicators at the top of the page), to represent each step in the supply chain: ORDER, ACKNOWLEDGE/COMMIT, SHIP, INVOICE, and PAY. The user can click on each milestone and see details on the documents related to that step in the supply chain. The difficulty was the distinction between ORDER and COMMIT since the two were so interconnected and would sometimes use the same kinds of documents. We also needed to allow for “change order” functioning as an “acknowledgement”, as some of our users operated this way.

VIEWING DOCUMENTS VS RAW EDI

Something else we discovered in the course of our research was that users were already attempting to click on the document name in the milestone history panel to view the details of that particular document on the page. Instead, they were directed to a view of the raw EDI document which frustrated them.

SOLUTION

We tested and iterated on each issue until we arrived at the solution below: it was easier for our users to decipher which documents were being replaced or changed with a tree structure, instead of viewing strictly in chronological order. We kept the “related” documents drop-down, removed the original “version” drop-down, and made the milestone history panel on the right the sub-navigation for the flow. From the history panel, users could navigate to and see the version history of that snapshot in the milestone. We also placed an icon next to the document name that would direct the user to a view of the raw EDI document.

We displayed changes visually, representing updates and changes with a blue dot, and removals with strike-throughs (with appropriate contrast to accommodate all sighted viewers). This way a user could tangibly see what changes the current document made on the original without needing to switch screens to compare.

result

It took many iterations of trial and error, but in the end, when we validated these designs with our sponsor users they felt it was a huge improvement upon the previous design.

Business Transaction Intelligence was also a common feature at our conferences, such as THINK or World of Watson. Product management always reported lots of excitement and enthusiasm from current and potential users alike.