< Go Back

IBM MQ

IBM MQ (Message Queuing), is messaging middleware that ‘simplifies’ and ‘accelerates’ the integration of various applications and data across multiple platforms. Message queues provide a temporary form of storage when the destination application for the message is busy or not connected. The previous method of storing the data was using servers; however, in order to minimising the necessary hardware, software and provisioning requirements, cloud integration is being introduced by IBM.

Our brief was to imagine what a native third party experience of IBM MQ would be within the Azure Cloud Platform.

Company

IBM

Timescale

July 2017

Meet the Team

Dominic Baderin / Engineering
Carla Boré / Engineering
Alex Hopwood / Graphic Design
Anya Jessop / UX Design


User Research

To gain empathy for our user's, we needed to start our project with user research. Unfortunatly, due to joining the project after the MQ team had conducted user research, we were not able to interact with any Sponsor Users; however, the MQ team were able to pass on insights gathered from interviews and sponsor users. This allowed us to learn about our users' current process and pain points, which will be discussed later on (just keep scrolling!).

The team I had the pleasure of working with.


Personas

Once we had gain an understanding for our user's journey, we created our two personas: Andre, an app developer, and Edd, and MQ Admin. Below shows a small version of our personas; however, we also consdiered our user’s education, values, goals, needs, limitations and desires. Our personas were created based upon the MQ team's research in order to represent the different user types that might use solution. Now we had our users, we needed to understand their needs.

Meet Edd, an MQ Admin, and Andre, an App Developer (it's worth you getting to know them, they're rather important!)


The First Challenge

Aligning the team's understanding

The team I was working with was made up of four university students, including myself, and hence we were not familiar with each other. Each of us had different skills and backgrounds, which led to a misalignment in our understanding of what our challenge was. Before frustrations could flare we needed to find a strategy to help each of us understand the fundamentals of Message Queuing. This involved multiple visual aids on whiteboards and asking questions to ensure we were confident of everyone’s understanding. If we had not aligned our team early on, we could have risked the derailment of our project.

(A BBQ and waterfight with the Design Studio, also helped to bring some fun to our group, which is always needed!)

Brainstorming what we felt we didn't already know as a team.

Brainstorming what we felt we didn't already know as a team.

Alignning our understanding of the current situation of MQ using visuals.

Alignning our understanding of the current situation of MQ using visuals.


Empathy Mapping

With our new found understanding of Messaging Queuing, we were ready to dive into the challeng; however, due to the user's still being unfamiliar to our new team, we were advised by the MQ team to create empathy maps for our personas. By creating empathy maps with the MQ team, we were able to discover gaps in our knowledge, and further aligned our understanding of Edd and Andre.

So how did we do it? We drew a grid and the four quadrants of the map: Says, Does, Thinks, and Feels. We then recorded what we knew about the user using sticky notes and placing them in the appropriate quadrant of the map. Examples of observations the MQ shared with us were the MQ Admin originally used a command-line interface and that the App Developers only want to focus on developing their app, rather than dealing with documentation.

Within each quadrant, we looked for similar or related items. This helped us to pick out the pain points of our users and allowed us to understand who we are solving the problem for even better. We then had a Playback with the MQ team to discuss our insights.

Edd, an MQ Admin's, empathy map.

Edd, an MQ Admin's, empathy map.

Working with the current MQ team.

Working with the current MQ team.


As-Is Scenario Mapping

Like Empathy Mapping, As-is scenario maps allowed us to gain an understanding of existing user workflows. On a whiteboard we drew four rows and label each: Phases, Doing, Thinking, and Feeling.

We then went through the phases our users currently go through using one sticky note per phase while we added sticky notes to each phase with what the user is doing, thinking, and feeling. We iterated through the scenarios until we were comfortable with the level of detail we had reached.

Discussing the user workflows.

Discussing the user workflows.

Our as-is scenario map, ready to find the pain points.

Our as-is scenario map, ready to find the pain points.


Defining User's Needs

Once we had built up an understanding of our users and the challenge, we compiled our insights and scoped for a meaningful problem to be solved.

We pulled out the pain points from the Empathy Maps and As-Is Scenario Maps. We found these to be poor documentation, a long process and poor communication between Edd the MQ Admin and Andre the App Developer.

Plotting the different emotions of Andre during the current workflow.

Plotting the different emotions of Edd during the current workflow.

Pulling together the commonalities of the pain points from Edd and Andre.


Mission Statements

After finding the pain points as seen above, we decided what our mission statements would need to be. These mission statements would be our focuses for the project, to ensure we were always coming back to the users and their needs.

The mission statements were short statements of our solution's purpose, focusing on who the users are, what need is being met, and the wow that makes our solution different.

The who (white), the what (blue), and the wow (purple)!


Ideation

We've got our personas, we've got our pain points, and we've got our missions! Now to get the ideas flowing (que more sticky notes).

Big Idea Vignette

We initially started by creating a Big Ideas Vignette which allowed us to rapidly diverge on a breadth of possible solutions for our users’ needs. Using sticky notes we wrote down a ‘big idea’ which described the experience a user might have with the solution. We used small illustrations to convey our idea and shared them within our team. We then looked for similar ideas and moved them physically closer together and identified any ideas that we felt stood out. We then had another Playback with the MQ team to discuss our ideas and converge on a few ideas that we wanted to advance.

We went wild with our ideas. Some feasible, and some most definatly not; however, one idea helped to spark another.

We don't think shouting is the most feasible method of data transfer!

We don't think shouting is the most feasible method of data transfer!

Plotting the ideas based on the feasiblity and impact on the users.

Plotting the ideas based on the feasiblity and impact on the users.

To-Be Scenario Mapping

We then used a To-be Scenario Map to tell the story of a desired future solution. Using a whiteboard and sticky notes, we drew four rows and label each: Phases, Doing, Thinking, and Feeling. Like the As-Is Scenario Map we then went through the phases of users while adding sticky notes with what the user is doing, thinking, and feeling; however, this time we were looking at what we what the ideal solution to be instead.

Using images and stories to illustrate our ideas.

Using images and stories to illustrate our ideas.

Iterating until we had a good level of detail.

Iterating until we had a good level of detail.


Wireframing

Finally we were ready to create our wireframes, which allowed us to prototype user interfaces before creating high-fidelity designs. We explored different variations of our designs and share our sketches to get feedback from the MQ team and the rest of the design studio at Hursley. Our low-fidelity sketches allowed us to iterate quickly and find the best solution.

Initial Wireframes

We initially started by creating a Big Ideas Vignette which allowed us to rapidly diverge on a breadth of possible solutions for our users’ needs. Using sticky notes we wrote down a ‘big idea’ which described the experience a user might have with the solution. We used small illustrations to convey our idea and shared them within our team. We then looked for similar ideas and moved them physically closer together and identified any ideas that we felt stood out. We then had another Playback with the MQ team to discuss our ideas and converge on a few ideas that we wanted to advance.

Illustrating my ideas for the process of logining into the system.

Illustrating my ideas for the process of logining into the system.

Illustrating my ideas for the dashboard.

Illustrating my ideas for the dashboard.

Developed Wireframes

We then used a To-be Scenario Map to tell the story of a desired future solution. Using a whiteboard and sticky notes, we draw four rows and label each: Phases, Doing, Thinking, and Feeling. Like the As-Is Scenario Map we then went through the phases of users while adding sticky notes with what the user is doing, thinking, and feeling; however, this time we were looking at what we what the ideal solution to be instead.

Wireframe for the process Andre takes to setup a new message queue.

Wireframe for the process Andre takes to setup a new message queue.

Wireframe for the process Edd takes to setup a new message queue.

Wireframe for the process Edd takes to setup a new message queue.


Prototyping

Once we had created our low-fidelity sketches and gained feedback from the MQ team we moved on to creating a high-fidelity prototype from our final designs, which was presented at our final Playback. The prototype gave an idea of the interface and navigation that we had designed.

Unfortunately our final Playback marked our last day at IBM which meant we were not able to see the project through further; however we gained positive feedback for the work we had completed.


Final Notes

The experience taught me a great deal about User Experience design, especially the techniques that I can use to understand my users better. Since the placement I have taken on other projects as a user experience designer and I wish to pursue more UX design in the future.

The main challenge was this was the first time in two years I was working with a team I was unfamiliar with. Initially it took time for us to feel comfortable enough to discuss our opinions and ideas freely because we were cautious of our ideas being judged by others; however, by the end of the two weeks, we felt comfortable discussing ideas and questioning our designs in order to find the best solution to the problem.

Working with new people with different working styles and on a project I was not familiar with, challenged me as a designer; however I loved testing my ability and it was a pleasure working with passionate creatives.

A very happy team after final playback!

A very happy team after final playback!

A final farewell to a great few weeks.

A final farewell to a great few weeks.