Some things have worked really well, some less so. To try and learn how to replicate our product successes as we scale, and teach new people what is working, we’ve been doing a lot of reflecting on how we work. There is one thing we do at Intercom that I believe is a major factor in contributing to our progress so far. This thing, is deeply understanding the problem each project sets out to solve. This sounds obvious, and is something that others say they do too, but we do it a little differently.

As a senior UX designer and agile coach, Claire and I would often talk about ‘what’ we did and ‘how’ we did it, but rarely stepped back to ask, ‘why?’ Why do we do Agile or Lean? Why do we do a particular practice or framework? Why do we decide to build a particular feature? The easiest way to enact change is to get people to move to a place where they always wanted to be; the message we used to show that shared place was Lean UX [1]. This is about how we came together to introduce Lean UX at BNZ and how our biggest insight was the power of the language and the vocabulary we use. How language has a massive impact on our mental models and the way we view the world. Language can inspire and unite, it can also confuse and alienate. The vocabulary we used as part of Lean UX worked on a tribal level to empower teams to make better decisions through getting people to unite behind the ‘why’ not ‘how’ or ‘what’.

In classical (waterfall) project management approaches, the requirements review is an essential gate before starting the actual software development phase. If you participate to these meetings as a software tester, your role is to make sure that the software requirements are testable during the acceptance testing process. In this article, Richard Ellison provides advice on how to handle the requirements validation process from a software testing perspective.

In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? This article gives you 4 reasons why it is a bad idea to split unfinished product backlog items.

User stories are one of the main format to record user needs in the Agile world. There is however a debate on the amount of information that should be available to the Scrum team before starting the sprint. In this article, Zuzi Šochová recommends to minimize the size of user stories and to define simple conditions of satisfaction instead of writing acceptance criteria.

UX practitioners often use the power of storytelling in their work — personas, scenarios, and UX stories all incorporate specific details and cause-and-effect relationships to make user needs more concrete and persuasive for designers and stakeholders. But, like any tool, these narrative techniques are risky when misused.

As the product owner, you are responsible for the product’s vision, and ultimately, the value of your product. You “own” the backlog. If your responsibilities include upstream product management—what I refer to as strategic product ownership—then you also shepherd your product through its entire lifecycle. Bottom line, your prime responsibility is deciding what to build and when to build it. Your decisions guide not just the health and well being of your product, but also all the people engaged in product discovery and delivery. Yet a common product ownership struggle I see in agile teams—regardless of industry and product type—is determining how to make decisions. As an agile coach, I use a pattern I call “Decide How to Decide.” It’s a simple technique to help people make transparent, participatory, and trusted decisions.

Help audiences empathize with users and buy into your design goals with well- crafted stories that build insight and focus on users and their needs.

The primary goal of creating a minimum viable product is not to build something, but instead to learn something. For Ries, who was working at a startup consisting almost entirely of engineers, the easiest way to get their product in front of prospective customers was to build and launch an initial version of it. Hence, the minimum viable product, or MVP.

This article provides an overview of a product design process, then discusses some indispensable activities that are part of an effective design process, with a particular focus on those activities that are essential for good interaction design. Although this article focuses primarily on activities that are typically the responsibility of interaction designers, this discussion of the product design process applies to all aspects of UX design.