Summary
We applied the design sprint format exploring a Hello World experience of an Integration developer using the Cloud Pak for Integration.
Preparation
Some great research was carried out between team members, that found a huge variety in the definition of both Hello World and other terms for new user experiences. Some terms were specific to the time in which the user’s experience was happening (onboarding, guided tour, getting started, first use) while others performed functions.
Hello World also had mixed definitions, but was less overused than many of the common UI-based terms.
The most likely historical explanation is simply that a short program like Hello World once allowed the programmer to make sure that a language’s compiler, development environment, and run-time environment were correctly installed.Because this involved a lot of work, a very simple program was used first to test things out.
We started preparing for the sprint the week before it was scheduled - perhaps a bit short on real user research - by assembling a team across the Integration design, product ownership, and development teams.
The most contentious decision was how far into the future the sprint output should be placed. We aimed for a couple of years in the future so that our designs weren’t constrained by the current state of the Cloud Pak UI.
I tried to provide insights from my sprint experience in Event Streams when recruiting team members. I advised on an Project management decider, but found that our real acting decider in the week would be a very technical Program Director because he really enjoyed working with design. For me, this reinforced the idea that sprints really must be team-directed for me.
The other influence I was glad I had, was to push for a dedicated facilitator. We learnt in our IBM Event Streams sprint, that self-facilitation was really challenging, and team members who supported with facilitation struggled to engage in either role as much as they wanted. As a result, we were really lucky to have a dedicated facilitator volunteer to run the Hello World week. This allowed all of us team members to focus on the sprint content. I envied the dedicated facilitator’s ability to put his foot down, time activities, and steer us out of black holes.
Expert interviews
One practice I really encouraged the group to follow from the Design Sprint format was the Expert Interviews on day 1.
This was for two reasons:
- We had a lot of strong personalities we needed to get bought into our sprint outcome. By inviting them to share their opinions we really started a positive dialogue and timeboxed their involvement.
- There is a tonne of domain knowledge in any project we do - so giving over a total of 3 hours to listening and absorbing 6 different takes on the problem space felt really good.
After the expert interviews, we had an updated and amended journey map for an integration developer looking to get their first piece of value in an integration environment. We worked really hard to avoid UI specific terms in the map - so that it wasn’t tied to current day UI.
In this sprint, I really learnt the value of “How Might We” notes as a note-taking method as well as launching us straight into ideation.
Lightning demos
We found Lightning demos really hard in the IBM Event Streams sprint, so I voiced concerns about them all the way from the planning stage of this sprint. We asked some of our experts for their favourite competitive ideas. We also started talking about, and noting ideas for, the Lightning demos from the very beginning of day 1. We looked at the IBM Event Streams starter application - and identified that it didn’t meet the Hello World definition because the code it was based on couldn’t be used as a starting point for development. We also looked at lots of smaller interactions we liked. My favourite of the Lightning demos was a really familiar interaction in video games - where the ‘learning’ parts of the game achieve the first few achievements or story points.
Google Ventures’ sketching method
The sprint methodology uses a really prescriptive sketching method, which is designed to get you diverging, converging, diverging and converging again within a 3-hour sketching period. I’m a big fan of it personally, but have found that IBMers are much happier using big ideas, storyboarding, and to-be scenario maps. That said, we ended up with a really strong “Art gallery” of ideas and enjoyed voting on them with our decider.
Sudo-user tests
After a gruelling day of prototyping, we got to our sudo-user testing. We operated this in a lab-style format where the test was broadcast to the sprint room by our researcher. We captured feedback on every screen from every test, using a post-it colour code:
- Green for positive,
- Yellow for neutral comment or general observation,
- and Red for a negative comment.
We would have loved to interview real users about our prototype, but it was sufficiently radical that we weren’t sure who they would be. Our prototype represented a lot more than just a Hello World experience - in making it work, we had designed a whole future for IBM integration. Our stakeholders formed most of our sudo-users, and had some great feedback, so whether or not our model for a Hello World comes to life, we drove alignment for the long-term vision of IBM Cloud Pak for Integration and our integration offerings.
You have created a ‘Hello, World!’ but also created a better experience.