Bringing Service Design to a Blockchain Team

Context: Part-time freelance project

Client: Unchain.io

Process overview

Key Terms:

Software-as-a-service | Enterprise Blockchain | Flow of empathy | Breaking down silos | Organizational Change | Crowdsourcing | Multi-stakeholder environment | Product vs Service Design | Share-Economy | Marketplace Value Propositions

Project summary

The client, Unchain.io is a validated and funded small enterprise bridging business applications with various types of blockchain networks.

The project’s goal was to upgrade the user experience for the users of the integration platform. It included taking a step back and seeing the industry trends and needs. Understanding the “as-is” situation from the perspective of the potential client organizations and the target users within those organizations.

By trying out a more iterative process – favoring multiple rapid prototypes, rather than getting it right the first time – we ensured that effort is spent in directions that matter (for the user, for the vision behind the service). These iterations would be used for validation and learning, not solely for providing solutions. Through creating moodboards with competitor workflows, borrowing from established design systems and good UI/UX Design – we worked toward less need for documentation, and made the initial steps on the platform smoother such that they inspire confidence.

The team had started using a different process and mindsetempathizing with the user, involving key stakeholders in well-scope sessions, and iterating quickly to manage uncertainty.

In order to ensure that the design effort is continued after the project concludes, the developer team was consciously involved in design activities and trained throughout the process in order to:

  • be more open to rapid iterations, the key question being:
    “what is sufficient to be shown to get a helpful reaction that teaches us”
    and not “what else should we improve before publishing”
  • would posses and sometimes use a different mindset: of a designer thinking in terms of a beginner’s (not that of an expert’s) mental model
  • be aware, humble and empathetic toward the jobs to be done and the user’s journey:
    learning at every step

Project outcome

Upon departure, the team was left with a better understanding of what Service Design can do, and whether it must be employed.

Together, we had gone through iterations composed of Prototyping, User Research, Framing, and other Design Activities – in order to create a more pleasurable, usable, and useful integration experience for the client organizations and the users within them.

In addition to the Deliverables on User Research and Experience Design, the team was left with:

  • A new holistic process partially implemented. Design tools were set up and filled in.
  • A planning roadmap was presented including activities and milestones on capability building / organization change.
  • The team was introduced to designers who help companies develop subscription business models and digital marketplaces.
  • Templates and preparations for future co-creation sessions in an attempt to lower the perceived risk or difficulty of user involvement.
  • I gifted a copy of the TISDD book, paired with method templates and guides – which made this project more enjoyable.

Case Study Contents:

The remaining of the case study is structured around the 3 characteristics of Service Design – characteristics that separate it from interaction design, as explained very well in this article by Fabrique.

(1) Research – that is wider and qualitative because empathizing with the user and understanding the context is not enough anymore; other affected stakeholders with an influence over the success of the service include: the internal employees in various departments within the company and other relevant external stakeholders (complementary products / service providers; regulators; client’s clients; etc)

(2) Orchestration – Putting together interactions into meaningful journeys. Orchestrating the touchpoints through channels, and connecting those to the back-end support activities – which are necessary for the experience to be consistent with the intentions.

(3) Organizational change – In order for concepts to go from the drawing board into the real world toward implementation, and to get commitment and effort from relevant stakeholders – the organization must act differently than before and make space for intentional design.


The client – Unchain.io

Unchain.io is a validated and funded small enterprise bridging business applications with various types of blockchain networks.

A strong and highly technical team with experience in blockchain integration projects

The team had been doing personalized consultancy and integration work in the blockchain sphere for years. By working across organizations and industries, they had identified some common challenges and a value proposition to support their partners by automating certain integration tasks.

While Unchain.io had strong technical skills in-house (trained through hard work on a project basis), the design expertise was not built within the team and was outsourced to freelancers.

The starting point for the freelance usability project was a high fidelity prototype built as a tech demo to show that it could be done. The prototype had not been sufficiently validated with relevant parties, and that is where the challenge started.

As in many innovative companies, the predominant attitude is to show the solution only “when it is ready for external feedback”, not a moment earlier. This could be due to hesitating to portray something “not good enough”; or wanting to protect reputation and defend one’s own work from criticism.

The Design Challenge

The freelance project had as a main objective to work on the usefulness and usability of the network integration platform. The team wanted the user to have a smoother experience.

A secondary goal had to do with putting together the foundation for a marketplace – the medium of exchange for the components.

The two objectives:

  • Improving the platform through good and intuitive design plus documentation to help the System Administrators and Integration Developers in their process regardless of their expertise of blockchain
  • Stimulating sharing of work done by partners and letting them re-sell partial solutions (components) or complete integrations (adapters) to other businesses through a Marketplace.

1. Research – wide and qualitative

Jump to the Table of Contents

When talking about service design, there are more unknowns and more stakeholders to take into account. Empathy and an in depth knowledge of the users is not enough. There is a need to have a good overview of all relevant stakeholders, in isolation, and also of how they interact between each other. So a good overview over: their context; motivations; how the value and money flows ; powers – both in the existing status quo (as-is) and how it could look like (to-be).

Visualizations done with Mural – a Collaborative Digital Workspace

The Ecosystem map and Jobs-to-be-Done tools are living documents, which should be made clearer and more accurate with time.

They can play 3 key roles: to describe the here and now, to make hypotheses or unknowns explicit – which can be further investigated if important, and to visualize a future situation.

An Integration Developer makes paths through which information can flow reliably across coding languages, frameworks and networks

Simplified Definition

Through creating the Jobs-to-be-done, some characteristics of Integration developers became clear:

  • Always on the lookout for efficiency improvements – like to learn
  • Natural born problem solvers: within moderately-to-well defined constraints
  • Like to stick to the tools they know well – unless peers or company processes lead them to rethink their methods
  • Tip: Stimulate their problem solving, and watch their path, then in a future design, build in and facilitate the unexpected approaches they took and scaffold them with signifiers and boundaries.

The enterprise blockchain context

The challenge that the industry is presented with is one of “education” – what does this mean, what can it do for us, how can we work with it; and one of “execution” – how do we find the expertise to do what we wish. As with any new technology, documentation is catching up slower than the advancements, and finding trained labour can be a challenge.

When companies move from experimental prototypes toward systems they wish to put in production – challenges can appear with regard to integration, reliability, security and inter-operability.

A consortia is a group of actors (government agencies, legal entities, companies, etc) that have a shared medium-term or long-term commitment. In this case toward information sharing and event automation.

Simplified Definition

The landscape is very competitive, and is defined by secrecy, but most important of all, consortia building. Because without consortia there is no collaboration or data sharing.

Source

The research was accomplished through:

  • Observing or leading informal discussions with the intended target audience
  • Second-hand knowledge and experience transferred from the Unchain team through interviews, presentations and filling in templates in a participatory way
  • 2 user tests covering two iterations with a total of 4 users
  • Acting out the interactions and steps using the first version which was present at the start of the project
  • Benchmarking analogical products from Amazon, Mulesoft, IBM, Google.

Dealing with second-hand information from colleagues is necessary in the real-world. If assumptions & perceptions are confused with facts & raw observations, it can become dangerous. Using that hidden knowledge that is already within the team can unlock important discussions and build trust between team members.

Key insight

2. Orchestration

Jump to the Table of Contents

Zooming in for the important details and zooming out to insure a meaningful experience

From individual interactions to a holistic service

Micro-moments are individual interactions. Put together they create a holistic experience, for instance from pre-purchase to post-purchase. The wider perspective is called a Journey map.

When bringing in more personas/characters for that particular actor, it becomes an experience map, which visualizes the commonalities or differences between the types stakeholder characters.

By zooming-in further inside the Journey Map, and asking through which channel the interactions take place, and what it is required in terms of support or back-end processes to deliver that experience, we create the Blueprint map.

A wider explanation and much more on the topic can be found here.

Blueprint Map To-be

The Blueprint therefore provided a holistic perspective over what must happen within the organization, and outside of it, for the service to be delivered, all while managing the emotional arc of the intended audience. It created understanding within the team on how various hidden details and internal process work to create a bigger picture. It also brought up a lot of aspects about the backend processes, automation and reliability.

Prototyping the MVP

The Value Proposition requires multiple journeys (sequences of actions) for it to make sense:

  • creating custom units
  • purchasing units in order to experiment or save costs
  • combining units into meaningful integrations

That being said, the MVP had to focus on the key to all of them: assuming the components (units) are available:

  • does the combining process flow smoothly?
  • does it deliver what it promises?

Therefore, the MVP assumes the platform has sufficient components, so they are not necessary to be built by the user or bought from other providers.

The sketching and wireframing focused on a few interactions only. The Blueprint Map had a wider scope and explored how the transitions at the front would be accompanied by supporting actions at the back.

Blueprint map: What the MVP excludes

It is desirable to have a common language for terms and concepts. This cannot be achieved simply through discussion or debate. Acting out and collaboratively filling in templates and designs can facilitate that.

Key Insight

Early in the prototyping iterations, a new design language was explored – heavily inspired by Carbon Design Kit from IBM, and although it was not fully implemented in the higher fidelity prototypes, it served as a good pointer on which principles to follow.

Moodboards (Amazon, Google, IBM) + Design principles

The moodboards above served as inspiration and learning from the big players in Gateways and integration: Google, Mulesoft, AWS, IBM.

Prototyping took place with paper mockups, whiteboard wireframes and click-through prototypes in Adobe XD. The Blueprint (only a journey map at the time) had a key role in the process as well.

Levels of prototyping fidelity – 3 types of Design – TISDD Ch. 7, p. 222

Exploring beyond the MVP: a Marketplace

While the Editor would create combinations of modules into meaningful integrations, the Marketplace would provide some of those reusable components.

The priority would be to validate whether the potential partners would step on board to upload and download these components, and under which circumstances.

What is a marketplace

Source: Everybody wants to be a marketplace – Frankly.studio

A marketplace plays a role in the exchange. Often there is a centralized payment system, fraud prevention, customer protection, customer support and arbitration of disputes. Also (and very importantly for one-way marketplaces such as Uber and Lyft), marketplaces verify customers and sellers, making sure that your next Uber trip will actually be a safe one! (at least, that’s what they aim for.)

To further define the Value Proposition, it helps answering these questions:

  1. What kind of marketplace do you want to start or be? (closed/open, centralized/decentralized, matchmaker/marketplace, one-way/two-way, etc.)
  2. What is your unfair advantage that you can take advantage of?
  3. What role will you play both as a facilitator and actor?
  4. Who is owning the technology, ‘rules of the game’, management and revenue streams of the marketplace?
  5. How to you enter the market and reach the ‘tipping point’ required (i.e. the minimum amount of actors needed to commercialize the platform)

Prototyping a marketplace

A quick and easy way to prototype beyond co-creation workshops or user tests with mockups, would be by using a framework that had figured out the various challenges of creating a marketplace:

  • interaction sequences designed to build trust and reliability;
  • the visual elements that are meant to inspire clarity and confidence;
  • the processes behind the surface (vetting, validation, payments) and the technical backbone to keep it working

Sharetribe allows companies to build a marketplace that is uniquely theirs. It can power the business at a fraction of the cost of a custom-build, on any scale.

In many ways Sharetribe is doing to the marketplace design landscape what Unchain is to the blockchain integration landscape. Their expertise and educational material in community building, human psychology, interface validation and building trust made it attractive to collaborate with.

Sharetribe – a framework for creating marketplaces

This collaboration would show what a human-driven mindset achieves. The Marketplace project would be accelerated, and the creation of it would not be a technical challenge but a community building and trust creation exercise. Another design sprint in which the developers would not be asked to code, but to fake/find shortcuts in order to do rapid prototypes and to put themselves in the shoes of the people who would go through the interactions.

Reframing

The importance of the Marketplace functionality had increased, while the path for implementing was simplified. The perspective had shifted to include the Marketplace toward future user test and co-creation sessions.

Such a big journey requires extra capability and departments, meaning that energy should be budgeted to build that capability sooner rather than later, and to collaborate by working using turn-key solutions on some interaction and technical elements, starting as soon as possible.

3. Organizational change

Jump to the Table of Contents

Transforming an organization (even a small one) such that it embodies Design Thinking or Service Design is a project in itself.

Some things that are part of this journey are: creating design ambassadors at key levels in the organization who speak up or decide at key moments and meetings; organizing design jams/ sprints/ sessions – not for their deliverables – but for the mindset they develop + preparation they require + agreement they stimulate.

It also involves setting up a process in which people at the back are encouraged to meet the users and see how their work impacts the bigger picture; a way to collect information from all members involved, and more than that – to problem solve collaboratively – not for the results, but for the discussions that start in people’s heads.

Create ambassadors for design who speak up at meetings and act within the organization early, when projects are defined and scoped

Key insight

Deliverables (Catching fish together)

The value of deliverables is in: the knowledge they collect; alignment they create; discussions and actions they stimulate; and process steps they make necessary.

It is important to do these work-products collaboratively with the team in planned sessions, to build shared understanding. Even if the findings themselves are not novel for the team as a whole; they to create a habit out of making space for human centered design.

Key insight

A difficult but important approach is to do these sessions together with outside stakeholders, which require intense preparation, care about confidential information, steering of process, and the ability to tell when an idea requires validation and contribution VS when it is too fresh to be understood or tangible.

Making space for Service Design (Learning to fish)

A new process

When attempting behavior change, a sure way to make it lasting is by “making it easy” – organizing the incentives and processes in such a way that the new way becomes the common sense thing to do. This is why a new process was needed.

The process described below is meant to be a guideline, and to be customized. The customization part is described later, and it is important to note that the team did borrow some key elements from the proposals made.

The process for implementation – TISDD Ch. 8.3

Please click through the following slideshow to see how the process was customized for this case:

Prioritizing design opportunities

The prioritization of findings into design opportunities takes place with the consideration of 4 main criteria:

Their overall impact on the entire journey

Their emotional effect on the user (anxiety, stress, confusion, etc.)

The ability to control and improve this part of the journey (who ‘owns’ this journey phase?)

The desire to innovate: “do we want to apply best practices or be an industry leader in a particular matter?”

Re-framing pain points into opportunities – frankly.studio

Customer support

A common frame of mind is “we will hire customer support when we need them, when we have sufficient customers” however this misses the point:

If offering customer service, support, guides and documentation is not a priority for the team, user frustration is not addressed at the right moment, and so those feedback points are not captured – that is the gold mining analogy for the research through design process.

Flow of empathy – TISDD Ch. 9.2.7

Building on top of the “transfer of empathy” concept – it is important that documentation and support sometimes be given by the same people who are developing, so which are normally not in customer facing roles.

Positive signs of change

Toward the end of the project, the signs for lasting change were:

  • Addition of 1 new designer role
  • The only designer in the team given more time for design rather than technical work
  • Changes to the creative process
  • Opening up the platform for public beta and experimentation
  • Inspiring questions and observations from the technical team throughout the duration of the project

Empathizing with your own team members is equally important. What is keeping them from changing their process or mindset?

Is it a habit, or are they trying to protect their work product from criticism or their process from too much interference?

Key insight

The End – Thanks for taking the time