;

Behaviour Driven Development for Designers.

Featured Image

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. 

Jira for Designers: Development Types

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. 

Jira for Designers: Test Driven Development

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. 

Jira for Designers: Behaviour Driven Development

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

Jira for Designers: Why does it matter?

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).

Jira for Designers: Where do we apply it?

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 for Designers: Jira

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)

Jira for Designers: Confluence

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 joint has visibility of why we made certain decisions was more important than what gas happened yesterday. 

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

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Design Director, Trusted Advisor and Author of
Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to find your feed in teams of 01, 10, and 100, supported by Grid Magazine and Supply section, where we weekly bring more insights on how to become a design leader in your organisation.

Tagged: Apply · BDD · Behaviour · Confluence · Designers · Development · Jira · TDD · Types
EMT

Related.

Featured Image
Overview Welcome to the fourth article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-02-15
 · 
5 min read
Featured Image
Overview Welcome to the night and the last article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless …
 · 
2020-03-12
 · 
4 min read
Featured Image
Overview Welcome to the seventh article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-03-10
 · 
6 min read
Featured Image
Overview Welcome to the eighth article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-03-10
 · 
5 min read
Featured Image
Overview Welcome to the sixth article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-03-05
 · 
6 min read
Featured Image
Overview Welcome to the fifth article of the 3x3 series - Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-02-25
 · 
7 min read
Featured Image
Overview Welcome to the fourth article of the 3x3 series - Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-02-20
 · 
5 min read
Featured Image
Overview Welcome to the third article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design …
 · 
2020-02-10
 · 
6 min read
Featured Image
Overview Welcome to the first article of the 3x3 series - Confluence for Designers, where we’ll be looking at the communication structure for medium and large organisations to achieve the transparency that leads to …
 · 
2020-02-05
 · 
4 min read

Newsletter

Subscribe.

Subscription.

A tailored list of meaningful tips and assets that help designers of all levels manage their daily challenges at scale.

100+

Design Articles 

Join more than 5,000 readers who redefine product design delivery through Design at Scale™

INSTAGRAM—We know you love visual stories and bite-size quick suggestions. That is why we created an Instagram channel specifically for your taste. 

X – Daily updates, shared links, and conversations about scaling design propositions in small, medium, and large teams. Join the conversation.

DAS-Social

Your Story
Matters.

Community.

Beyond every design is a story. Every story drives curiosity and helps us grow.
Join our community to share yours.

LINE_MAGENTA_050_301

Categories

LINE_MAGENTA_050_301

Legal

LINE_MAGENTA_050_301

Share

All brands and trademarks presented on the DesignatScale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners.
Do not copy or publish any of the projects shown here without approval from 9V™ + GIVE™ + Design at Scale™ and/or relevant companies and agencies.

View