The methodologies in this toolkit focus on observing, learning from, and designing with the people interacting with open source technologies, particularly in emerging economies. This resource is created and maintained by the Ventures team at the UNICEF Office of Innovation, as part of the technical mentorship provided to the early-stage startups that we invest in. It aims to guide the design and development of user-centred products.

Jump right in

Why does it matter to Office of Innovation?

UNICEF Office of Innovation is founded on the belief that no one gets there alone. Designed around the mechanics of collaboration and the principles of an iterative growth mindset, this toolkit exists to serve early-stage companies by guiding them through digital design fundamentals. It works in tandem with the strategic and technical mentorship to support Venture Fund investees holistically.

A journey is a story; a map is one way to visualise it.

We’ve identified key user personas and presumably developed a business model canvas. Now, the user journey map paves the way for better, more efficient, and intentional product development.

In the startup environment, the impulse is to “build first, ask questions later.” But pausing to ask yourself the right questions early on can save you and your team a lot of grief. A good user journey map is one such tool to get you and your team asking the right questions.

• It creates a single source of truth - Capture an entire experience with a single system of record. It’s a shared team artefact, connected together around the user experience.

• It helps us look beyond symptoms - A user journey map helps us look beyond the symptoms and get to the root of what might be broken. Are users having a hard time learning to use your product? Are they opting out once there’s nowhere left for them to go?

The most important mindset to start with is keeping your focus radically and unapologetically on the user. It’s not about what your dev team wants or your marketing team wants – it’s about what your user wants and needs from your product.

Each persona has a distinct need or expectation and thus demands a different journey map. The map will also look very different at different stages of your product development journey. It’s advised to revisit it every 6 to 12 months for a healthy product.

Identifying the right user goal

A goal describes the overall thing the user is trying to achieve. Goals should refer to real-world end states and ideally not be confined within the scope of your solution. Goals can be layered. Depending on the phase of your product launch, we could be looking at different type of user goal. As Don Norman puts it in his book, Emotional Design, we can think about

• Visceral motivations—how a user wants to feel (Experience Goals)

• Behavioural motivations—what they want to do (End Goals) and

• Reflective motivations—who they want to be (Life Goals).

At this stage it’s typically preferred to consider a high-level reflective or life goal, since we will have an opportunity to get more granular in the chapter about user interfaces — where we will chalk out a specific moment from this journey in more detail to create task-based user workflows. A task is a more specific activity that helps users achieve their real world goals.

Be sure the goal is based on a solid insight form the field, and that it truly reflects the human needs of the user we're mapping for.

The Mapping

Decide with your team whether you're mapping the current experience or a desired or imagined future experience of the user? Then place the persona or user that you're building the journey for at the beginning, and their goal at the end of the map.

At the very minimum, these are a few swim-lanes that can get us started with drawing out a user journey map —

Be open to encountering a mismatch between user goals and your solution’s ability. In his book The Design of Everyday Things, Don Norman refers to two kinds of such gulfs — the Gulf of Execution (“How do I work with this tool to accomplish my goal?”) and the Gulf of Evaluation (”Did this work how I wanted it to?”). A lot of user mistakes happen when users do not get enough help in bridging these two gulfs, and the designers’ mental model and interpretation of how the system should work does not match users’ mental models. More on this on the chapter about designing Interfaces.

At the end of this exercise you've either found complexity in a specific phase that you want to double click into — In which case you can create a detailed service design blueprint — to include the backend activities that support the journey. Alternately, you can take a note of the challenges and opportunities that have surfaced, and use them as the fodder for further synthesis. Sometimes a comparison of different user journeys surfaces good insights too.

Individuals can be unpredictable, yet when viewed as part of a group we often find patterns and predictability in behaviour.

The purpose of sense making or interpreting is to move from seeing “what is” to “so what.” We take the raw material about our users and their environments to identify what is important in context of their decision-making and action-taking. It helps isolate the most important pieces of information to be unpacked further. The journey map is already one type of sense making we've attempted, so let's see what other tools we have at our disposal.

Looking for insights

Let’s look at a few more techniques employed by design researchers, to synthesise qualitative information. At the most fundamental level, we can start by mapping out all our information in one place. A professor of mine used to say that there’s no better way to see patterns in information than looking at everything you have, all in one place. It’s not unlike what we see on popular detective shows — there’s always that extensive wall of cutouts, cut across by red threads. Luckily we have tools like Miro to make this process easier.

Once we have an overview of our research notes, we can create Affinity Maps — Clustering common themes together and prioritise the important ones. Alternately, if we find contradiction and not similarity, we can take a note of Identified Tensions — articulate, on two ends of a spectrum, things that contradict with each other. These can often become the axes for 2 x 2s — a model often employed by strategists to arrive at actionable recommendations and insights.

In a way, it's useful to think about research synthesis as a form of data visualisation.

Designit also recommends looking for edge cases and contrast in your findings. Averages are typically well-known. Outliers and edge cases, on the other hand, are often surprising. Many well-known macro-trends contain counter-trends that are sometimes the result of some maverick doing things differently, but that can also be an early sign of a pendulum swing.

Observations to → Findings → Insights

A finding is an observation that characterises unexpected behaviour or disconnects what you see. It is non-judgemental and explainable in many possible ways. A finding is rooted in observation, and does not interpret. To help us interpret findings, we can ask why. This brings us one rung up the abstraction ladder and arrive at an insight. An insight interprets a finding and explains why this surprising behaviour might be happening.

For example, if you’re observing users trying to form a new habit, and arrive at a finding that people tend to club a new practice either before or after an existing habit, an insight might be — Existing habits are a good trigger for initiating behaviour change, or building a new habit

How do you identify a good insight?

A good insight increases empathy for the user experience. A well crafted insight allows us to frame better opportunity statements, which is the topic of our next chapter.

They are non-obvious, generalisable (grounded in multiple pieces of data or applicable to multiple participants) and actionable. When articulating an insight, you need to make sure you’re asking ‘so what’ — why is this important, and why does it affect the project?

This process of asking ‘so what’ or ‘why’ is also known as laddering. Findings ladder up to form insights. Alternately, asking ‘how’ helps us ladder down from an abstraction.

The iceberg model is another way to arrive at juicy insights. In this method of laddering we go from observed events to underlying mental models through 3 steps of ‘why’.

If you only see one solution to a problem, then you don’t really understand the problem.

"How Might We" Statements

Opportunity Statements are the bridge between the research we conducted and the solutions we will generate. They are a way of framing the problems from user research as opportunities for inventive solutions. The final step of synthesis is to reframe a problem as a possibility.

Framing How Might We statements, is one such tool that helps us translate insights into actionable design solutions. These are small but mighty questions that allow us to reframe our insights into opportunity areas and innovate on problems found during research.

The problem we encounter is that How Might We (HMW) statements are often either too vague or too specific.

• Vague and broad HMWs is that they give minimal direction or inspiration. These statements are meant to spark ideas you can later test with users. Without any focus, where should you start?

For example, ‘How might we initiate behaviour change?’ might be too broad in scope and unable to spark tangible ideas.

• When HMW statements are too narrow, we lose all the possibilities of innovative ideas that can arise from them. With too much focus, we are stuck on one particular solution already. We want several different ideas to test at the end, so focusing too much on one solution will limit creativity and innovation.

For example, ‘How might we help users build a new habit through peer validation?’ might be already point to a product feature, so we might want to reconsider broadening the scope of the opportunity

We can turn the dial on these through a laddering technique — grounding a vague statement by asking how, and broadening a narrow statement by asking why. A good HMW statement helps you focus on solving a problem. In this example, perhaps an ideal middle ground could be to ask ‘How might we nudge our user to change their behaviour by triggering the habits that they are trying to build?’

Ultimately, it needs to be a question that tickles your imagination and guides you into the next (divergent) phase of your project — to explore possible solutions in solving the right problem.

People Nerds and NNG suggest that phrasing the HMW questions positively help generate a wider scope of solutions or answers to the question.

Decision Making

A useful decision making tool at this stage is the confidence scale. In product development and prototyping, speed and quality are two important variables. Prioritising one is typically at the expense of the other. This tool helps you make that trade-off.

It recommends focusing on quality if you’re confident in the problem you’re solving and the solution you’ve created; and focusing on speed if you’re less confidence in the importance of the problem you’re trying to solve (regardless of confidence in the solution). If your confidence in the importance of problem is high, but confidence in the solution is low, then you’re in a bind and need to balance speed and quality. This is where rapid prototyping helps move things along, and iterate through variations of a solution to meet the user’s needs more acutely.

Biases

False Consensus Bias

The assumption that others will think the same way as you do. An individual is more likely to focus on information that proves their personal beliefs regardless of the truth. When you’re conducting any type of UX research, you have to be cautious. You can avoid false consensus by limiting the guidance you give users and identifying and articulating your assumptions.

Sunk Cost fallacy

The deeper we get into a project we've invested in, the harder it is to change course without feeling like we've failed or wasted time. To avoid the sunk cost fallacy, break down your project into smaller phases, and then outline designated points where you can decide whether to continue or stop.

A design isn’t finished until someone is using it.

Of all the tools in a User Experience Designer’s tool kit, usability testing is arguably the most powerful. Arguably, we’re already one step into iteration, as this chapter brings us full circle, right back to research and discovery. The way you know that you’re at a stage to employ usability testing is by listening for questions such as “Will users be able to. . . ?” and “Are there any red flags in this design?” “Why are users getting stuck?” Will our customers understand how to. . . ?” “Is it intuitive?”.

After working through your user’s journey maps and workflows, it’s likely that some of these questions have come up. In this chapter we get practical about usability research. How to build the right fidelity prototype, recruit the right participants for testing, and a few pointers on how to conduct and record research interviews.

Prototyping as a researcher’s love language

While is the most widely adopted method for testing digital products, there are many opportunities to quickly gather feedback from your user along the journey of building your product or service. This is where prototyping comes into play. Prototyping is a mindset as much as it is a technique — it can take on many forms of output and . It is a researcher’s best communication tool — allowing designers to more efficiently articulate ideas and facilitate discussions with less ambiguity than verbal dialogue. Prototyping empowers us with the open, iterative mindset necessary to evolve good ideas into great ones. It allows us to kill bad ideas early, through visually tallying ideas with ourselves, our team, and most importantly our users.

How to recruit participants?

One of the biggest barriers is often a lack of knowledge about where to find users, so let’s dig in. Where do we begin?

Taking the time to find the right users for your usability testing will pay off in the quality of the research you gather. It’s always worth the effort, and you don’t waste time conducting research with users who don’t fit the bill.

The Fidelity Framework

Think of fidelity like placing bets. Low fidelity is a small bet—quick to make, low risk, but might not tell the whole story. High fidelity is a bigger bet—more time invested, but potentially higher payoff. Here's when to use each:

[]

Conducting and documenting your user testing sessions

Participants provide the best feedback when they feel comfortable with the moderator, which could be you or one of your team members. Starting with getting-to-know-you small talk can make it easier for participants to feel comfortable and open up, both in person and virtually. You want to establish a professional-but-friendly rapport with participants right from the start.

I usually start these sessions with a brief conversation about their past experiences and existing habits that are relevant to whatever is being tested. Every session helps the team learn a bit more about the users. Always thank participants for coming, communicate how grateful you are that the participant is taking the time to participate in the study and remind participants that they should be open and honest about their experience, so the design team can make improvements.

Finally, the meat of these sessions, includes

1. Presenting participants with simple goals and scenarios so we can

2. Observe them using the product or prototype to complete key tasks

3. While asking them to think out loud.

To get the most useful feedback about the product you’ve designed, let participants know that you’re here to find out how to improve the design, so constructive criticism is more than welcome.

Just as we did with foundational research, it’s always a good idea to supplement our primary research with secondary desk research. For instance, you may want to learn about the competitive landscape, as well as the team’s perceptions of competitive and related products. Competitors’ products are great “prototypes” to learn from.

Ask yourselves, what are the closest competitors to this <feature, product, idea>?, How does this compare to competitors?, What behaviours, conventions, or expectations might users bring to this product based on their experiences with other products?

Biases

Confirmation bias

One of the most effective methods for overcoming confirmation bias during research is to ask open-ended questions when conducting interviews.

For example, if you’re conducting an online survey with a large group of participants and one of your questions is: “How do you use our product?” As the designer, you have a few ideas about how you think people use your product, so you may give them options to choose from. If none of the options apply to the user, and they can’t select “other” or skip the question, they’ll be forced to choose one of the multiple-choice answers that doesn’t match their actual experience. That means you’ll end up with false information that skews your research data and potentially provides incorrect evidence for a hypothesis you already had.

And with that, we come full circle in our journey — from research to research. You can reach out to me at for additional questions or if you need a heuristic evaluation, UI audit, or for any other design advice, asset or assessment.

Good luck on your product journey!

People don’t always do what they say, or what you think they do.

We’re all a bundle of contradictions, works in progress. As the saying goes “pay attention to what people do, not what they say”. Our actions and feedback is not often aligned, and this unpredictability forms the basis for a human centred design approach to problem solving. We must design for how people behave, not for how we wish they behaved. Products built upon empathetic insights about human behaviour, always find a place in the lives of people whose needs are being served.

As an early stage startup with all gears moving toward fund raising, it can feel like a distraction to engage in design thinking. With software it’s clear: when you don’t have programmers, you don’t get a computer program. But when a team develops a product without designers, a design gets made nonetheless — accidental, bad design, most likely.

And what is the cost of bad design?

Good design isn’t the outcome of picking up a tiny issue and creating a solution for it. It’s arrived at by gaining deep understanding for the problems people have, the context in which they use products and testing solutions with people. It’s labor-intensive and requires people who are engaged with their users over long periods of time.

But if you think good design is expensive, let’s look at the cost of bad design — it is everywhere, and it costs us. Sometimes it’s about bad design research and working off biased insights, that can cost the company down the road; and sometimes it can be decisions based on intuition, implemented in the product. If you’ve ever felt stupid using an ATM machine, or spent time filling out a form to only learn that it can’t be submitted — with no indication as to what did you do wrong — that’s bad design.

speaks in depth about five social innovations that failed in their implementation. Cautionary stories about trying to solve problems ‘for’ people, instead of ‘with’ them. A good reminder that you are not your user (one of the core principles of digital designs discussed in a later chapter) and reason to invest in systems thinking using a human-centred approach.

Companies that prioritise design embed it as a core component of strategy, culture, and process. They recognise that design is not just about aesthetics, but a strategic tool that can drive innovation, and can create a competitive advantage. When done right, design is an investment in the company and keeps the business congruent and centred around the user.

How do you define design?

Before the industrial revolution, designing was often ‘unselfconscious’, an integral part of making. As planning became separated from making, designing became more ‘self conscious’.

The understanding of design at scale, has changed over time. While it used to be conflated with applied arts and craftsmanship before the invention of the printing press, it found a place in ergonomics during the industrial age, and has come to be something of behavioural science in the information age. The growing need for graphical user interfaces, has fuelled the rise of design as a distinct discipline in the tech market, with specialisations within design sprouting by the day.

When we talk specifically about digital product design, this excerpt by Kevin Slavin, from the , is one way to ground our thinking —

The user made perfect sense in the context in which it was originally defined: Human-Computer Interaction. User-centred Design emphasised the practical and experiential aspects of the person at the keyboard, as opposed to the complex code and engineering behind it. But we are no longer just using computers. We are using computers to use the world. The obscured and complex code and engineering now engages with people, resources, civics, communities and ecosystems. Should designers continue to privilege users above all others in the system? What would it mean to design for participants instead?

At its core, Amber Case argues in, that design is a rhetoric, a reflective argument, and a philosophy of governance. Rhetoric is commonly referred to as an art of persuasion. Aristotle defined it as the technique of discovering the persuasive aspects of any given subject-matter. Classical rhetoric emphasises the speaker and is concerned with creating and teaching the art of public speaking. New rhetoric, which developed in the second half of the twentieth century, is an emphasis on appeal to the views and values of particular audiences and the structuring of argument.

Design that is effective has an influence and impact on a human subject’s belief, behaviour, or action. User Experience as a discipline isn’t neutral — it shapes how we think, what we buy, and even who we become.

Design is the intention behind a default state. When we create designs, we’re defining what is possible or what is highly encouraged within the context of our products. By implication, we’re also defining what is discouraged. Michel Foucault talked about governance as structuring the field of action for others. Governance is the processes, systems, and principles through which a group, organisation, or society is managed and controlled. In this way, design is governance as long as it shapes how a product or service will be used, and restricts people’s existing or emergent choices, even when they’re not a user themselves.

This toolkit is broken up into chapters that reflect the phases of a human-centred design process.

1. We start with discovery, diving into foundational research, stakeholder mapping, persona building, and culminating at an honest and earnest user journey.

2. We move onto the defining stage of synthesis, where we take the help of some time-tested frameworks to arrive at robust insights from our raw research findings. We’ll be setting the stage for a constructive and successful generative phase.

3. Lastly, we’ll go through the doing phase, perhaps the most intense of all — where we’ll revisit our user journey maps through task-flows. We will define our information architecture, draw a concept model of our product and start sketching wireframes.

4. And because iteration is inescapable in the design process, we’ll conclude right back at discovery — a short chapter on user testing, thus bringing us full circle from research to research.

We are no longer just using computers; We are using computers to use the world — interact with people, resources, communities and ecosystems.

We have mapped out the user’s journey, and found a way to articulate our challenges and insights as opportunities. It’s time to shift our perspective to build mode and focus on the product or solution.

In this chapter, we learn to draw user flows — a task-focused user journey within our product; (2) think through our product’s conceptual model, and (3) corresponding information architecture. Then as we put pen to paper, mouse to screen, we go through a few (4) time-tested principles for interface design.

The product or solution you are building is no doubt complex, and full of variables worth testing. So what is it that you want to prototype? Maybe you've already pinpointed a key interaction with the user. An intent-rich moment when key decisions are made and preferences shaped. Maybe it's the user’s first interaction with your solution, or something that triggers a change in their behaviour, or even the point at which they felt motivated enough to recommend your product to a friend.

Let's draw out that interaction. Think of a task that needs to be accomplished, a 'job to be done', or short term goal, and list out the very specific actions, corresponding tool used and time taken for that micro-journey. Then find what's not working about it — where the user experiences most friction or frustration —  and now you know what needs to be prototyped for testing.

Alternately, if the product is at a more mature stage, and we’re looking to fix or better a moment that lives entirely within the universe of our solution’s digital experience, we can directly dive into the language of user flows. This acts as a precursor to your wireframes or low-fidelity prototypes.

User flow(chart)s

A commonly used tool in product development, the user flow (or interaction flow, task flow) is a step-by-step visual mapping process, outlining what a user does to finish a task or complete a goal through your product or experience.

User Flows can be thought of as something like the set of directions that Google Maps dictates to you as you’re driving. Except instead of outlining the route on a road, a User Flow diagrams outlines how users moves around your product.

Typically, the visual key to a userflow diagram is as follows —

rectangle = step/ page; diamond = decision; arrow = branch; oval = start or end

Now that we have a robust understanding of our users’ journeys — both as a high-level scenario and as specific task workflows, we put on our product-centric glasses, and take a fresh look at our solution through the lens of it’s conceptual model and information architecture. As my professor would say, we have to think about .

Conceptual Models

When you say, “I know how to use the oven,” or “I know how to use Excel,” you are referring to a conceptual model. The design of a digital product almost always starts with its conceptual model. This gives the team a high-level understanding of the tasks people will do with it, the elements and actions required for them to complete those tasks, and the sequence they need to happen in. Users need to have an accurate conceptual model of a tool or product in order to be able to use it effectively. As an example of a conceptual model Johnson + Henderson describe an alarm clock.

The clock stores the current time of day, continually updating it to track the passage of time. It displays the current time constantly. Users can set the current time. Users can set an alarm at a specified time, or no alarm. When an alarm is set and the current time equals the set alarm time, the alarm is triggered. Users can turn off an alarm.

“For people to use a product successfully, they must have the same mental model as that of the designer. But the designer only talks to the user via the product itself, so the entire communication must take place through the ‘system image’: the information conveyed by the physical product itself.” - Don Norman

This brings us to the design of information.

Information Architecture

Information Architecture is the practice of organising, structuring, and labelling information to make it easier to find and understand. A definition I like is organizing stuff, so it’s easy to find. It is the backbone to creating effective digital products. Even though the information architecture itself necessarily visible in the interface, it definitely impacts the User Experience (UX). The intuition or feeling that they’re consuming content in a connected and coherent way adds up to a a UX that matches the user’s needs and expectations.

Sometimes the terms information architecture and navigation are used interchangeably. Although navigation is just a part of IA, and doesn’t quite accommodate the full scope of your product functionality, it is the translation of your thinking and the most visible part of the system of information organization. It’s helpful to rely on when considering the pathways of information.

Think about roles and permissions of a user at this stage — “who” is doing the navigating and what places do they have access to navigate between. For example, many service oriented products have a logged in vs. logged out experience. Sometimes there’s a difference in access based on subscriptions. C.R.U.D (Create, Read, Update, Delete) is a simple framework for considering the entire lifecycle of core objects in the context of roles and permissions.

Two common techniques to test your iA are card sorting and tree testing. Seeing how prospective users categorize information into groups helps the you understand users’ mental models. Be cognizant of . When presenting your users with choices, keep in mind —

Hick's Law - The time to make a decision increases with the number and complexity of choices. Miller’s Law - The number of objects an average human can hold in working memory is 7 ±2.

Equipped with more clarity around the functional components of our product, we can begin to sketch specific wireframes or low-fidelity prototypes to test part of the product for usability.

Heuristic Principles

1. Visibility of System Status, Error Prevention

Programmers know how difficult it can be to locate the source of an error in an interface which lacks immediate feedback; they have to resort to tools such as breakpoints and stepping to understand how the state of the system changes with each action specified in their code. The real difference between command-line UIs and modern GUI designs is not the presence of colourful icons — It’s visibility of system status.

Even when the system does not have a screen (voice-only devices for instance), a minimum feedback that the command was heard is essential. Amazon’s Echo displays a ring of light on the device, and a ting sound, to indicate that it is currently listening or working on the command.

Other examples include a swish sound in digital wallets to indicate processed payment or whoosh sound to convey a sent message or email. Progress bars on a survey that indicate where you are, and even the slightest vibration you feel while typing on your phone are examples of immediate feedback that increase trust in a product. It also allows users to quickly identify the source of error and fix them as soon as they were made.

It is not only about anticipating errors but also failing gracefully. Error messages are often overlooked or are added at the last minute without any thoughtful presentation or wording. They are the last tool to get users to stay in your application. Vague 404 pages or failed form submissions that don’t clearly explain what caused the failure are both types of oversights that will confuse and frustrate users. Use error messages to your advantage. Make them noticeable and make sure any part of your system where user action is required is equipped with proper error handling notices. .

In the chapter about user Goals and Journeys, we spoke of the gulf of execution and evaluation, which is worth a revisit at this point in our design process.

i. The Gulf of Execution — when users do not know what action to take. It is the space between what they want to do and what the system presents as possible. If you’ve ever hovered over a page unsure which button to click, or abandoned a form because it was unclear where to start, you’ve been inside the gulf.

ii. The Gulf of Evaluation — after the action. Did it work? Did the system respond? Is the outcome visible, trustworthy, and interpretable? If the interface does not make the result legible, the user remains stuck, even if their action was technically successful.

1. Match between system and the real world, Consistency and Standards

YOU ≠ USER. It’s easy to get caught up in the development of a product and see it so often that we take many parts of it for granted. This heuristic reminds us to use familiar language, and leverage your users’ interactions with existing objects.

Skeuomorphic web design may seem overdone, but its basic principle — to create an interaction that mimics one from the physical world — relies on people’s existing knowledge and helps them easily learn an interface, with no need for training.

Our past experiences influence our visual perception. Jakob’s Law dictates that users prefer your site or product to work and behave the same way as all the other sites they already know. As users are spending more time on digital products that are not yours, they develop ingrained expectations and mental models of how things should work.

1. User Control and Freedom

Making it easy for a user to back out of a process or undo an action, brings a sense of freedom and confidence. Exits allow users to remain in control of the system and avoid getting stuck and feeling frustrated.

1. Flexibility and Efficiency of Use

For the long term effectiveness of your solution, it’s important to think about the flexibility and efficiency of use of your product. While new users rely heavily on step-by-step tooltips or clearly labeled menus, more-experienced users learn keyboard shortcuts or touchscreen gestures to complete the same task.

Beyond simply structuring functionality to allow for open-ended approaches, another way that we can allow users flexibility in how they perform tasks is to enable expert users to customize the interface to suit their unique (and often dynamically changing) needs.

In the context of user goals and expectations, take note of two additional behavioural patterns —

Biases

Digital interfaces are also subject to a type of recency bias called the Serial Position Effect which states that users have a propensity to best remember the first and last items in a series.

In practice this means that positioning key actions on the far left and right within elements such as navigation can increase recall. Placing the least important items in the middle of lists can be helpful because these items tend to be stored less frequently in long-term and working memory. This is applicable to surveys and dashboards as well.

People make sense. It’s our job to find out why.

Human-centred design goes beyond comprehending user demands and takes into account environmental factors, cultural variances, societal effects, and ethical issues. In addition to being user-friendly, HCD seeks to develop solutions that are ethically sound, socially conscious, and flexible enough to work in a variety of settings. In this chapter we’ll dig deeper into these themes — aligning intentions and needs. This starts with framing an intended outcome, mapping relevant stakeholder relationships, and creating archetypical personas based on user research.

Intended Outcomes

Our objective is for this (existing state) to change for (key user). We want to achieve (ideal state) by addressing (common obstacle) through (our solution).

To frame our intended outcome, start with this statement. Articulate who you think you are trying to help, how you are hoping to serve them, and what factors in your environment should inform the solution you create. Think of this as a version of your mission statement, or an actionable addendum to it.

This is a statement you’ll find yourself frequently revisiting. It isn’t meant to be set in stone, but for a period of time it helps the team orient toward a specific goal. Once we have this outcome in place, let’s shift the lens outward and consider the consequences of this outcome. Every project has people who are not directly interfacing with the solution, but who have a direct stake in the outcome of a project.

Stakeholder Mapping

Stakeholder mapping brings your team together to capture what you collectively know about your stakeholders and their interests, helping you ensure you have the right representation of voices in the room. Consider those who will be affected by this work, and are invested in its success, or those who must be involved in decision making. Think about existing government relationships and potential community partners. Accounting for these key relationships early on can accelerate a project, save cost and open up opportunities that may have been invisible so far.

There are many different ways in which , here’s a template that focuses on types of value exchanged, and quality of relationships —

Place your product or company at the centre, and start with mapping the existing key stakeholders and allow yourself to speculate on potential relationships you would like to develop to help the product succeed. The word stakeholder might seem inaccurate at times, so you might want to zoom out and consider all actors with agency. Allow the map to get messy and complicated.

The advantage of mind-mapping in this way is two fold — 

1. Collaborating with different people in the team increases the resolution of information on the map.

2. The ability to scan a lot of information at once, and find connections that were previously missed.

Canvases such as Miro, Mural or Figjam allow us to get out of our instinctive linear ways of reasoning, and think spatially in systems, instead.

User Personas

A persona is a fictional, yet realistic, description of a typical or target user of the product. They help the team consider designs and plans from a point of view that is not their own.

Personas are also useful as a communication artefact for the team, creating a common vocabulary or shorthand. They enable us to recruit more suitable participants at the usability testing stage. Good personas are built off of research, not assumptions. Every piece of information should have a purpose for being included. Only add data that directly influences their interaction with the solution. Personas should be short, digestible, and focused.

Here’s a simple template to capture the archetypical user -

Consider Extreme Users

When considering the user's needs in design, it’s very easy for a designer to fall into the trap of designing for the first, average user they can think of. Only by understanding the viewpoints of a full range of people is it possible to avoid the pitfall of designing for yourself. While observing extreme users may seem counter-intuitive at first, understanding extreme users is essential for improving the opportunity for innovation in a project. Through speaking to the extreme users and identifying their amplified needs, it can help pull out more meaningful insights and thus gives the potential to push ideas in different directions that you wouldn’t have previously explored.

[]

Biases

As a researcher, Primacy bias - where you remember the first participant most strongly and Recency bias - when it’s easiest to remember the last thing you heard in an interview, conversation, or similar setting, because it's the most recent — are two inescapable traps we all fall into. While it’s probably not possible to build an immunity against them, being aware of one’s prejudices can deter their biasing effect significantly.

From the participant, Social Desirability bias or Friendliness Bias is a commonly observed one. A person’s tendency to answer questions in a way that will be viewed favourably by others or or one’s tendency to agree with those they like in order to maintain a non-confrontational conversation, is a pertinent human behaviour. Be mindful of this tendency while moderating your sessions.

In usability studies, the social desirability bias can cause participants to focus on the positive aspects of their experience with the product and minimise the negative aspects. One way to guard against this bias is provide participants with a series of statements that came from other users. Ask participants which statement they most relate to, and emphasise that there is no correct answer.

Principles and Laws

Tools for Collaboration and Thinking

Inclusive Design

Case Studies

Recommended Books

Blogs:

The alternative to good design is always bad design. There is no such thing as no design.

In this chapter we look at a few laws of gestalt and their application in digital interfaces, and the evolving field of interaction design.

Now that we have conceptual clarity about the intention of the solution and insights about the user’s expectations, along with an architecture for information, we can shift our focus toward shaping the visual graphical interface. Take this opportunity to think deeply about the form of your product. Form is a function, and nothing brings that to life better than the principles of gestalt.

To elevate the visual form of our product we could employ the principles of gestalt. These help us understand how we process visual information by either starting with the whole and then working our way to the parts, or by attempting to break a confusing whole into its simpler component parts. While it’s not a hard science, the laws of gestalt broadly include:

A century after their inception, let’s look at how the logic of gestalt theory continues to find relevance in digital interface design today.

1. Isolation Effect First off, the figure-ground perception finds it’s application as the Isolation Effect in user experience design. Gestalt states that we instinctively perceive objects as either being in the foreground or the background. This speaks directly to the Von Restorff effect or the Isolation Effect, which predicts that when multiple similar objects are present, the one that differs from the rest is most likely to be remembered. The simple takeaway is that we should make important information or key actions visually distinctive.

2. Aesthetic-usability effect

   The Gestalt psychologists called this the Law of Prägnanz (aka “good figure” or “law of simplicity”) — possibly a forerunner to the aesthetic-usability effect—which speaks to the user’s tolerance of minor usability issues when they find an interface visually appealing. Tools can make it tempting to add all sorts of elements to your interface. Just because you can, doesn’t mean that you should — be deliberate about the additional information that you add to focus user attention.

As Edward Tufte, put it so beautifully in his book, The Visual Display of Quantitative Information, “Clutter and confusion are not attributes of data — they are shortcomings of design.“

1. Law of Closure Our brains tend to fill in the blanks of an incomplete picture, to perceive a complete image (a consequence of confirmation bias). In digital interfaces this maybe experienced when you see a partial image above the fold on a screen, your brain wants to complete it by viewing the whole picture, which unconsciously drives you to scroll down a screen. Or sideways, as in the Spotify app.

2. Law of Common Fate Users expect associated elements to move in the same direction, and vice versa. To fulfil users’ expectations, you should ensure that the elements that belong together move in the same direction and at the same speed. You can use this when designing nested menus and dropdown navigations. This can often supersede or override other laws of Gestalt such as grouping by proximity, especially when applied as an animation of uniform motion for unrelated objects.

Why typography matters

Typography isn’t about making your text look good, it’s about building trust. Consistency in fonts, spacing, and design across a user's journey creates a cohesive brand image. Whether it’s your website, social media, or printed materials, using the same system and rules of font and hierarchy makes your brand recognisable and professional.

• Clarity focuses attention: Cognitive overload is a problem in today’s digital landscape. Users are more likely to pay attention when what you have to say is coherent — both visually and in tone.

• Personality brings engagement: Fonts can evoke powerful emotional responses. A playful script typeface can make your brand feel youthful and energetic, while a classic serif font exudes sophistication and trust. Think of it like choosing the right outfit for your message.

• Accessibility widens scope: Legibility and readability are non-negotiable. Universal design principles are a way to bridge mismatch of a user and their environment. Enable users to edit font weights, contrast, and letter spacing if required.

Good typography is measured by how well it reinforces the meaning of the text, not by an abstract scale of merit. Typographic choices that work for one text won’t necessarily work for another. Don’t rely on rote solutions. One size never fits all.

[read more]

What is interaction design?

The essence of the word "interaction" implies a relationship between a human and an environment. Interaction design is an art form to make experiences that fluidly respond to human intent. When does a swipe trigger an action? Do gestures retain momentum? What happens if a finger is covering content? How can we predict intent based on context? Executing well on details like these make products feel like a natural extension of ourselves.