What is IBM Event Streams?
IBM Event Streams is IBM’s Apache Kafka offering. Apache Kafka is an immensely popular messaging software which was released by the Apache foundation in 2011. The Event Streams team provide Kafka as software and as a service and add fully supported capabilities such as an award-winning UI, schema registry, REST API and connector library.
My role
User Experience Designer
Objectives
- Enable IT Administrators and Developers to connect their applications with Event Streams.
- Maintain a current User Experience within the IBM Design Language that is consistent with other IBM products.
- Plan the future of Event Streams and organise the Event Streams roadmap competitively.
Georeplication design sprint: my summary
Running a week-long design sprint using the Google Ventures format was really educational, and taught me a lot about facilitation. It also triggered a lot of questions about how we schedule our work items through the quarters and releases.
Why did we sprint?
A sprint is essentially a week-long workshop that is good for making a start on quite meaty problems. I think that they’re a good way to start work on an experience that is net new or lends itself to a one-week kickoff.
With MirrorMaker 2.0 available, development strategy pivoted to incorporate it. We needed to assess a significant feature of our UI - the part that allows people to replicate their Event Streams objects to other geographies or regions.
I had joined the team after the original Georeplication experience was designed, and wasn’t the only one that would have fair bit of learning to do. From what we’d seen, a design sprint was a good way to fit that learning curve into a short length of time. We also wanted to mark a relatively major change to the UI with a large kick-off effort that would give the changes momentum, while not taking too much time out of the rest of the tasks that the team was working on.
Preparation
Knowing that I’d be facilitating while trying to take part in the sprint, I did quite a lot of preparation - including creating a deck which summarised each stage of Google Ventures’ sprint.

Every slide in the deck included quotes from the Design Sprint book, images where necessary, and most importantly the position of the current activity on that days’ agenda.
I also created a sprint timetable, which allowed our Deciders, Experts, and other Stakeholders to know when their presence would be helpful, and when they should steer-clear.
Day 1
We started our day looking at our sprint goal, creating sprint questions, and mapping the scenario. We struggled with the goal because it was big - this georeplication feature had 3 distinct use-cases we had expected to cover. To try and cope with the doubts we had, we listed some sprint questions - things we were mindful had the potential to take us off-course or cause problems. These would become our metrics for success at the end of the sprint.
We got a lot out of ask the experts sessions, which we identified as a really good method for learning, if a little bit daunting. There was a lot of domain knowledge to be picked up, and we spread our net too wide by inviting experts from other products to share their understanding of Georeplication too. Our map of the scenario was challenging, in hindsight because we were too tied to the existing UI designs and therefore couldn’t express the users’ mental model. The biggest challenge we faced was when our deciders chose ‘the target’ in an experience we hadn’t mapped. In hindsight, identifying that the biggest challenge our users faced was deciding which georeplication use-case to use, should have hit pause on our sprint and sent us off to do user research. Instead, we ploughed on to design the experience anyway.
Day 2
Lightning demos on very technical projects are HARD! In fact, we thought they were so hard, that we skipped them. That would have been fine, except when we hadn’t got the hand of How Might We notes either - and that was a real problem. The design sprint format relies on How Might We notes both to get ideation started as well as identifying needs statements - all in one swoop.
So what did we do to sort that out? After voting on our How Might We themes, we started a bit of sketching. Then, we re-grouped with crazy-eights on a variety of voted themes, and voted on moving those forward.
Day 3, and 3.1, and 3.2… and 4
Cue a mega-storyboard. This storyboard literally took days, and wasn’t particularly creative. While we didn’t have the small amount of divergent time mandated by the sketching method, we couldn’t converge on the super complex technical parts. Eventually, we nailed down a story, and made a prototype. We never really finished this sprint, but it was a great experience.
What did we learn?
- We found that the structure of a sprint was really good for us
- Putting thought into our activities before doing them was good
- The several rounds of solo ideation in the Sketching method was refreshing for the whole team because we typically work really closely with our developers and design in parallel with code. This can mean that we don’t give enough time to ideation and coming up with a range of ideas. It was nice that Andy and Emma, our development sprinters really picked up on the range of convergent ideas too.
- It was really good to invest a significant amount of time learning in the Expert Interviews. It stopped us trying to design on assumptions and justify later. It also made us put more energy into due diligence outside of our product than usual.
- Having our development squad in the room the whole week, completely turned the sprint into a success. They had everything from placeholder text in the prototype to novel ways to explain geo replication in our education absolutely nailed down.
- The format of the sprint forced us to stay low fidelity, which was unusual for us, and really important. I don’t think our developers had ever seen us paper prototype before.
- We got buy-in from management and leadership early because they were all involved either as our deciders or they gave expert interviews. This meant that at the end, they were all invested in the output.
What would we change next time?
- Be looser with the 3 minute demos - they don’t have to be competitive products, and it helps to have plenty of time to come up with ideas beforehand
- Have stakeholders debate your goal for plenty of time and narrow it down before the team is exposed to it
- Doing some user testing, even with sudo-users, would provide much-needed closure after the sprint
if your mind starts with multiple ideas in parallel it is not prematurely committed to one path and stays more open and able to receive and conceive more novel innovations.