Behavior_driven_development_and_user_experience

width=”100%”—
layout: blogpost
title: Behavior Driven Development and User Experience
image: eliran.jpg
author: Eliran Malka
tags:
– Programming
– Community
– Open Source
– Web UI
—

Behavior Driven Development (BDD) is the new “buzz word” for the programming concept of Test Driven Development (TDD).  This change in terminology is the result of the realization that the features of a product are, in fact, just behaviors that the developer needs to be aware of, test, and develop.  That is why the relationship between user experience and behavior driven development is tightly related.  User experience is just that, where the emphasis should be on the user, and their specific needs.
We tend to regard UX as development driven, and that developers and designers inherently understand what the users need. However that’s not always true.  There are specific roles focused on researching these complex aspects of UX, and understanding what users want, and it is the developer’s job to be aware of and understand this.  We really don’t always know what users want, and this should have more weight in the development process.
 
Development Based on the User’s Needs
Users often times need things we don’t always supply them with, or even know about, and we should listen to our users.  A typical development process consists of a Product Manager, or the UX designer requesting a certain feature, based on their communication with the end user and community.  However, the developer really doesn’t have any contact with the end user, and this results in a broken link in the process that needs to be fixed.  The developers should be aware of users’ needs.

Cloudify – automation, orchestration, with the tool chain you love.  Go

But how?
Speaking a Common Language
This can be accomplished if all of the stakeholders in the development process from the users, through the UX designer, the product manager, and eventually the developer speak the same language. In order to achieve this, a functional specification (spec) needs to be defined that creates a common language for everyone in the development process.  This common language should be used across the board, from internal communications and communications with the end user, through testing processes.  This will then propagate into the development process.  Once a common language is defined and understood by all the involved parties based on this spec, we can then begin to understand and extract behaviors from that common language, and start writing tests.  Why write tests first?
Test Driven Development
The common TDD methodology, AKA BDD, is based on the idea that any term defined in the spec is a behavior a user expects from the product.  If a user has an expectation from your product, this is something that should be defined and developed. This approach has suddenly reversed the process.  Users can now define features, and can be involved with defining the spec, making them an integral part of the development process.  Following the spec definition we begin TDD, we write and run tests based on this spec only. The way this works, is that TDD is an iterative process, i.e. – write tests first ? see that they fail ? see that the tests pass ? write code ? see  that the tests pass ?  update the code ? see that the tests still pass, and so forth, and so on.  So long as the test doesn’t pass we don’t have a working feature/update/bug fix/patch or whatever it is we’re attempting to rollout.
 
Why Test Driven Development has Become Behavior Driven Development
Once a stakeholder in the development process defines a certain behavior it can be changed. Behaviors can be dynamic. If a user decides they would like a certain behavior changed, we can always redefine the spec and decide upon different behaviors. Once the behavior is redefined, it is then updated  in the spec, and becomes a new term in the common language that all of the stakeholders are familiar with, which ultimately defines the development process for this new term.
It’s important to note that in addition to being iterative, the spec is also cyclic.  Each stakeholder can influence the features implemented or suggested, or suggest new features, as they all extract the needs from the users.  So eventually everyone is involved in the process.
 
Open Source Community & Development
Open source communities are usually very involved in a product, especially if they have specific expectations from a product.  That said though, they are also very careful about being respectful of the product.  Open source community members honor other people’s code.  For the most part the community will be comprised of developers who are also contributors, not just users.  They tend to be very careful about contributing, without communication first. Communication is a core value in the open source world.
If a community contributor believes your product needs to have a certain feature, they’ll usually first communicate with the developers and ask for the feature, and see how they respond, as opposed to just forking the code, writing the feature, and then pushing it back. This is why the common language is important, it makes it easier to communicate these needs.  This is especially true with open source products, when often times the community supplies answers about the product that the vendor can’t.  Therefore involving the users, and creating a common language eventually contributes to the satisfaction of the users, and their overall user experience, in return for simplifying communication.
For us at Cloudify, this is a guiding principle in our development process, to ensure our development is always behavior driven, and puts the user at the center of the experience.