Confidential project, names changed
Design & research lead
Andrea, BJ, Colson, Jason
How can we bundle two siloed pieces of hardware into a cohesive user experience?
Quick project stats
Hours spent working with users & business partners
Quick project stats
Companies participated in research (including business partners)
Quick project stats
Customers & business partners interviewed
Joining the project
Because of the confidential nature of the project, I’ll need a be a little vague on the technical specifics. I’ll change some product names, too. But that’s fine, we’re focusing on research process here anyway!
A technical concept
I joined the team pretty early on in the ideation phase. The engineers had a pretty solid early concept, my PMs were forming thoughts on revenue potential and business plans, but there were still huge gaps around user experience.
The concept was to combine the F7230 into the same piece of hardware as a J100 machine. Basically, we’d be pulling two pieces of hardware into one.The challenge here was that the F team and the J team didn’t have a history of working together super closely in the past. Sure, they talked, but they rarely ever joined forces to create cohesive experiences.
From a user experience perspective, the J and the F management consoles were completely different and didn’t really talk to each other. That was the first big UX challenge I initially saw. Thankfully for us, there was an existing offering (the 13W Dedicated) that was similar to what we wanted to do. We could use that as a jumping off point for research, engineering, and PM.
How might we create a cohesive user experience for a bundled F7230/J100 hardware offering?
The technical space
Low 13W Dedicated sales
The 13W (the product offering we were using as our jumping off point) was sold exclusively through business partners, and it wasn’t doing too hot. We needed to identify pain points and blockers to both the BPs selling and the customers who were and weren’t purchasing this.
Combining disparate management processes
Like I said before, the J and the F management consoles were extremely different. But if we were going to combine the two into the same hardware, how would users manage their experience? What were the implications for the users? Would a new user persona be born? There were a lot of questions and a lot of different people who would have to work together to make this a cohesive experience.
But let’s table that second problem
I didn’t even know if we should be building this thing! If sales of the baseline offering were so low, why would expanding it be a viable move for the business and a valuable experience for users? Strategically, it made sense to table the management question for this first research sprit.
My initial goals & gut reactions
Evaluate the 13W Dedicated with business partners
First step was to work with the business partners to understand their blockers to selling the 13W. I also wanted to do some secondary with them about their customers. What were motivators and blockers their customers were experiencing?
Evaluate the 13W Dedicated with users
Next, I needed to figure out what was going on from a user perspective.
For the users who had purchased the 13W: Why? What was the value? What were the downfalls?
For the users who were qualified, but didn’t buy: Why? Are the pain points we assume you have even valid?
My big question:
Should we even build this thing?
Align with this new (HUGE) team and start to figure out what we need to figure out
Questions & assumptions exercise
Business partner surveys
Business partner interviews
Evaluate the 13W Dedicated from a BP sales perspective. Why wasn’t it selling?
Get the user perspective to see if there was even a problem that needed to be solved.
Before I started building out a research plan and roadmap, I needed to reflect internally with this huge new team full of IBM F and IBM J people.
I like starting new projects by interviewing some key stakeholders. It helps me build a rapport with my new teammates, but also helps get a sense for how aligned everyone is. From there, I can start to identify big gaps we’ll have to cover in research.
Questions & assumptions with the team
I said this in the last case study, but I’ll say it again: I love a good questions & assumptions exercise with the whole team. It’s a great way to get buy in and support from the team and it helps diversify the questions we’re asking in our studies. I’m ultimately gathering information so we as a team can make informed decisions, so it’s important to know what everyone needs in order to make those decisions as confidently as possible.
Building the research plan
This was such a complicated space and there were so many variables and uncertainties up in the air. From a research perspective, I love when a team has lots of questions. But from a leadership perspective, I didn’t have the resources to answer all the questions in a single study. So diversifying methodologies to allow for parallelization where possible became key.
My design team and I sorted all the questions and assumptions we had solicited from the team. Then we re-framed the themes into research objectives. We then brainstormed potential methodologies we could leverage to answer the questions our team had.
The initial research plan
We were on a time crunch, we needed to deliver research and develop hill statements as quickly as possible. I worked with our PMs and stakeholders to negotiate the timeline and set reasonable expectations for the studies my team could deliver within that period.
I tried to drive parallelization wherever it made sense to run two parallel studies.
Team best practices & prep work
Tracking work in Trello
The design team tracked out work in Trello. I pre-populated each sprint with a time box, goals, and anticipated activities. During stand ups, we went through the cards and updated our status
Building our research protocols & surveys
Our core team was, no joke, 17 people. We needed a lot of communication and patience to get the interview protocols and surveys to a place where the team was comfortable. We build the artifacts in Box notes so the team could build off of our drafts.
Recruiting research participants
Since we were looking at a very specific user base (specific J model size and cooling, less than 2000 capacity), sponsor user recruitment was slower than usual. I talked to a lot of sellers and business partners to get ahold of the right research participants.
Evaluative research with business partners & users
Business partner survey
We started by surveying the North American J100 business partners about their experience selling with 13W Dedicated. Out of the 10 North American BPs, we got 9 responses back!
Follow on interviews with the BPs
Following the surveys, we had in-depth interviews with the business partners. To dive deeper into blockers they’d experienced and areas of opportunity.
Interviews with actual users
Once we had the context from the business partners, we interviewed real users. We set out to confirm the pain points we had gathered from the BPs and uncover additional information on their behavioral patterns. We wanted to know about the unique needs and restraints of this super niche group of F/J users.
The big question we had was: should we even build this thing???
J100 and F7230 sales cycles and warranties don’t align
Customers buy J100s on a 2-3 year cycle, F7230s on a 4-5 year cycle
Customers pre-purchase their warranties
Customers don’t want to introduce double the change at once
Fear and uncertainty around forced upgrades
Desire for broader use beyond F7233H
We’d have to completely change how J100 and F7230 are sold… AND we’d have to transform how customers make purchase decisions
Customers are nervous about being forced to upgrade their J100 and F7230 at the same time if they buy the 13W Dedicated
If they want to upgrade their J100, will the F7230 have to be upgraded too?
We can’t force customers to upgrade their J100 and F7230 at the same time
Migration plan needs to be a forethought for IBM
User can only put a F7233H into the 13W Dedicated space
A laundry list of things customers want to put in the 13W Dedicated
In client shops where space savings are the highest priority, limiting the 13W to F7233H is actually a huge pain point
Re-evaluate our lives
Woah there, wait a second
The pain points we identified with the 13W Dedicated were not something our team could (or should) address given compliance and sales restrictions. BUT an existing project that was already underway COULD help our users in the exact way they needed!!
The J100 and F7230 teams pivoted and re-allocated resources to the team that was developing the right solution for users. They’re now developing a solution that addresses all the pain points of customers AND business partners AND IBM!
This is a happy ending!!
We should only build things that will help users and serve a business purpose. I’m stoked that we’re not forcing a solution that wouldn’t address the pain points we had identified.