Jeff Patton's User Story Mapping: Unleash User-Centered Product Design

5星 · 超过95%的资源需积分: 50 184 浏览量更新于2024-07-20 1 收藏 38.8MB PDF 举报

"User Story Mapping" 是一种在敏捷软件开发中广泛应用的方法论，由Jeff Patton所著，并得到了业内权威如Martin Fowler、Alan Cooper和Marty Cagan等人的推崇。这本书的出版信息显示其国际标准书号(ISBN)为978-1-491-90490-9，定价分别为US$34.99（美国）和CAN$36.99（加拿大）。它对于提升团队的产品设计能力具有重要意义，特别是帮助团队专注于用户需求，避免陷入孤立的产品特性追求中。该书的核心理念在于揭示整个故事的全貌，通过用户故事映射（User Story Mapping）这一工具，使团队在产品开发过程中保持对用户需求的清晰关注。作者Jeff Patton强调了动态故事地图的重要性，这些地图能够引导团队进行富有成效的讨论，确保团队成员对项目目标有共同的理解。书中内容不仅介绍了如何创建用户故事地图，还提供了实践指导，让读者学会如何在整个开发流程中有效地运用这一方法，从而确保产品的正确方向。通过阅读这本书，开发者可以了解到如何在快速迭代的环境中保持团队的协作效率，以及如何将用户的声音融入到设计决策中。Marty Cagan的评价突出了Jeff Patton作为一位真正的敏捷专家，他的指导对于提升产品团队的竞争力至关重要。《User Story Mapping》不仅仅是一本技术指南，更是一本帮助团队实现从战略到战术层面转变的实战手册，旨在帮助团队达成公司所需的高度和期望。 "User Story Mapping"是一本实用且深入浅出的书籍，适合任何希望通过用户中心视角驱动软件开发并提升团队协作效能的项目经理、设计师和开发人员。无论是初学者还是经验丰富的专业人士，都能从中获得有价值的洞察和技巧，提升项目的成功率。

While the idea of collaboration is neither new nor particularly in‐

sightful, it is actually very difficult to do effectively. The way that de‐

velopers work—their pace, language, and rhythm—is quite different

from that of interaction designers.

Practitioners in each of the two fields are strong, capable, and inter‐

nally well disciplined, yet they share a single, common weakness. It is

really hard to express a design problem in programming terms, and it

is equally hard to express a development problem in design terms. The

two sister disciplines lack a common tongue. And that junction be‐

tween the two disciplines is precisely where Jeff Patton lives.

Jeff’s method of story mapping makes sense to developers, and it

makes equal sense to designers. Story mapping is the Rosetta Stone

for our digital age.

Despite protestations to the contrary, Agile development is not a very

useful design tool. It is a way of thinking about development that is

design-friendly, which is a very good thing, but by itself it won’t get

you to a product that users love. On the other hand, so many times we

have seen good designs, well documented, given to developers—Agile

or not—who manage to kill the essence of the design in the process of

implementation.

Patton’s story mapping approach is the bridge over this chasm. Inter‐

action design is all about finding the user’s truth and telling it as a

narrative. Software development is all about breaking those narratives

into tiny, functional chunks and implementing and integrating them.

It’s so ridiculously easy for the essence of the narrative to slip away

during this complex process. Yes, the functions are implemented, but

the patient dies on the operating room table.

By mapping out the user’s stories, the design retains its narrative

structure yet can still be deconstructed for effective implementation.

The designer’s story, which is a formalized version of the user’s story,

remains intact throughout the development.

The conventional corporate world has proven that it is nearly impos‐

sible for a team of two or three hundred people to build a product that

people love. Meanwhile the startup community has proven that a team

of four or five people can build small products that people love, but

even these little products eventually grow big and lose their spark. The

challenge we face is creating big software that people love. Big software

xiv | Foreword by Alan Cooper

is to try to give you a flavor of just how different the best teams are

from the rest.

With a grateful nod to Ben Horowitz’s Good Product Manager, Bad

Product Manager, here’s a glimpse into some of the important differ‐

ences between strong product teams and weak teams:

Good teams have a compelling product vision that they pursue with

a missionary-like passion. Bad teams are mercenaries.

Good teams get their inspiration and product ideas from their score‐

card KPIs, from observing customers struggle, from analyzing the

data customers generate from using their product, and from con‐

stantly seeking to apply new technology to solve real problems. Bad

teams gather requirements from sales and customers.

Good teams understand who their key stakeholders are, they under‐

stand the constraints that these stakeholders operate in, and they are

committed to inventing solutions that not only work for users and

customers, but also work within the constraints of the business. Bad

teams gather requirements from stakeholders.

Good teams are skilled in the many techniques to rapidly try out

product ideas to determine which ones are truly worth building. Bad

teams hold meetings to generate prioritized roadmaps.

Good teams love to have brainstorming discussions with smart

thought leaders from across the company. Bad teams get offended

when someone outside their team dares to suggest they do something.

Good teams have product, design, and engineering sit side-by-side,

and embrace the give and take between the functionality, the user

experience, and the enabling technology. Bad teams sit in their re‐

spective functional areas, and ask that others make requests for their

services in the form of documents and scheduling meetings.

Good teams are constantly trying out new ideas in order to innovate,

but doing so in ways that protect the revenue and the brand. Bad

teams are still waiting for permission to run a test.

Good teams insist they have the skill sets necessary to create winning

products, such as strong interaction design. Bad teams don’t even

know what interaction designers are.

Good teams ensure that their engineers have time to try out the dis‐

covery prototypes every day so that they can contribute their thoughts

on how to make the product better. Bad teams show the prototypes

to the engineers during sprint planning so they can estimate.

Good teams engage directly with end users and customers every week

to better understand their customers, and to see the customer’s re‐

sponse to their latest ideas. Bad teams think they are the customer.

xviii | Foreword by Marty Cagan

剩余323页未读，继续阅读

libingchen

粉丝: 29
资源: 263

Jeff Patton's User Story Mapping: Unleash User-Centered Product ...

最新资源

Jeff Patton's User Story Mapping: Unleash User-Centered Product ...

色域边界描述GBD

USB记录清除读取工具

图像白平衡算法

mapping(address => string) owner;mapping(address => string) user；modifier中如何让只让owner调用，如何再让user调用函数

List the three common ways of mapping user threads to kernel threads.

No mapping for GET /user/login

solidity，怎么允许mapping(address => uint)owner和mapping(address => uint)user有不同的权限调用函数

最新资源