Who are we building for?
TradeWindow provides an aggregator service, Cube, for seamless integration between different stakeholders from Shipping to Retail making this truly a Farm to Plate solution.
I joined the business as the Lead CX/UX Designer. My role was centered around optimising the experience of the of individual products and connecting the product silos for a seamless CX leaving fewer mandates to the users’ workflow.
“Design and development teams assume that their users think and act like they do, so they end up designing for themselves rather than their users”
Assumptions are not inherently good or bad. They exist to help us deal with incomplete information. Sometimes it isn't appropriate to insist on an utterly complete picture before proceeding—therefore before we think of personas, learning to build and attributes of a proto-persona become important.
Working with Assumptions
Co-design and
Proto-Persona
I use a version of this proto-persona template in a workshop with SMEs and other stakeholders.
Should facilitation become challenging in the absence of a few stakeholders at the workshop, or, in the past when I have foreseen a high probability of agreement bias (typically observed in focus groups):
I run multiple smaller sessions with a fewer stakeholders or
Email the persona canvas template to individuals supported by a ‘How to’ video. In some cases, I have see much merit in running such a session with a certain anonymity.
This agrees with my ‘outcomes over output’ mindset and supports the democratic nature of Design Thinking techniques.
I then assimilated the content from all workshops and collated the findings into themes to produce one distilled proto-persona that was to be refined further by merging with qualitative research findings and customer data.
I see persona as a tool to:
State the user Goals clearly;
Surface the Roles and dependencies.
Keeping product sense in mind, we bifurcated the persona project to serve the two purposes mentioned above — Goals and Roles.
Goals of TW Cube users
In this case we had seen many common themes emerge from the proto-persona workshops done earlier and previous research exercises.
We had observed the commonality in gender, age, job tenure and other variables.
The assumptions and observations from the proto-persona developed in the previous workshops were now to be validated by refining —although the persona was welcomed by the team. So, pivoting the strategy was essential.
Further analysis and synthesis of the pervious research data gave us a range of the categorical variables that I matched with the ones in the proto-persona.
Firebase data gave us the insights to the pages and features these users accessed most. This helped us understand their goals better and validate the assumptions from the proto-persona.
I then assimilated these outcomes into a user-persona (under non-disclosure agreement) so the persona was no longer just a set of values but an entity whose attributes the teams benefitted from.
I remain conscious of the unused findings from previous research workshops before I propose a new research project.
Case in point, we had qualitative data from having met 10 different users in two different research exercises done previously.
Creating Role-Based Personas
Goal-based personas you saw earlier was of a bottom-up construct based on attitudes, preferences, and behavioural characteristics.
Role-based personas, in this instance, focus on factors that impact the technical, non-demographic details and other information typical of workflow based on a series of document production their impact on trade facilitation.
Framing an individual within a particular role helped me focus on what they are trying to accomplish — their goals and challenges — within the context of the application. Here, the most important considerations are the task at hand and the motivations of our user.
Like many others, shipping too is a highly process-led industry with acronyms and many aliases for document names and processes.
For TradeWindow purposes, I associate role-based personas with participant roles. A role frames what an individual is trying to accomplish within a particular context. For example, maybe the user role is a Beneficiary Bank whose role is to create payment and acceptance letter for the exporter by approving the Line of Credit and export documents, so that importer payment can be confirmed.
I gathered the different journeys I had mapped with the exporters previously. I consulted with the SMEs to understand the variation in the documentation required depending on:
Category of goods exported
Country of Export
Country of Import
Actors in
Jobs-To-Be-Done
Making them 'actors' - therefore:
As a…(name of the actor)
I create...(documents they create)
I require...(documents they require)
so that..(the next person can do their job)
This surfaced dependencies of jobs between their individual roles.
This artefact was purposefully used in subsequent JTBD workshops and other tasks such as;
State transitions between document/contract flows
Actions triggered by changing states
Changing taxonomy of the UI buttons
Roles — How do we use them?
What good is an artefact if it cannot meet the purpose with which it was created!
With these powerful tools, the teams delivered valuable features and updates in the TradeWindow’s offering.
State Transitions of Documents/Contracts
Document Permissions + Visibility + CRUD patterns
Document/Contract
State Transition Workshop
The team appreciated having this artefact ahead of the Document State Transition workshop. Through this workshop we laid a common understanding of the document journey and its impact on the nesting contract behaviour.
It helped the participants have meaningful solutions and streamlined conversations by presenting the requirements and constraints (laid by dependencies) in an accessible and precise manner.
While it is important to create artefacts that stakeholders can uptake, communicating processes and socialising outcomes will foster better adoption and strengthen the voice of the design team. I see this as an essential part of the design strategy.
Below are some elements from white-boarding during workshops and the slide deck, I presented to the stakeholders at the kickoff meeting and then between subsequent iterations.
A 5 part series of podcasts - ‘Personas at TradeWindow’ allowed the leads to openly share their thoughts on the persona and how they see this as a tool that will narrow the gap of our customer understanding.
What next?
