Client: Unchain.io
Date: 2018-19
Duration: 6 months
Organizational-DesignDesignOpsCulture-TransformationMulti-StakeholderStrategy
The client, Unchain.io is a validated and funded small company that bridges business software with various types of blockchain networks.
The starting point for my work was a high fidelity prototype – a technical demonstrator. The predominant attitude was “we will open it up for feedback only when it works and is ready”.
The project’s goal was to upgrade the usefulness (relevance) and usability (user-friendliness) of the digital platform.
My work consisted of two parallel tracks:
- Actual Design work
- For Design to take place, enabling factors were required.
The rest of the article will describe the 3 Key Takeaways ⭐, followed by three chapters: Research, Orchestration, Organizational Change – 🔗 don’t miss this one
3 Key Takeaways (~2 min read)
⭐ Taking on a different perspective
Stepping away from being experts… Assuming a beginner’s frame of mind
By cultivating a humble and empathetic mindset, the team became more open to rapid prototyping and validation.
It helped us bring assumptions to the surface and get closer to building the right thing.
Saving costs and helping team dynamics by avoiding going down unnecessary roads.
Why are people resisting reality-testing their ideas with the target audience ?
Perhaps one is trying to avoid being perceived as annoying… Or in order to defend against criticism and damaged reputation.
Ecosystem map “as-is”
Communicating using tangible props can be more accessible for those who won’t sketch
⭐ A Participative approach
A participative and co-creative approach was the only way to tackle such a multi-stakeholder environment. Very complex and continuously changing.
This way of working has the advantage of making assumptions explicit so that they can be verified and acted upon. When applied well, participative sessions can save cost because feedback is given in real time, when it can still be useful.
The approach can also help motivate the participants and build buy-in (by having a stake, or by feeling listened).
It stimulates empathy and understanding – stepping out of our comfortable shoes – into reality, or at least into a different perspective.
⭐ Applying a New Process
When attempting behavior change toward the technical team, a good way to make it lasting was by “shaping the path” – organizing the incentives and operations in such a way that the new way becomes the easy and common sense thing to do.
The old question:
“what else should we build and improve before publishing our work”
Was slowly being replaced with:
“what is the minimum we can show so that we get a helpful reaction which teaches us X”
The rest of this article will further describe the 3 big efforts:
Research (1 min)
Orchestration (2 min)
Organizational Change (3 min – makes important points)
Research:
Wide and Qualitative
It ain’t what you don’t know that gets you into trouble.
It’s what you know for sure that just ain’t so. – Mark Twain
In Service Design, there are more perspectives and more stakeholders to take into account compared to UI/UX Design.
Empathy, an in-depth understanding of the Personas and their context is necessary but 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.
Other 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 service providers; regulators; client’s clients; etc).
Ecosystem Map
(early version, “as-is” )
Jobs-to-be-Done
Contrasting the needs, goals and constraints of the 3 key stakeholder types
Other work included:
- Defining the Persona 🔗 : in B2B the user is not always the same person as the customer (decision maker)
- Understanding Consortia between Organizations and the Enterprise blockchain Landscape 🔗
- Observing and Interviewing the target audience
- User-testing parts of the journey
Dealing with ‘second-hand’ information from colleagues is necessary in the real-world. However, special care should be taken to not confuse ‘interpretations’ with ‘raw observations‘.
Orchestration: assembling micro-Interactions into complete Journeys
Zooming in for the important details and zooming out to ensure a meaningful experience…
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. (Or Experience Map if it covers more customer segments/personas)
The map 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 also contributed to a shared understanding within the team on how various hidden details and internal process work to create a bigger picture for the customer.
Other work included:
- Creating Moodboards based on similar offerings and competitors
- Exploring beyond the MVP: creating a Marketplace 🔗
Blueprint
Map
You can’t manage what you can’t measure.
And you can’t measure what you don’t see.
Building on top of mature Design Systems
IBM’s Design Language
Experimenting rapidly using click-through mock-ups
When cardboard or paper mockups are not enough 🙂
Organizational Change
(that lasts)
Empathizing with your own team members is perhaps even more important than empathizing with other stakeholders.
What is keeping them from changing their process or mindset? Is it a habit? Are they trying to protect their work product from criticism or their process from too much interference?
What actions should we take and what commitments should we make – such that the new space for Design remains and expands after my departure ?
Transforming an organization (even a small one of 10 people) such that it embodies Service Design is a project that takes more than half a year and more than a part-time Junior Designer.
But its a start.
This effort included:
- organizing Sprints/Jams/Sessions – because some things are only learned by doing and experiencing.
- lobbying decision makers for budget allocations or process changes
- creating Ambassadors at key levels in the organization who speak up during key meetings
Design impacts Strategy
Presented a tailored roadmap, including milestones on capability building and achieving higher and lasting design maturity 📈
Aside from the Deliverables, and the experience of being involved in Design, the team was left with:
A new creative process: Presented at length three pages down, in the ⭐ Third takeaway 🔗
Templates and preparations for future co-creation sessions with a hope that it would be seen as less intimidating, and less risky.
Shaping the path
Introductions and partnerships were laid out in which ‘off the shelve SaaS marketplaces’ and ‘experts in recurring commerce’ would be involved.
As a result, encouraging the human and business perspectives in an already heavily technical team
Learning by doing
By building on top of an existing Marketplace platform, the creation of it would not become 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 using shortcuts (rapid-prototypes).
They would be required to place themselves in the shoes of the users – instead of asking technical questions regarding feasibility.
Toward the end, the positive signs for lasting change were:
- The only person in the team with a design background was given more time to do it
- Addition of 1 new designer role
- Opening up the platform for public beta and experimentation
I am grateful to
Jelle who made space for Design and Learning,
Thatcher for being a Design Ambassador,
P.S. # Lifelong learning:
Having good designers on the team does not guarantee that the work being delivered will be good or relevant.
Design Operations (DesignOps 🚀) has the purpose of shaping an organization in order to ensure that the 3 activities are happening together consistently:
Technical work done based on design decisions, which in turn would rest on understanding, validation and user research.
