Over 8 months I worked closely with a team of designers, engineers and project managers to redesign and revitalise IBM MQ for modern day cloud computing.
IBM MQ is a 25 year old messaging product that provides messaging capabilities to facilitate the flow of information between enterprise applications. Today many organisations are turning to cloud computing. Building infrastructures that can automatically scale up and down to deal with business needs. We were tasked with building a solution that met these modern demands
IBM MQ comes with a brand and a history of being one of IBM’s most dependable offerings. Over time it has become a trustworthy piece of software for many developers and administrators with 85% of Fortune 500 companies and 94% of the worlds top 100 banks trusting it to support their infrastructure.
We were tasked with adapting this product for the needs and behaviours of customers today, while balancing the expectations of our existing users. We wanted to create a user experience that would seamlessly fit into the work flow of our existing users. All while being able to quickly on-board our new users.
John, Design lead
Chatura, UX designer
Tobi, UX designer placement student
Ashley, Visual designer
Sasha, Design researcher
Own the user experience, supporting and leading research calls, defining the direction for our first and future releases.
We built our user story around a retail company looking to move 80% of their infrastructure to the cloud by 2022. We focused on their discovery, trial and purchase of IBM Cloud. Then how we would support their extended use. We created two guiding problem statements “hills” in each of these areas.
He ensures the technical progression of his company matches business goals. He enjoys bringing innovation into IT and evaluates new technology for his company to take on. He hasn’t worked hands on with MQ in a few years but he has a deep conceptual understanding of the product. He very rarely finds time these days to write code but is a part of his job he really misses.
James is responsible for the daily running of MQ. He has a deep understanding of MQ at both at a conceptual and implementation level. He’s had over 10 years of development experience with 7 working directly with MQ. While on-premise MQ is a large part of his work life but is extremely excited to see how the new challenges of cloud computing change his work.
We started by gathering our designers, engineers, project mangers and our stakeholders to run a workshop to determine the direction of the release. This was an opportunity to bring the team together and reflect on our diverse perspectives. During the workshop we identify areas of current user pain which we could resolve. These were prioritised and turned into two statements of user intent. These were used to align our teams to achieve a common set of goals.
The first was to make the maintenance of MQ on Cloud as easy as possible for administrators. The second was to ensure they could securely connect to any existing infrastructure.
Using this direction we ideated and prototyped the most hopeful abstract ideas. Initially these were quick hand drawn sketches, exploring every option. Each set of wireframes focused on the user journey of the administrator tackling one or more of the pain-points outlined in the workshop.
During the process ideas were continuously presented to our stakeholders and technical experts to be critiqued. Where possible we worked closely with selected users under NDA to receive feedback on our ideas. By focusing on a real world narrative I was able to tell a more compelling story, focusing feedback on the journey and solution as a whole, instead of the detail.
We visited four organisations and were fortunate enough to spend time understanding their daily routine. This resulted in extremely valuable insights.
Administrators are excited about how their jobs will evolve.
Ensuring the software is available, troubleshooting problems, preventing malicious attacks and provisioning infrastructure for MQ are examples of responsibilities being moved from the Administrator to IBM in MQ on Cloud. We initially expected this reduction in responsibility would be a issue for the administrators. We assumed we would have to do a great deal in aiding them through this transition. However by talking to administrators we quickly understood that they we’re excited by the advancement of MQ and how their roles would evolve to work with the new product.
“When can we get our hands on the cloud version”
“I’m excited to see how my daily routine changes with this”
Administrators have a deep understanding of the business impact of their actions.
Initially we suspected that due to the size of these organisations it would be unreasonable to expect an administrator to understand the impact of the messages being sent on his infrastructure. This was supported by queues of messages being highly secured with few people with access to read them. However, this theory was quickly thrown out. We learnt that administrators not only knew what their infrastructures were serving but the business impact of their actions.
“See this queue here I know if that fails, a delivery won’t be accepted at a store, meaning the food sits in the truck going off”
Through out the process we reflected on user feedback. Then use our insights to refine our ideas. Working our way from hand drawn sketches to mid-fidelity prototypes made using Sketch and Marvel. Our final outputs being Sketch hi-fidelity prototypes, Sketch Measure files and CSS and HTML prototypes. We moved on from each prototyping method when we felt a more powerful tool was required to convey our ideas. This enabled us to gather rich feedback from our users at every stage, drastically evolving our product.
Much like most projects, we had our fair share of struggles. One of the biggest struggles we faced as a design team was bridging the existing on-premise interaction patterns, content and thinking with the ones of a cloud world today. This involved building a deep understanding of current MQ users. We worked through this by iterating new ideas with our existing user base.
Through multiple iterations we ended on an seamless experience we felt enabled Edward and James get the most from MQ on Cloud. We focused on a discover, try and buy experience that enables Edward to get up and running in a matter of minutes instead of hours on-premise. We designed a guided tour that would explain even the most complex low level technical terms while giving Edward everything he requires to make an informed purchasing decision.
For James we focused on the extended use of IBM MQ on Cloud. We wanted to make the creation process as quick as possible, progressively giving him the correct information to build his infrastructure appropriately. The guided tour walks through the process of deploying a Queue Manager, a dedicated piece of infrastructure on which integrations can be built. Then guides our uses through the process of connecting a sample application. This walks the user through the complex task of connecting a application on their computer to the cloud. Throughout the process we focused on giving our users victories at every stage, encouraging them through the process to ensure they had a delightful experience.
This is only the beginning for MQ on Cloud. Very early on we pushed out many parts of our experience to decide on a minimum viable experience (MVE) for our first release. We have started prioritising this backlog to build a plan for our next release. We also aim to gain wider feedback from making the product generally available. While there will be more to improve, we feel we have built a solid foundation of bringing this complex product to the Cloud.
Our initial focus will be to focus on adding extra security. How can we enable our users to mange certificates and encryption to make sure the data they transfer is always secure? While a lot has been done to simplify the product and open it out to a large user base, I feel we can still do more to open messaging to the developer community.