-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
15 changed files
with
385 additions
and
139 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,44 @@ | ||
--- | ||
title: "Why Text is still the most powerful tool to get things actionable" | ||
meta_title: "The Who, What, Why of User Stories" | ||
description: "this is meta description" | ||
date: 2016-11-11T07:11:00Z | ||
image: "/images/userstory.jpg" | ||
draft: false | ||
--- | ||
|
||
One of the cornerstones of Scrum is the user story—a simple, yet profoundly effective tool that captures the essence of what needs to be built, for whom, and why. At its core, a user story follows the "Who, What, Why" format. I experience this format as one of the most powerful, yet "cheapest" format to get things done. | ||
|
||
|
||
### Understanding the "Who, What, Why" Format | ||
|
||
The structure of a user story is both straightforward and insightful: | ||
|
||
- **Who**: Identifies the user or stakeholder who will benefit from the feature. | ||
- **What**: Describes the feature or functionality to be implemented. | ||
- **Why**: Explains the reason or benefit behind the feature. | ||
|
||
Let's break this down with an example: | ||
- **Who**: As a frequent traveler, | ||
- **What**: I want to receive real-time flight updates, | ||
- **Why**: so that I can stay informed about any delays or changes to my schedule. | ||
|
||
This simplicity is its strength. It keeps the focus sharp and the goals clear. | ||
|
||
### The Workability of the "Who, What, Why" Format | ||
|
||
The "Who, What, Why" format forces the team to distill the feature down to its essence. This clarity helps in understanding exactly what needs to be built and why, ensuring that no effort is wasted on superfluous features. By starting with the "Who," the focus remains on the end user. This user-centric approach is crucial for building products that genuinely solve user problems and deliver value. The "Why" component acts as a constant reminder of the feature's purpose. This is where you, along with your sparring partner, can double-check the value proposition. Is this feature truly valuable from a user perspective? Does it align with our overall business goals? This step is critical for ensuring that every piece of work contributes meaningfully to the product. User stories written in the "Who, What, Why" format are easy to understand for everyone involved—developers, testers, product owners, and stakeholders. This common understanding fosters better communication and collaboration across the team. | ||
|
||
### A Real-World Application: Sparring with Your Partner | ||
|
||
Imagine you're part of a team developing a new project management tool. You've identified a potential feature: a customizable dashboard. Here's how the "Who, What, Why" format can help: | ||
|
||
- **Who**: As a project manager, | ||
- **What**: I want to customize my dashboard with relevant project metrics, | ||
- **Why**: so that I can quickly access the information I need to make informed decisions. | ||
|
||
Before committing to this feature, you bring it to your sparring partner—a fellow team member, a stakeholder, or even a potential user. This collaborative review process is invaluable. Your sparring partner might point out that while the feature sounds good, it might be more beneficial to include real-time collaboration tools instead. Or, they might affirm that this customization is exactly what's needed to enhance productivity. | ||
|
||
This iterative validation ensures that the feature is not only feasible but also valuable. It helps in catching potential issues early, saving time and resources in the long run. | ||
|
||
"Who, What, Why" - Its simplicity belies its power! |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,110 @@ | ||
--- | ||
title: "Decision-Matrix: Improve the self-ogranisation skills of your team" | ||
meta_title: "" | ||
description: "Understanding Decision-Making Levels: A Simple Guide" | ||
date: 2020-10-04T07:30:00Z | ||
image: "/images/decision-matrix.jpg" | ||
draft: false | ||
--- | ||
|
||
Often, teams struggle because no one knows who should make decisions. This confusion can lead to long, unproductive meetings, delayed actions, and general frustration. Having clear guidelines on who makes decisions can help teams work better and faster. One way to achieve this is by using a decision matrix, which outlines who decides and how they do it. We'll explore an eight-level decision matrix that shows the different ways decisions can be made and who is involved at each level. | ||
|
||
## The Decision Matrix | ||
|
||
<table> | ||
<thead> | ||
<tr> | ||
<th class="text-center">Who decides</th> | ||
<th class="text-left">... how</th> | ||
<th class="text-right">Decision Level</th> | ||
</tr> | ||
</thead> | ||
<tbody> | ||
<tr> | ||
<td rowspan="3" style="vertical-align:middle; text-align:center;"> | ||
<svg class="w-10 m-auto fill-slate-50 " xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512"><!--!Font Awesome Free 6.5.2 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free Copyright 2024 Fonticons, Inc.--><path d="M224 256A128 128 0 1 0 224 0a128 128 0 1 0 0 256zm-45.7 48C79.8 304 0 383.8 0 482.3C0 498.7 13.3 512 29.7 512H418.3c16.4 0 29.7-13.3 29.7-29.7C448 383.8 368.2 304 269.7 304H178.3z"/></svg> | ||
The owner</td> | ||
<td>... decides.</td> | ||
<td class="text-right">Level 1</td> | ||
</tr> | ||
<tr> | ||
<td>... decides and explains.</td> | ||
<td class="text-right">Level 2</td> | ||
</tr> | ||
<tr> | ||
<td>... seeks advice and decides.</td> | ||
<td class="text-right">Level 3</td> | ||
</tr> | ||
<tr> | ||
<td rowspan="2" style="vertical-align:middle; text-align:center"> | ||
<svg class="w-10 m-auto fill-slate-50" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 512"><!--!Font Awesome Free 6.5.2 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free Copyright 2024 Fonticons, Inc.--><path d="M96 0C43 0 0 43 0 96V416c0 53 43 96 96 96H544c53 0 96-43 96-96V96c0-53-43-96-96-96H96zM64 96c0-17.7 14.3-32 32-32H544c17.7 0 32 14.3 32 32V416c0 17.7-14.3 32-32 32H96c-17.7 0-32-14.3-32-32V96zm159.8 80a48 48 0 1 0 -96 0 48 48 0 1 0 96 0zM96 309.3c0 14.7 11.9 26.7 26.7 26.7h56.1c8-34.1 32.8-61.7 65.2-73.6c-7.5-4.1-16.2-6.4-25.3-6.4H149.3C119.9 256 96 279.9 96 309.3zM461.2 336h56.1c14.7 0 26.7-11.9 26.7-26.7c0-29.5-23.9-53.3-53.3-53.3H421.3c-9.2 0-17.8 2.3-25.3 6.4c32.4 11.9 57.2 39.5 65.2 73.6zM372 289c-3.9-.7-7.9-1-12-1H280c-4.1 0-8.1 .3-12 1c-26 4.4-47.3 22.7-55.9 47c-2.7 7.5-4.1 15.6-4.1 24c0 13.3 10.7 24 24 24H408c13.3 0 24-10.7 24-24c0-8.4-1.4-16.5-4.1-24c-8.6-24.3-29.9-42.6-55.9-47zM512 176a48 48 0 1 0 -96 0 48 48 0 1 0 96 0zM320 256a64 64 0 1 0 0-128 64 64 0 1 0 0 128z"/></svg> A group</td> | ||
<td>... decides if everyone supports it.</td> | ||
<td class="text-right">Level 4</td> | ||
</tr> | ||
<tr> | ||
<td>... decides if no one is against it.</td> | ||
<td class="text-right">Level 5</td> | ||
</tr> | ||
<tr> | ||
<td rowspan="3" style="vertical-align:middle; text-align:center"> | ||
<svg class="w-10 m-auto fill-slate-50" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 512"><!--!Font Awesome Free 6.5.2 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free Copyright 2024 Fonticons, Inc.--><path d="M96 128a128 128 0 1 1 256 0A128 128 0 1 1 96 128zM0 482.3C0 383.8 79.8 304 178.3 304h91.4C368.2 304 448 383.8 448 482.3c0 16.4-13.3 29.7-29.7 29.7H29.7C13.3 512 0 498.7 0 482.3zM609.3 512H471.4c5.4-9.4 8.6-20.3 8.6-32v-8c0-60.7-27.1-115.2-69.8-151.8c2.4-.1 4.7-.2 7.1-.2h61.4C567.8 320 640 392.2 640 481.3c0 17-13.8 30.7-30.7 30.7zM432 256c-31 0-59-12.6-79.3-32.9C372.4 196.5 384 163.6 384 128c0-26.8-6.6-52.1-18.3-74.3C384.3 40.1 407.2 32 432 32c61.9 0 112 50.1 112 112s-50.1 112-112 112z"/></svg>Each individual</td> | ||
<td>... seeks advice and decides.</td> | ||
<td class="text-right">Level 6</td> | ||
</tr> | ||
<tr> | ||
<td>... decides and explains.</td> | ||
<td class="text-right">Level 7</td> | ||
</tr> | ||
<tr> | ||
<td>... decides silently.</td> | ||
<td class="text-right">Level 8</td> | ||
</tr> | ||
</tbody> | ||
</table> | ||
|
||
|
||
## The Decision Matrix Explained | ||
|
||
The decision matrix categorizes decisions based on who makes them and the extent of consultation or explanation involved. Here’s a breakdown of the eight levels: | ||
|
||
### Levels 1-3: Owner-Centric Decisions | ||
|
||
#### Level 1: The Owner Decides | ||
At the most autonomous level, the owner or leader makes decisions unilaterally. This approach can be effective for urgent decisions or when the owner has the most expertise. | ||
|
||
#### Level 2: The Owner Decides and Explains | ||
Here, the owner still makes the decision but provides an explanation to the team. This fosters transparency and helps the team understand the rationale, potentially increasing buy-in. | ||
|
||
#### Level 3: The Owner Seeks Advice and Decides | ||
In this scenario, the owner consults with team members before making a decision. This approach leverages collective input while retaining final decision-making authority. | ||
|
||
### Levels 4-5: Group-Centric Decisions | ||
|
||
#### Level 4: The Group Decides if Everyone Supports It | ||
Decisions are made collectively, requiring unanimous support. This ensures total agreement but can be time-consuming and challenging to achieve consensus. | ||
|
||
#### Level 5: The Group Decides if No One is Against It | ||
A slightly more flexible approach, decisions are made as long as there are no objections. This method balances inclusivity and efficiency, allowing for quicker consensus while addressing major concerns. | ||
|
||
### Levels 6-8: Individual-Centric Decisions | ||
|
||
#### Level 6: Each Individual Seeks Advice and Decides | ||
Individuals make their own decisions but seek advice beforehand. This encourages collaboration and informed decision-making while maintaining personal autonomy. | ||
|
||
#### Level 7: Each Individual Decides and Explains | ||
Here, individuals make decisions independently but must explain their choices to the team. This promotes accountability and transparency within the organization. | ||
|
||
#### Level 8: Each Individual Decides Silently | ||
The most autonomous level for individuals, decisions are made without consulting others or providing explanations. This can be efficient for minor or routine decisions but may lack transparency and cohesion. | ||
|
||
## Practical Applications of the Decision Matrix | ||
|
||
Implementing this decision matrix can significantly enhance clarity within an organization. By clearly defining who is responsible for what decisions and how they should approach them, teams can avoid confusion and streamline processes. | ||
|
||
Different situations may call for different levels of decision-making. For example, in crisis situations, Level 1 (The Owner Decides) might be most appropriate. Conversely, for strategic planning, involving the group (Levels 4 or 5) could yield better results. | ||
|
||
Encouraging various levels of consultation and explanation fosters a culture of engagement and accountability. When team members feel their input is valued, they are more likely to be committed and motivated. | ||
|
||
The matrix also helps balance the need for individual autonomy with the benefits of collaborative input. Levels 6 and 7, for instance, empower individuals while ensuring they remain connected to the team’s objectives and insights. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,100 @@ | ||
--- | ||
title: "How to Navigate UX Risks" | ||
meta_title: "" | ||
description: "this is meta description" | ||
date: 2017-02-09T05:00:00Z | ||
image: "/images/risk-mgnt.png" | ||
draft: false | ||
--- | ||
|
||
Risk is an inherent part of any design process. Whether you're launching a new product, updating a service, or implementing a novel feature, understanding and managing potential risks is crucial. Effective risk management not only helps in avoiding pitfalls but also maximizes the potential for success by balancing risks with rewards. The core idea is to identify, assess, mitigate, and continuously monitor risks to maintain control over the design process. | ||
|
||
## The Risk Management Framework | ||
|
||
The risk management process is a structured approach consisting of six essential steps: | ||
|
||
1. **Establish Organizational Objectives** | ||
2. **Identify Hazards** | ||
3. **Assess Hazards** | ||
4. **Develop Risk-Reduction Controls** | ||
5. **Implement Controls** | ||
6. **Evaluate and Monitor Controls** | ||
|
||
### 1. Establish Organizational Objectives | ||
|
||
Aligning on organizational objectives is the foundation of effective risk management. Clear objectives provide a benchmark against which potential risks can be measured. For example, an e-commerce team might aim to increase revenue per visitor through features like 1-click purchasing. Understanding the strategic goals helps in prioritizing risks and aligning mitigation efforts with business priorities. | ||
|
||
### 2. Identify Hazards | ||
|
||
Identifying hazards involves recognizing any aspects of the design that could potentially cause harm to the business or its customers. Hazards can range from usability issues leading to customer dissatisfaction to financial risks such as increased operational costs. A comprehensive hazard identification process includes input from various stakeholders to cover all possible angles. | ||
|
||
### 3. Assess Hazards | ||
|
||
Assessing hazards requires evaluating both their likelihood and impact. This step quantifies risks, helping prioritize them based on their potential effect on the project. The risk assessment can be mathematically represented as: | ||
|
||
\[ \text{Risk} = \text{Likelihood} \times \text{Impact} \] | ||
|
||
#### Example Hazard Assessment | ||
|
||
| Hazard | Likelihood | Impact | | ||
|------------------------------------------|-------------|------------| | ||
| Increased number of accidental transactions | Likely | Moderate | | ||
| Increased number of fraudulent transactions | Occasional | Critical | | ||
| Increased shipping costs and CO2 emissions | Frequent | Moderate | | ||
|
||
### 4. Develop Risk-Reduction Controls | ||
|
||
Once hazards are assessed, the next step is to develop strategies to reduce these risks. Mitigation strategies should aim to lower either the likelihood or the severity of the risks, or both. This might involve design changes, process adjustments, or introducing new tools and technologies. | ||
|
||
#### Example Risk Mitigation Strategies | ||
|
||
| Hazard | Mitigation Strategy | New Risk Probability | New Risk Severity | | ||
|------------------------------------------|--------------------------------------------------------------|----------------------|-------------------| | ||
| Accidental transactions | Provide confirmation and cancellation options; delay fulfillment by 12 hours | Occasional | Negligible | | ||
| Fraudulent transactions | Require authentication within 12–24 hours of 1-click ordering | Seldom | Critical | | ||
| Increased shipping costs and CO2 emissions | Offer "Ship Now" and "Ship with Next Batch" options | Likely | Moderate | | ||
|
||
### 5. Implement Controls | ||
|
||
Effective implementation of risk-reduction controls is critical. This step involves translating mitigation strategies into actionable changes within the organization. Clear documentation and communication ensure that all team members understand their roles in managing and reducing risks. | ||
|
||
### 6. Evaluate and Monitor Controls | ||
|
||
Risk management is an ongoing process. Regular evaluation and monitoring of controls ensure that they remain effective over time. As the design evolves, new risks may emerge, necessitating continuous adjustments. Feedback loops and periodic reviews help in maintaining an up-to-date risk management framework. | ||
|
||
## Case Study: Implementing a 1-Click Purchase Feature | ||
|
||
To illustrate the risk management process, let's consider the example of an e-commerce team implementing a 1-click purchase feature. The primary objective is to increase revenue per visitor by simplifying the purchasing process. | ||
|
||
- **Objective**: Increase revenue per visitor | ||
- **Hazards Identified**: | ||
- Increased accidental transactions | ||
- Increased fraudulent transactions | ||
- Increased shipping costs and CO2 emissions | ||
|
||
- **Risk Assessment**: | ||
- Likelihood of accidental transactions: Likely | ||
- Impact of accidental transactions: Moderate | ||
- Likelihood of fraudulent transactions: Occasional | ||
- Impact of fraudulent transactions: Critical | ||
- Likelihood of increased shipping costs: Frequent | ||
- Impact of increased shipping costs: Moderate | ||
|
||
- **Risk-Reduction Controls**: | ||
- Accidental transactions: Add confirmation and cancellation options, delay fulfillment by 12 hours | ||
- Fraudulent transactions: Implement authentication for high-value purchases within 12-24 hours | ||
- Shipping costs: Provide options for immediate or batched shipping to optimize costs and reduce emissions | ||
|
||
- **Implementation**: | ||
- Design the user interface to include confirmation steps and cancellation options | ||
- Integrate authentication mechanisms for high-value transactions | ||
- Develop backend systems to manage shipping options effectively | ||
|
||
- **Evaluation and Monitoring**: | ||
- Track accidental transaction rates and adjust confirmation processes as needed | ||
- Monitor fraud rates and refine authentication protocols | ||
- Analyze shipping data to ensure cost and emissions targets are met | ||
|
||
## Watch out! | ||
|
||
Risk management in design is a dynamic and essential aspect of project success. By systematically identifying, assessing, controlling, and monitoring risks, organizations can navigate the complexities of design with greater confidence and effectiveness. The structured approach outlined in "Design Risks: How to Assess, Mitigate, and Manage Them" provides a valuable framework for minimizing negative impacts and enhancing the potential for successful design outcomes. |
Oops, something went wrong.