Welcome to the Jira for Designers series brought to you by Design at Scale™ – Academy. In a previous article, we discussed Confluence as a knowledgebase(↘︎Link) complementing the Atlassian Jira Board(↘︎Link). This article will examine the two types of development and why it matters to designers like yourself to see the difference and what you can get out of it.

Disclosure: Please keep in mind that my development knowledge is limited, and my ambition is not to copy and paste what is elsewhere – but to merely introduce these methods and allow designers like yourself to ask the right questions. If you are an engineer, you’ll laugh a little – so let’s begin. 

Development types

It is quite obvious that over the last fifty years, development, the same as other disciplines, has gone through a biblical revolution. Therefore, our engineering colleagues have experienced, tested, used and ditched several different types of development approaches. More robust systems required extensive testing, which led to a method called test-driven development. Many fronts and groups reflect on the use of behaviour models and adapt to the framework called behaviour-driven development.

The only difference between the two is that test-driven development requires past the criteria reflecting the functionality (regarding the user) so the test becomes successful, while behaviour-driven development requires the user objectives, let alone the behaviour to be fulfilled. (I know this is over-simplification, but stay with me)

From the design perspective, we believe that behaviour-driven development is far more impactful across the range of organisations as it fulfils two separate functions. One is aligning the business objectives with development through design, and the second is recording and intellectual property of a specific behaviour for your product or service. Before you ask your development team, let’s look at them in detail. 

Test Driven Development

Test-driven development (TDD in short) is a software development process that relies on the repetition of a very short development cycle to fulfil the attempted or defined test. 
The first engineer defines an initially failing (automated test) case with a desire to improve or stress test the function. Then, it produces the minimum amount of code to pass that test. Finally, after the results, the engineering team refactors the new code to acceptable criteria.   

Let’s look at the TDD cycle in detail:

1/ Test Definition – write a small, focused test that defines a specific behaviour or functionality we want the code to have. This test should initially fail because the code it's testing doesn't exist yet.
2/ Write the Code – write the (simplest possible) code that makes the test PASS. Don't overengineer or add unnecessary features at this stage.   
3/ Refactor – if the test fails, rewrite the code or test criteria. Once our test passes, clean up the code.
4/ Deploy – Improve its structure, readability, and efficiency and deploy without changing its attempted behaviour. 

This is the basic. If you wish to know more about the TDD or if your engineering team prefers it, please go all in and ask them all the possible why you can. Be curious, not inquisitive. There are probably plenty of reasons why you are using the TDD(↘︎Link) in your organisation. 

I have spent 12 years in TDD and still deliver great quality fo design work in finance, media, broadcasting and telecommunication. It is fair to say that persuading the business to shift its focus is very hard but not impossible. If you wish or plan to move with your team, feel free to reach out at Design at Scale™ – Community(↘︎Link) for more technical details. 

Behaviour Driven Development

Behaviour-driven development was pioneered in early 2000 by Daniel Terhorst-North(↘︎Link). The method has grown as a response to the above-mentioned test-driven development (TDD), where programmers "get straight to the core stuff".  The approach was extended from simple tests to contextual testing and coding that minimised misunderstandings.
Since the BDD has evolved beyond analysis automated testing at the acceptance criteria, in 2004, another BDD pioneer, Liz Keogh(↘︎Link), started advocating modality and scales across devices.

The Consumer/user objectives were written in a way that engineers can programme and businesses can understand what is happening. While designers know exactly what to design – symphony. 

Given I visit "/login"

 When I enter "Bob" in the "user name" field
   And I enter "tester" in the "password" field
   And I press the "login" button
 Then I should see the "welcome" page

To 

Feature: Subscribers see different articles based on their subscription level
Scenario: Free subscribers see only the free articles
 Given Free Frieda has a free subscription
 When Free Frieda logs in with her valid credentials
 Then she sees a Free article

Scenario: Subscriber with a paid subscription can access both free and paid articles
 Given Paid Patty has a basic-level paid subscription
 When Paid Patty logs in with her valid credentials
 Then she sees a Free article and a Paid article

Why does it Matter?

To keep this article design specific, the differentiation between both methods is mainly from where they are used. More commonly, TDD(↘︎Link) will be used in a heavily regulated environment like banking and insurance, whereas BDD(↘︎Link) can be used from a start-up environment to an enterprise. There is no right or wrong. The basic premise is that small tests are written and done the same way as TDD, and still, the overall development can be done as BDD. 
The greatest advantage is when the language between Strategy(↘︎Link), Business(↘︎Link), Research(↘︎Link), Design(↘︎Link), Development(↘︎Link) and Integration(↘︎Link) becomes one. I do not say this lightly. It creates the ultimately desired transparency.
The clarity of where we are going long term reflects on strategy, mainly epics and HLRs(↘︎Link). This is translated to business and feature briefs or PIDs(↘︎Link) that are planned accordingly on a quarterly or monthly basis. Research and design focus on behaviour that directly impacts revenue and, therefore, supports profitability. When the development and integration reduce the code refactoring and integration challenges but developing an API(↘︎Link).

Where do we apply it?

As mentioned above, BDD helps the full organisation delivery cycle. With respect to design, we essentially have two lenses. One is helping strategists and business representatives define the future in digestible language. Where on the other hand, we foster a greater relationship with our engineering team by articulating the prepositions in the language that is essentially the code.
You might ask, but why are some UI tools already generating the snippets of the codes? Well, the code is written in what is designed, not how it behaves. If we engage with an engineering team, they’ll most likely rewrite the code completely to fit their development framework. 

If you run your team on the cost or you are proving a startup idea, you can go all in. I have been part of a few successful startups that defined BDD – still used snippets of the code from Figma and built a dirty (goo-looking) prototype that allowed them to get €180k in funding. Inevitably, it will be a little bit more work later on, but as a starter, it’s a great beginning.

Jira

The point here is not to replicate the cucumber documentation but to give you an idea of the method and its practical implementation in your own environment. As your proposition will be different from others, you will need to define the criteria by which you will communicate. In the majority of the cases in which we have built a foundation code, we use the following structure.

As a legitimate user,
I shall be able to take ACTION in order to achieve RESULT and, therefore, fulfil the business REQUIREMENT objective that can be measured against the defined success CRITERIA.

This way, the majority of our users' stories have been well-defined and well-understood by the Business, Design and Development Teams, leaving no room for mistakes and reducing refactoring by 32% (which in our case was three three-month budget)

Confluence

Before we started writing the stories in Jira, we ran several trials and definitions that were fully documented at the conference. You might ask why we kept this as a reference. Mostly because our team was growing or using freelancers, we needed to keep a track record of all the changes reflecting development. Therefore, whoever joins has visibility of why we made certain decisions was more important than what happened yesterday. 

For more details, please visit the Cucumber documentation or reach out to Design at Scale™ – Community(↘︎Link).