Appendix: Embedding Design in an Organization

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 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.

More background on the team:

The team had been doing personalized consultancy and implementation work in enterprise blockchain 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 had strong technical skills in-house, the design expertise was not built within the team and was outsourced to freelancers.

In addition, the predominant attitude was to show the product for feedback only “when it is ready”, not a moment earlier. This could be due to wanting to defend one’s own work from criticism and to not damage one’s reputation.

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).

Ecosystem map “to-be” (created using Mural)
Research Method details:
  • Observing or leading discussions and interviews 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.

Using the hidden knowledge that is already within the team can unlock important discussions and build trust between team members as well.

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.

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

Defining: Micro-Interactions ⬅ Journey Map ⬅ Blueprint

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.

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.

Blueprint map “to-be”

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.

Blueprint map: What the MVP excludes

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.

Competitor Moodboards and Design considerations (IBM Design Kit)

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”.

Visualizing the different Prototyping fidelity levels:
Levels of prototyping fidelity – 3 types of Design – TISDD Ch. 7, p. 222

Exploring beyond the MVP: a Marketplace

Read more: What is a marketplace ?

A marketplace plays a role in the exchange of value. 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)


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.

Sharetribe – a framework for creating marketplaces

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 usersinstead of asking technical questions regarding feasibility.

All successful marketplaces are Co-Created (intentionally or not)

Following the prototyping of the Marketplace functionality, the perspective had shifted to include the Marketplace toward future user test and co-creation sessions. This large change in functionality covers too many assumptions (with impact over the vision of the service offering), which need to be reality tested early with the target audience in a Co-creation fashion.

Offering a marketplace comes with a requirement for extra capability and talent, meaning that energy should be budgeted to build these abilities as soon as possible.

Finally, the option of building on top of turn-key solutions (e.g. Sharetribe, supporting and simplifying interaction + technical aspects) was seen as preferable compared to building a marketplace from scratch.

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.

The process for implementation – TISDD Ch. 8.3

Please feel free to pause and click through the slideshow to see how the process was applied:

How to prioritize 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?”

Source: – Re-framing pain points into opportunities

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).

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, people which are normally not in customer facing roles.

Reflection -the relevance of a Participative approach:

The value of deliverables is in:

  • the knowledge they collect and present;
  • team alignment they create;
  • discussions and actions they stimulate or make possible;
  • process steps they make us go through.

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 as a whole; they to create a habit out of making space for human centered design.

Involving outside stakeholders is more difficult to arrange, but will always result in reality-checks… It is difficult because these sessions require more intense preparation, must account for sensitivity about confidential information and require more process steering because the participants have wider ranging goals.

Working with outsiders also involves the ability to tell when an idea requires validation and contribution VS when it is too fresh and intangible to be understood for any useful feedback to occur.

I am grateful to
Jelle who made space for Design and Learning,
and Thatcher for being a Design Ambassador.

Thanks for taking the time