Dates: October 2018 – March 2019
Context: Part-time freelance project
The client, Unchain.io is a validated and funded small enterprise bridging business applications with various types of blockchain networks. The Value Proposition is to simplify the software integration between blockchain networks and business applications.
The project’s goal was to upgrade the user experience for the users of the digital platform for software integration. It included taking a step back and seeing the industry trends and needs, understanding the “as-is” situation for the potential client organizations and the target users within those organizations, the “to-be” scenarios of the journey that the user will be undertaking under the new value proposition. Key hypotheses were put to the test in the real world and lessons were learned.
However, most importantly, organizational change and a user-centered process had to be applied toward the developer team itself. The case study describes the deliverables and process that had to be undertaken in order to do the work itself, and for a more hidden goal – but perhaps even more important – leave behind a different team:
- more open to rapid iterations, the key question being “what is sufficient to be shown to get a helpful reaction” instead of “what else is missing for it to be good enough to be public”
- that would posses and (where appropriate) use a different mindset – that of a designer rather than of a developer and technical problem solver
- that is aware, humble and empathetic toward how the value proposition fits into the day to day life of the user; and scheduling the chance to validate that firsthand more often for all team members
Shifting between the business/user/technology mindsets ; Flow of empathy ; Breaking down silos ; Software as a service ; product vs service design ; Share-economy ; Marketplace value propositions
- As an outsider within an evolving team: setting clear expectations of what is required to do my job, and what is not: where independence and freedom is appreciated VS. when constraints are necessary
- As an agent of change, when need commitment, support and facilitation VS. what can do alone
- Earning trust with time; being mindful and explicit about changing responsibilities and powers
- Importance of understanding what the mental model of the users is in order to be able to build a new one or modify the existing one. To cure analysis paralysis within the team with outside validation at multiple stages in the process
- Optional read: Service Design vs UI/UX Design
- The Client
- Starting Point
- The Design Challenge
- 1. Research – wide and qualitative
- 2. Orchestration – from Interactions to Journeys
- 3. Organizational change – making space for lasting effects
- Conclusion – Interaction Design <> Service Design <> Strategy
Optional read: Service Design vs UI/UX Design
Services are all around us, toothbrushes become smart, paired with an app which helps us stay consistent and engaged, therefore orchestrating an experience, and not just a product. We have transitioned from buying CD’s or music toward buying a subscription to unlimited and personalized music services. Not all services are subscriptions however, museum trips, restaurants are experiences bought on an individual basis.
Strategy, which includes brand identity and the context in which the company is operating in, informs the orchestration of the services and which details are held as important and which are not. e.g. Easyjet does not prioritize user experience, as they have other goals in mind. This is working out for them very well. In today’s competitive landscape however, it has become a dangerous strategy to miss this perspective, all other things being equal.
Interaction (UI/UX) Design starts with: given that this action has to be accomplished, “What is a way to do it as pleasantly, efficiently and humanly possible?”
The feedback loop flows upward as well, from interaction design (human psychology details) – to the strategy. A collection of frustrations or sub-optimal interactions can sometimes only be addressed by a systemic reevaluation of the service, which can happen when it is a strategic goal, when time and resources are budgeted for it.
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.
The value proposition of unchain is to simplify the software integration between blockchain networks and business applications. By using plug & play reusable and modular components, integration developers and their CTOs, are able to jump over delays related to learning, testing and getting code into production.
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, the team had identified some common challenges and a value proposition to support the network integration process for their partners.
While the team 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 (which would become a wider service design challenge) 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 Value Proposition requires multiple journeys (sequences of actions) for it to make sense:
- creating custom components
- purchasing elements in order to experiment or save costs
- combining units into meaningful integrations
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 gateway through good and intuitive design plus documentation to help the system integrators 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
As described above, 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 how they interact between each other and how the value and money flows. So a good overview over: their playing field; context; motivations; 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 networksSimplified Definition
Through creating the Jobs-to-be-done, some characteristics of Integration developers became clear:
- Always on the lookout for efficiency improvements
- Natural born problem solvers: within moderately-to-well defined constraints
- Like to stick to their guns unless peer leads them to rethink, or boss incentive
- Tip: Stimulate their problem solving, and watch their path, then encourage the unexpected approaches they took and cement them with signifiers and constraints.
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 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
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.
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 details work to create a bigger picture. It also brought up a lot of questions 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 components
- purchasing elements 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 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.
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.
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.
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
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:
- What kind of marketplace do you want to start or be? (closed/open, centralized/decentralized, matchmaker/marketplace, one-way/two-way, etc.)
- What is your unfair advantage that you can take advantage of?
- What role will you play both as a facilitator and actor?
- Who is owning the technology, ‘rules of the game’, management and revenue streams of the marketplace?
- 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.
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.
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.
The repercussions of false hypotheses over the strategy of the original MVP would have been too great for the marketplace to be left outside the Usability testing cycles.
There is no chapter on strategy, as that perspective was mentioned on a contextual basis. For instance, it was apparent in the stakeholder mapping and competitor benchmarking. Clearly, it was an important consideration when editing the value proposition design of the marketplace and how that functionality affected the offering as a whole.
3. Organizational change
Making space for continuous improvement in the service offering, and in its delivery
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 scopedKey insight
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
Making it possible to learn how 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.
Please click through the following slideshow to see how the process was customized for this case:
A few observations:
Design opportunity prioritization
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
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.
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 designing and developing, so which are normally not in customer facing roles.
Signs of positive 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
Interaction Design <> Service Design <> Strategy
Hopefully the separation between interaction design and service design has been successfully explained through this case study.
Upon departure, the team was left with a better understanding of what Service Design can do, and whether it must be employed.
The team has been introduced to designers who help companies develop subscription business models, and others who have extensive experience with digital marketplaces.
The living documents/ deliverables were left in an easily editable form.
Templates and preparations for future co-creation sessions were provided in an attempt to make user involvement possible: to lower the perceived risk or difficulty.
A planning roadmap was presented including milestones on both product management and capability building / organization change objectives).
I also left a copy of the book which made steering this complex project a bit more doable and enjoyable. My thanks to the authors.
I’d like to thank the team for making space for me and for Service Design.