Improved Coms Yield
Improved Workflow.

Visier: Design Sprint

visier.com

A 5-day Design Sprint in cooperation with Visier for educational purposes.
My sprint team consisted of 3 people:

Holly Gilbank - Ideator, UX Design, Content Curator
Eva Yue - Ideator, UX/UI Design, Prototypist
Myself - Ideator, UX/UI Design, Prototypist

Tools - Pen & Paper, Stickie Notes, Figma

Day 1
Brief. Research. Map.

Problem Space

We have received feedback from our Administrators for better ways to identify and communicate problems in the data visualization to Analysts.

How might we enhance the experience and communication between Administrator and Analyst to flag a problem, form a detailed report, and send it to specific Analysts all within the application?

Constraints

• Use of Clarity UI library (currently used by Visier) to ensure designs are consistent with the existing application.

• Use of supplied Key Screens so designs can integrate within the current application.

Assumptions

• Chat (ie. Slack) API within Visier application.

• Graph points contain more information in metadata.

• Ability to create an algorithm that consolidates tickets into groups based on related metadata.

• Sometimes the Analyst knows best and needs to override the algorithms.

Deliverables

• Prototype – showcasing the workflow of Administrator flagging an issue and Analyst receiving issued ticket.

• In-app feature – primarily designed within application supplied Key Screens

• Web application – 1920 x 1080px resolution

• Presentation – present case in five to eight minutes.

Goals

• Streamline communication between the Analysts and Administrators.

• Make a way for the analyst to send and flag a dynamic chart with all information to the admin.

• Make the workflow more efficient for admin by creating a more organized environment.

Understand the Task

From the project brief the task flow goes:
Administrator has to screenshot the found error and write a detailed email to the Analysts. The Analyst would then have to refer to the screenshot, try to understand the problem and fix it; plus additional correspondence if/when needed.

Quite a lot…

Mapping

As a team we mapped out the existing task flow starting with Administrator reviewing a chart as Task Begin, and Analyst informing when ticket is resolved as Task End. We then filled the steps in between. Being as thorough as possible allowed us to identify possible points of intervention. The vital step in the flow was Analyst receiving ticket. This point would determine how quickly a ticket would be resolved.

Interviews

For a basis of empathy, we conducted interviews (with people immediately available due to time constraints) to gather insight into communication:

What did communication mean to them?

What methods do they use, what do they like about them?

Which ones do they not like?

Why? Why? Why?

Findings

• Group chats were an important feature that is often used.

• Messaging was quicker than emailing because people felt emails had to be longer and written more professionally.

• Sending files (gifs, PDFs, etc.) with message apps was sometimes better than writing, plus a fun feature.

• Read message labels had mixed feelings, like and dislike; but good to know when messages are seen by recipient.

We consolidated and synthesized interview notes and recorded any statements that stood out to us (positive and negative). Next we categorized each key note into themes. With a few themes formed, We held a vote for the discovered themes and selected Alerts/Prioritizing & Organization and Information Overload to form our hypothesis.

Hypothesis

Assuming that workflow efficiency is dependent on effective communication, we had to keep in mind it is never single-sided and more than talking/messaging. In order to improve communication, all necessary information must be clear and concise, efficiently delivered from sender to receiver(s). Confirmed when the lifespan of issued tickets are reduced with minimal follow-ups.

Speed Ideation

Inspiration Board

To start the day, we used 30 minutes to search for design and functionality inspiration. Presented our findings and discussed about the features we liked. With a supplied UI library there was no need to change focus on new designs. We focused on the presentation and hierarchy of information.

To quickly get ideas flowing our sketches started with Crazy 8s (eight sketches, one minute each). After another quick group presentation and review, we allotted 40 minutes to focus on our own user flows and features.

Art Gallery + Heat Map

Time to share. This time more time and more thorough. We each voted on three ideas and/or features. After all votes (stickie dots) were cast, we received additional input and votes from members of the Visier UX/UI team.

The Decision

Original recommendations were to focus on the Administrator’s perspective; but it made more sense to us to focus on the Analyst. Administrators flag irregularities which is only the beginning of the process. What mattered to us was how the problems were solved.

Proto -Persona

To maintain our human-centred design thinking, we created a proto-persona. Our research was quite broad to develop a fully refined persona; but it was still essential to have someone to focus on for any firm design decisions.

Design

Having Visier’s Clarity UI library allowed us to move straight to high fidelity designs. This was essential to be prepared for usability tests the next day and to stay on schedule for Day 5 final delivery. Figma was the tool of choice because of its Multiplayer Editing feature (another example of good communication).

Administrator Flow

Start – Administrator finds an outlier in a graph. Then simply clicks the outlier to activate a Flag Ticket modal. The modal is auto-populated with metadata existing within the graph:

• Graph title and category

• Administrator (user) name

• Point details (value of outlier, month before, month after)

• Ticket issue time

• Text area for additional comments if required

By connecting and auto-populating the ticket with data from the graph, the task instantly becomes more accurate and efficient. No time spent creating screenshots and creating an email. Only review ticket contents and add a comment if needed. Send.

Analyst Flow

From (the Analyst) Kai’s dashboard, a toast alert would inform him of a new ticket. Each new ticket would be reviewed by the (assumed) algorithm and potentially grouped/stacked with any existing tickets of relating data. Stacks are more noticeable and appear more urgent.

When Kai clicks a stack, all unrelated tickets fade and hide. All tickets within selected stack spread out into a quick-view. Kai then selects a single ticket to resolve. Instead of deciphering a screenshot with hand-typed notes, Kai is now directly linked to the graph in question, outlier and its values already in focus.

A chat (Slack) API allows Kai to quickly communicate with Administrators associated with the ticket/stack, if need be. From here, the flow remained the same: fix outlier data, submit for review, receive feedback or confirmation of update. End.

We allotted four hours to conduct four tests, gather and assess our findings. The tasks of the test would run through the process from finding an outlier to its resolution:

• Manager task - identify outlier in graph, flag and report.

• Analyst task - determine priority of issued tickets.

• Analyst task - communicate with team to gather more insight on issues.

• Analyst task - repair outlier data.

• Analyst task - inform team to review and submit amended data

User Tests

Our testers were unfamiliar with the application. This would help us design an extremely user-friendly experience for someone familiar with the app. Our focus was usability and look and feel. Does the design fit the existing look? Was layout of elements and information easy to follow and understand?

Visier Test

Visier is familiar with the application. Rather than handing over control, we did a demonstration while describing our thoughts and reasonings at each step. This way we didn’t waste the limited time we had with the Visier team. Their familiarity with the application provided vital insight: what was working and not, what to consider. We asked specific questions to validate our design decisions.

Finally we decided on the lowest effort, most impactful iterations that we could very quickly apply. Most importantly, find the sweet-spot between sufficient information and information overload. Thankfully, changes would be mainly cosmetic, not structural.

Final presentations of solutions and one winning team. Winning was never our drive, but it is nice to be rewarded for hard work. Eight minutes to show our Sprint journey from research, ideation to creation, refine.

Turned out that our hard work paid off and we were chosen as the winning project. We stood out because we faced the problem from beginning to end, manager to analyst. The Visier team also felt our questions were strong and showed great ability to absorb and apply feedback.

Learnings

• Looking beyond the recommended task gave more understanding of the whole process and offered great ideas.

• Communication was more than just words, in this case data and visual hierarchy were most important.

• Simplifying the task at the beginning also simplified the process throughout.

Looking Ahead

Additional features giving analysts more power and control:

• Option to search tickets, including archived.

• Ability for analyst to reorganize tickets to make custom groupings.

• Flexibility with discussion board members.