Writing good acceptance criteria is one of the keys to effective software delivery. But it’s hard. This article looks at Feature Mapping, a new technique that can help teams write higher quality acceptance criteria more easily. An Executable Specification is a Definition of Done that you can run as a test. In Behaviour Driven Development (BDD), we refer to acceptance criteria as “executable specifications”. Executable Specifications are meant to be clear, unambiguous, written in business terms, and easy to automate. Each acceptance criteria is a concrete example of how a user interacts with the system to achieve some business goal.

Visualizing user attitudes and behaviors in an empathy map helps UX teams align on a deep understanding of end users. The mapping process also reveals any holes in existing user data.

Personas have long been a useful tool in a user-centered design process; however, in recent years, jobs-to-be done, a new technique for focusing on customer needs, has been gaining steady prominence. Jobs-to-be-done (JTBD) is a framework based on the idea that whenever users “hire” (i.e., use) a product, they do it for a specific “job” (i.e., to achieve a particular outcome). The set of “jobs” for the product amounts to a comprehensive list of user needs.

Sometimes as software developers we think that if we build a good product, the users will like it. It is not however not always so easy and you have to communicate well about it, especially if you follow an Agile approach and are looking for instant and valuable feedback from your demo. In this article, Esena Gusic shares some of the tricks she uses as a product owner when delivering a product demo during the Scrum sprint review.

Empathy maps, customer journey maps, experience maps, and service blueprints depict different processes and have different goals, yet they all build common ground within an organization.

Both these complementary types of user research play important roles in an iterative design cycle. Qualitative research informs the design process; quantitative research provides a basis for benchmarking programs and ROI calculations.

Professionals want clear, concise information devoid of unnecessary jargon or complex terms. Plain language benefits both consumers and organizations.

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.