Much of my work on blockchain-as-a-service at IBM was focused on developer personas and adoption of the open source Hyperledger Project. After my first year, I developed Blockchain Design Principles, where you can read more about specific design challenges.
My role: Design Lead, IBM Blockchain
Dates: August 2016 to July 2017
The design team was focused on designing the workflow for launching a private node and network on IBM Cloud (at the time, “Bluemix”). The UX flows needed to fit with the established patterns of the Bluemix design system (now called Carbon Design System), but take into account the entirely new activities need for blockchain-as-a-service.
Blockchain technology in the enterprise environment was still very new, and the engineers at IBM were actively building and contributing the the Hyperledger Project. This meant that we were essentially building the car as we were driving it, and changes to the mechanics happened rapidly. Often the design team did not learn of fundamental changes to the base layer (affecting the entire design) until a week or more after they occurred, making our wireframes obsolete. It took time for the designers to understand the technical implications and we trailed behind—often only brought in to make things “prettier”.
An added problem was that designers in the RTP location had just moved into a brand new IBM design studio, a highly coveted space with workshop/lab/maker areas. If your seat as a designer was not being utilized, you were asked to give it up—so my initial solution of physically moving closer to the engineers to improve communication brought a great deal of tension.
Lastly, the biggest challenges when designing for blockchain centered around building accurate personas and access to real users—there was a push to develop experiences for future jobs, not where actual users were in reality. Users were a moving target, changing monthly in the jobs they were trying to do, much of it sheer experimentation with an emerging technology.
A major problem to solve was communication between the engineering team and design—we needed to get in front of decisions being made that affected user experience. First, the engineering team needed to know who the designers even were, and what we were bringing to the table. I got some budget to throw a pizza party for the blockchain team, and made a large format poster with pictures of all the designers and their work (which remained up so that people could stroll by and see the design team).
Next, I facilitated design thinking workshops to bring engineers, offering managers (product managers), and designers together to align on and understand our users, and then ideate solutions. This was critical because each group had different information about the users, business objectives, and feasibility constraints that needed to be understood by everyone.
These workshops spurred questions and highlighted gaps in our understanding of potential users. Because the engineers had participated, they were more willing to sit with me during user interviews, filling in the technical expertise and allowing us to get better information.
User interviews gave us enough information to build as-is scenarios, start to make personas of real people, and understand pain points together. I used Mural, which allowed real time collaboration and a digital record of our work to refer back to later.
Later, I built our sponsor user program to give us official, and faster, access to customers and users invested in the outcomes of our work. It allowed us to have one agreement in place and not have to worry about constant NDA signing when inviting customers to co-create in workshops or when getting feedback on prototypes.
Developers knew our names! We developed a good relationship with the engineering team through inclusion, but also because we adopted an “all hands on deck” attitude. For example, the Hyperledger documentation needed a lot of work—our developer personas were struggling with understanding a lot of new concepts. We jumped in to help structure content, test content with card sorting, and illustrate the more complicated processes. The engineering team saw we were willing to do what it took to help our users, and our users were thrilled with the improved documentation.
Consequently, our team started bringing designers into the process earlier, alerted us to changes sooner, and unprompted: began routing user feedback they gained externally (like at conferences) towards us. Combined with the sponsor user program, we had an exponentially better understanding of our users—more insights driving better solutions.
We were able to ideate the experience together with the rest of the blockchain team, developing “To-be Scenarios” that informed the prototypes.