This article adds more detail to the points which I touched on in the Visual and Short version 🔗.
This is an Appendix, for reference only and linked from there.
Table of contents:
The Client
A strong and highly technical team with experience in blockchain integration projects
Unchain.io is a validated and funded small company, at the time of writing consisting of 10 people. The goal of the company is to bridge business applications with various types of enterprise blockchain networks.
The starting point for this freelance project was a high fidelity prototype built as a technical demo. The prototype had not been sufficiently validated with relevant parties, even though there were plans to build even more functionality.
The Design Challenge
The freelance project was scoped around the usefulness and usability of the digital platform. It must serve the users (beginners as well as experts) in achieving objectives set forward by their organizations.
Secondary goal: investigating the creation of a marketplace for modular software integrations. This would involve encouraging the re-use of software created by other organizations.
Appendix 1. Research – wide and qualitative
This is an Appendix, I recommend seeing the Visual and Short version 🔗.
In Service Design, there are more unknowns and more stakeholders to take into account compared to UI/UX Design, where the problem space is more defined. Empathy and an in depth knowledge of the personas is not enough. It is important to have the same in-depth understanding of all relevant stakeholders, both in isolation, as well as how they interact between each other.
The Ecosystem map and Jobs-to-be-Done tools are living documents, which should be made clearer and more accurate with time.
These deliverables can play 3 important roles: describe the here and now, surface unconscious assumptions and unknowns and they can visualize a future situation.
Visualizations done with Mural, a Collaborative Visual Workspace
Defining the Persona: the user is different than the customer
An Integration Developer makes paths through which information can flow reliably – across coding languages, frameworks and networks
Simplified Definition
- Integration Developers are great problem solvers, but only within well defined problem constraints
- In the very dynamic and competitive software industry, they value improvements which make them more efficient.
- Like to stick to the tools that are proven to work well for them- unless peers or company processes lead them to rethink their methods
- Pro-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 constraints.
Altough an integration developer (User) has to work with the constraints set by management, he has a say over the tools and work processes that are to be used. Fundamentally, the decision maker over how work takes place is the CTO/Architect (roles vary depending on the way an organization is structured).
These two participants are the main stakeholders: the Integration Developer (creates), and the System Administrator (adjusts and manages).
The enterprise blockchain landscape
At the time of the project (early 2019), the industry was presented with a challenge of “education” – what does this mean, what can it do for us, how can we work with it, how do we experiment… As well as the challenge of “implementation” – how do we integrate it and how do we find the expertise.
When companies move from experimental prototypes toward systems they wish to put into production – challenges can appear with regard to time-to-market, reliability, security and inter-operability.
Consortia in Blockchain
A consortia is a group of organizations* that have a shared medium or long-term commitment toward each other.
* organizations: private companies, auditors, government agencies (e.g. customs), local government, etc.
The blockchain landscape can be seen as a competition between groups of (not just individual) organizations.
The field is very competitive where secrecy is important.
Another defining characteristic is consortia building. This is where technology integrators/providers play a role of orchestrator, as well as facilitator.
Without consortia (a commitment to share and coordinate) there is no interoperability, data sharing or collaboration, there is limited added value.
Update (2021) – At the time of the project, MS Azure (now Quorum) and Amazon AWS Blockchain did not have their integration offerings as developed as they are nowadays. Understanding how it would have impacted our Value Proposition shows the importance of Trendspotting, Forecasting and Design Strategy.
Appendix 2. Orchestration
This is an Appendix, I recommend seeing the Visual and Short version 🔗.
Zooming in for the important details and zooming out to ensure a meaningful experience
From individual interactions to a holistic service
The Blueprint 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.
The map is further explored the following chapters.
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
The sketching and wireframing focused on the most crucial 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.
Moodboards and moving toward a Design System
To achieve a user friendly and compelling experience, a design system was studied (Carbon Design Kit – the Design Language of IBM). Although we customized it heavily, it served as a very useful pointer on which principles to follow.
The moodboards above served as inspiration and learning from the big players in Gateways and integration: Google, Mulesoft, AWS, IBM.
It is desirable to have a common language for terms and concepts. This cannot be achieved simply through discussion or debate. Acting out, collaboratively filling in templates and completing designs together can facilitate that.
Getting on the same page
Rapid click-through Prototypes
Prototyping took place with paper mockups, whiteboard wireframes and click-through prototypes in Adobe XD (pictured below). The Blueprint (pictured earlier) had a key role in the process as well.
Please note: these prototypes are quick and dirty. They are intended to test layouts, and not provide input for developers. I had limited time and this was not an Interaction Design project.
How these prototypes were combined with User Research and Validation is explained in a following chapter, titled “A new process”.
Exploring beyond the MVP: a Marketplace
While the Editor would combine components (modules) into meaningful integrations (pipeline), the Marketplace would provide some of those re-usable components without the need to create everything from scratch. This is an advantage due to the promise of simplicity, reliability and time to market.
The priority during this Design would be to validate whether the potential partners would step on board to upload and download these components, and under which circumstances. Another goal was to investigate what elements of a marketplace we missed (unknown unknowns).
A rapid and simple way to prototype beyond “acting out interactions during co-creation workshops”, would be by using a framework that had solved 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
A prototype was built (WooCommerce – WP), demonstrated and discussed, but this article will not describe it in any more detail.
The case for a flexible Marketplace
Sharetribe allows companies to build a marketplace that is uniquely theirs, at a fraction of the cost of a custom-build.
In many ways Sharetribe is doing to the marketplace landscape what Unchain is to the blockchain landscape. Their expertise and educational material in community building, human psychology, interface validation and building trust made the team consider a partnership.
A new perspective on building it
The collaboration with Sharetribe would show what a human-driven mindset achieves. The Marketplace functionality would be accelerated, and the creation of it would not be a technical challenge but a community building and trust creation exercise.
It would allow for design sprints in which the developers would not be asked to code, but to fake it and find shortcuts. To be required to place themselves in the shoes of the users – instead of asking technical questions regarding feasibility.
Appendix 3. Organizational change
This is an Appendix, I recommend seeing the Visual and Short version 🔗.
Transforming an organization (even a small one) such that it embodies Design Thinking or Service Design is a project in itself, and it was not the explicit goal stated in the initial Design Brief. However, changes in operations were required to make space for Design…
Some things that are part of this effort were: 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.
Create design ambassadors who speak up at meetings and act within the organization often and early, when projects are still defined and scoped
Key insight
Making space for Service Design
A new process
When attempting behavior change, a good way make it lasting is by “making it easier” – organizing the incentives and processes in such a way that the new way becomes the common sense thing to do.
The process described below is meant to be a guideline and to be customized. The way we borrowed it for the developer team is described in the slideshow following the overview.
Please feel free to pause and click through the slideshow to see how the process was applied:
Customer support is important for building the right thing
A common frame of mind is “we will hire customer support when we need them, when we have sufficient customers”. However, this misses an important 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 (gold for the design process).
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, people which are normally not in customer facing roles.
I am grateful to
Jelle who made space for Design and Learning,
and Thatcher for being a Design Ambassador.
Thanks for taking the time