Solution Builder - Learn&Discover 

How can we help our customers find the product they need?

Role: team lead of 4 designers
What: from incubation to product design
When: Jan '17 - May '17

The product

Solution Builder is a tool for data practitioners to learn about IBM Analytics products and to design unique solutions for their business needs.

Solution-first approach

Our clients come to us with business goals, not product names.  We realized that what they need are answers to their business problems, so we built a new marketing tool starting with a 'solution-first' approach.

Design Journey

IBM has a very extensive portfolio of products. As designers we attempted to understand the offerings in our business unit, and that turned out being an extremely time consuming task. We thought that if we were having this hard-time, then our clients or potential new customers were maybe experiencing a similar problem.

In the attempt of understand it better, we started with a massive research that covered different sources (such as: IBM Marketplace, Wikipedia, internal interviews with architects and technical sales). We soon realized that all these products were related to each other by data and by the way they were allowing data to flow from one stage to the other. That was a pivot point: there was still a ton of technical information and product details that we didn't know, but we had a draft of what we called 'Data Journey'. Our products had to be grouped in the data journey, to help users understand their core capabilities, independently from their marketing names. 

From that point forward, we started with the design of the 'Solution Builder', a tool that offers a progressive disclosure of information, available at the user's will. The user can go deep and read more, or can simply browse through the different stages until she finds what she is looking for.

Design-Development workshop

We could not do this alone, we needed support from Subject Matter Experts. We interviewed solution architects and technical sales in IBM, so we were finally able to draft an end to end data journey, based on which we organized the products we were familiar with. Then we had a workshop with development to verify our information and to understand relationships between the listed products. In one day we had design thinking activities such as empathy maps to define personas, affinity maps to cluster our users needs and relationships between the offerings.

Design decisions

• Modular architecture: we are open sourcing the tool to other teams, therefore every component is fully customizable. Starting by the initial wireframes, each asset has been created in a way that could support a variety of content and could be moved across the page to make the information flow differently.

• Multiple users: we included information with different technical level of details, therefore our discovery tool speaks to multiple audiences. From the data scientist who is looking for the latest innovation in ML, to the CDO who has the final say on which product to provision, everybody can learn something from the Solution Builder.

• Solutions, not products: users go through a progressive information disclosure and a series of 'focus states'. They are encouraged to start their discovery journey by looking at pre-packaged solutions based on real business needs (like how a bank predicted customers churn using Machine Learning). We want to help users to think that if 'this' solution worked for 'this' company with similar business goals as their, then it might be worth it to try the products they use and to mirror their architecture.

• Technical information, not marketing messages: our users want to do their job, and they are always on the hunt for new products that could help them being faster and more accurate. They build proof of concepts to evaluate new products and they research on the internet for reviews and technical forum to help them make a choice. We wanted to make all of this tasks easier for them.

• Products relationships: in order to focus on their job, our users want to find products that well related to each other, to avoid incompatibility or process' slow down. We created a tool that highlights products integrations and provides packages of products ready to be used (we call them 'solutions'). 

• Build your own solution: the selection of a new tool follows several steps and it is supported by experimentation and research. For this reason we designed the 'My Solution' section, where the user can review her bookmarked products for later. In the future we want to introduce a 'share' capability and the ability of writing comments and annotations.

Next steps

Due to the impressive amount of available offerings, this tool could result in a never ending effort, but we think we got to a point where we can release the tool to the public and see how users react. We are open sourcing it for other teams in the company who experience same pain-points as ours. We have a working HTML and CSS prototype on the internal GitHub that anybody can use, and we put together design style-guide to explain the architecture, user flows, interactions and visual components. 

What I learned

This was a design-driven project, no one really asked for it. Our team felt that all the previous attempts to help our customers in the product discovery were unsuccessful and we decided to give it try.  We knew that if we started with the user experience in mind we could bring something more effective to the table. Therefore I learned a lot on handle incubation projects and how to bring them to the shipment phase.

• How to work blue-sky: the hardest part was not to lose focus of the scope of the product. As designers we see all the users painpoints and we tend to diverge often in the attempt of finding answers for all (or as many as possible) of those. As design lead was my responsibility to pull the reins when creativity and ideation went too far.
• How to prioritise features: with little pressure from development or offering management on which features to include and when, we let the ideation phase open for a while. We came up with tons of ideas and features, that we had to prioritise in order to reach a minimum viable product in a reasonable amount of time. Ultimately, our main criteria for prioritization was 'Solution first'.
• How to manage requests: development saw this tool as answer to its need for an internal catalog of products. For a split moment we also thought this could be the answer, but we soon realised our starting point was different and we were solving a different user need, so it would have not be beneficial for our customers to pivot the project half way through. We are now working on the development of the internal catalog.
• How to pitch an incubation project: I learned immensely from my manager regarding this point. I understood how to progressive share your work to people in the organization that can support your work and pitch it to their higher level. It was not an easy task, not everybody saw the scope of what we were doing. But at the end of the day we managed to be successful and to find more proponents than opponents.
• How to ship an incubation project: we reached a phase where everybody we showed the product to was excited, but no one committed on a real ship date. So we spotted the next release of another product our studio was also working on, and we made a case on how 'Solution Builder' would have being a perfect addition to it. We proposed a user entry point to our experience, we figure the technical details with development, and we succeeded: Solution Builder will be live for internal customers at the end of May.

Interactions details: