;

March 30, 2020

The Folder Structure for your remote team

Welcome back; this article is part of the series called DaS™ – Naming convention.

The previous article explored the history and mental models behind sorting information in digital space. This article will discuss how our research impacted folder structures for remote product teams. One place, one location, and one language contribute to better transparency across the team and the business. 

Figute02: Structure 

The Structure

The structure below, in essence, represents the mental model of the product team. Instead of being biassed and having 27+ different folders describing brief, org-chart, or god knows what, we have surveyed 1k+ people about what folder structure they use while delivering the product or service. [001↘︎]

With hundreds of answers from the different business functions, we’ve settled on a product design structure that any designer can adopt from day one.

Company Name

The same (or similar) as the file structure in the previous article, I tend to create the following mental pattern where the “The Company Name” becomes “TCN” (for the purpose of this article). The TCN becomes an abbreviation of any sub-folder or files I create within. 

Please note: if you have been working for one single company for more than fifty years like my father, skip this point – there is no point in repeating the name of the company you dedicated your life to. 

If not, the advantage of this activity is that whenever you type in Apple Spotlight Search or any other alternative cloud drive can reach the file you are looking for in less than two clicks – simply search for it.

Figute03: Business, Design and Development

Order

We all like the specific order. I have already spelt some secrets in this article[002↘︎], so feel free to dive into even more details if you wish. In general, I define the structure for every business startup or corporation in the following way:

Business (Strategy and Vision)
Experience (Design)
Technology (Engineering)

I’ve been successfully operating for more than a decade and a half within this model:

Figute04: Structure

Name of the Company 

(Business)

1.0 — TCN* Hello
2.0 — TCN* Business
3.0 — TCN* Research

(Design)

4.0 — TCN* Content
5.0 — TCN* Experience
6.0 — TCN* Design

(Development)

7.0 — TCN* Development
8.0 — TCN* Releases
9.0 — TCN* Integrations

*As you can see from the structure above, the numbers define the order, the brand defines the logical group, and sections decide the function related to the product.     

The Function

Each folder has a specific set of correlated data with the desired output—for example, the PID – Project Identification Document[003↘︎] is in the Business folder. The research folder [004↘︎] compiles all competitive, design, behavioural, and user landscape analyses reused (or referred to) in the following folders: experience, design or development, etc.

The reason behind that is quite simple. If we refer to research, we should have everything in one place. Then if we build something on these findings, the desired behaviour = 5.0 Experience[005↘︎], particular visual treatment = 6.0 Design[006↘︎], or perhaps inevitable functionality = 7.0 Development[007↘︎], in a specific timeframe = 8.0 Release[008↘︎]. 

Figute04: Application 

Application

The team of one

As a team of one, you are the queen, king or both in your kingdom. You set up, challenge and maintain the structure as you wish. Even if you start creating the shared files, you can still control your network and keep it tidy. 

If you make it suitable (according to research), you save yourself 23% of your time; if not, you waste almost 40% of your time finding stuff. [009↘︎]

One Team

That brings us to the team of many. You might ask why this structure is not in the group of many, too – actually, it is as it becomes scalable from a “one to many” mental model.

Over the last 1000+ implementations, I’ve asked everyone how they found it. We discussed, amended and implemented with little to no changes. The departments and functions focused on the delivery adopted quickly, whereas the departments focused on individual outputs like the insights team need a bit of tweaking. 

Here are the differences: 

A product has specific needs compared to a department, research or insight function within these departments. That dictates the adjustment for the purpose. 

Surprisingly enough, the structures that we adopted in 2006-8 are still in place and spread across the entire 3000-plus employee business as a natural response to the need for – clarity, transparency and accessibility. 

Team of Teams 

That brings us to the final advantage … and perhaps the more relevant one in the current era.
Literally, all organisations currently scale their propositions and call for “staff on-demand” integration. Having the corporate “product-based structure” aligned allows BA, UX, UI, researchers or copywriters to find relevant information every time they move from one team to another in the same business unit is even more crucial.  

The calculated waste of time finding the latest information in a corporation of 1k+ people is more than 40% of productive time. Let’s translate this to a 20-day month – eight days will be wasted on finding existing stuff. 

(the number above includes – a journey from login, opening up and adequate resources and search for a specific piece of information in the digital structure)

Remote Teams

That brings us to the latest and most relevant point: remote teams. 

It’s no longer applicable to freelancers as every one of us works remotely. One of the most common daily questions is:

“Where can I find the latest design, presentation or prototype?” – Linked in Survey

We spend 16% of our productive time (over an hour a day or 3.2 days a month on Slack) rather than creating a flexible structure that works wide cross-company. By polluting our conversation about where the stuff is, we lose the touch of making things. Concentrating on communication makes everyone busy with zero impact on our users.

Figute05: Where Next 

Where next 

The folder structure will not save the communication challenges for your company. Yet, very soon, you might recover some of your time and sanity regarding your productivity. You can read the other two days if you are more productive and work only 6 hours a day. 

Here are some considerations that help me with my thinking; yours might be different.

1/ How do you run the project? 

– Jira, Confluence, Trello Asana, Miro?
– MS 365, Google Drive or DropBox?
– Or both and more?

2/ Is there a hierarchy/dependency?

– Do you know where you are by looking at the specific folder or piece of information?

3/ How deep can you go?

– 3x3 goes only three levels.
– That still gives you 243 places to put and organise your work around one project (never use more than 90, even in the most complex proposition)

4/ Does your text replicate the operational structure of your local folder or your structure in the work folder?
(for the purpose of this article)

– My files
IN – From Client
WORK – Work in progress
OUT – Delivered
LIVE – Signed Off
5/ What will happen in someone accidentally delete the folder?

– is there a backup/history?
– how far does the backup goes?
– is that important for the project? 

“Let’s help all product teams to see what we are creating by sharing the information in one common place – One Location.” – Jiri Mcc, Greenwich 

Let us know at @designatscaletm
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm

March 25, 2020

Impact of File Naming Convention on delivery

Welcome back; this article is part of the series called Naming convention.

The previous article explored the history and mental models behind sorting information in digital space.[001↗] This article aims to discuss the naming convention of our files spread across drives or remote places. 

Environments 

The remote world eventually moved our internal naming convention from local hard drives to a public space. You name it – Miro, Slack, Google, Microsoft or Figma (or Sketch). Every boss, product owner, human resources or developer knows what we are and how we orchestrate our designs in the company we work for. 

“The messy team equals messy structure, resolving in a messy product or service, period – there is no science about it.”

–Jiri Mcc, Greenwich

The good thing is if you are really organised, the impact is imminent. Upon gaining the respect, you also broaden your influence that could easily expand from design to business and development. 

There is a silver lining between imposed file naming convention and a carefully crafted one. Do make sure you work with your development team first to align on the basics of how the names work in their specific world and how we can make them more prominent in our designs.

Figure02: A made-up naming convention for this article reflecting the topic 

Acronyms 

The red flag goes with making everything an acronym or abbreviation – 

even though it can be very efficient once embedded. It also has to be digestible to a broader audience. So if your team serves cat food in your company, you don’t have to call it “CFC – Cat Food Company”. 

The challenge with some acronyms comes with an ambiguity of the meaning. Once, on a project, we had the acronym CWA. It meant four different things – you most certainly want to avoid that.

Figure03: Detailed explanation.

Method

I have settled on the following. Call me old school, but I have crafted the structure and naming convention since 2000, and now this effort massively pays off. Throughout and after finishing the projects for a specific client, I’ll rename and adjust all the files for easier and smoother access later.

Year 

The first part of the file is the year - in the format YYMMDD. This allows me to have an understanding of when the file was created or when it was shipped. 

Some of my folders start with the year, for example, “Y22 TCN SOW,” which tells me everything I need to know about the Statement of Work (SOW in short) of specific clients in that year. 

Question: Why don’t you use YYYY? Because we’re at the beginning of the 21st century and no one will ever look for the files from 1982 that need to be integrated into the following release. So, I shortened it for YYDDMM (220217, for example) and used folders that start with /Y22 (inherited from old-time coding).

 

Project Name

Project names are abbreviated or shortened to three letters. Having a project name defines a specific piece of work for one client. Now in the corporation, it can go as complex as: 

client “TCN”, 

transformation name “TSN”, 

Project Name “PRN” 

This allows me to distinguish between different projects in the same transformation initiative.

 

Release (aka. versioning)

Although not previously common amongst designers, one thing we’re seeing more often are the release names Alpha “AL”, Beta “BT”, Candidate Release “CR1.0” 2.0 and so on. That allows me to ship specific versions to specific developments and releases. It allows designers to work on two releases simultaneously without missing the death line or mixing the assets. 

Design System

We are all on the verge of design system expansion. Everyone talks about the colours, pallets, and tokens. Very few articles debate the point of versioning and different releases, rebranding and international design system supporting multiple markets with LTR & RTL UI, etc. 

Since the early days of design, I’d always include the name (or an acronym) of the Design System (later referred to as DS) – at Sky it was SKYOS1.3, and in LloydsBank, it was Constellation Co1.0 showing the DS and the version. 

Figure04: The convention accessibility via multiple touch points.

Accessibility

All the above leads to broader accessibility amongst files that use the same naming convention across the business and development. 

Anyone in the same unit or transformation is aligned with the product team by locating files on the server, in Jira, Trello, dropbox or Confluence. This saves 32% of productive time (Assuming all participants agree on the naming convention, respect it, embrace it, and maintain it).

Figure05: Scaling the naming convention across different touch parts of the business.

Scalability 

Establishing straightforward guides about the names allows teams to franchise this thinking and move beyond one team or team. It inevitably empowers department units that deal with a vast amount of data – like research, insights and copywriting. 

As of now, three documented case studies represent an infinite scalable model allowing designers to simply start the file from the master and link all design systems – DS into a project file. Once executed, the file can be translated to a prototype or production file from SD to CX to UI assets. 

Adoption

I can not speak for Sketch and Abstract as I haven’t tested them thoroughly; the convention's adoption was swift regarding Adobe (/Y00-18) and Figma (/Y16-22). It also plays in various technical environments – such as broadcasting, finance, trading, and aviation.
(Feel free to add your question or DM me for more details)

Figure06: An impact of the naming convention of the team, department and business.

Integration 

One of the main advantages of our naming convention influenced (or defined) by design is the broader integration beyond the design function. In six months, we have started seeing product owners start using the same formats for their PPTX and our Confluence and Jira structure evolved to the point of a unified “Knowledgebase” – the result, everybody can find whatever they were looking for. 

Figure07: Where Next – How to ask the right questions.

Where next 

We’ve got the primary, not rocket science, here: As a genuine note, try to look at your current folder structure and ask yourself the following questions: 

1/ Do you know what you are looking for?

– Specific design
– Version
– release or iteration. 

2/ Do you know what are you opening?

– if you are certain it saves you 23% of your time if not it burns you 49% of your time
– Visual Search is 30% faster than word /read search. We have specific tiles that allow us to know what is inside.

3/ How do you link/update your files? 

– Having smart objects (Adobe) or design system (Figma), where is your library?
– is that a unified and centralised place or is it well redistributed?

4/ How many people working on one file?

– One 
– many (if many who is the owner of the file)

5/ Do you the status of the file?

– Draft
– Work in progress 
– DOR – Under review 
– DOD – Delivered (aka final sign-off version)

Let us know at @designatscaletm
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm

March 20, 2020

The power of the naming convention

We’ve all been there. Someone, most probably a boss, ask us to find the latest email or miro[001↘︎] board or simply share a file created a while ago, and we struggle to find it. 

Where is it?
How do I find it?

How was it called again?

Perhaps it was <final _final _RobertsFinal _shipping _version _final.ext> doesn’t make sense to anyone who didn’t specifically work on it. 

Situations like these are not rare; after observing studies describing different lenses where people struggle to locate their pressure assets in various business functions[002↘︎], I become curious about what techniques can shift this paradigm. And we all one day find what we are looking for?

In other words, how do we navigate within inherited naming conventions or structures? 

What other methods can we apply to reach the desired outcomes?

Is the search the ultimate answer to file location? (especially if we do not know what we are looking for)

How can we choose an approach for the naming convention as a team, department or business that scales?

The following four articles aim to set basic principles that help us organise our world of digital assets in whatever structure we find ourselves in. Equally, draw some lines on what to control and what to ignore. 

Let’s talk about naming conventions.[003↘︎]  

“IDC estimates that an enterprise employing 1,000 knowledge workers wastes at least $2.5 - 3.5 million per year searching for information, failing to find existing actionable information.” – IDC Survey (2020)

To understand the challenge better, we need to rewind a few centuries to understand the basis and implications of how we all got here.

Figute02: Bookkeeping 

History of bookkeeping

Luca Pacioli [004↘︎], the Italian father of accounting, is the first to mention double-entries in bookkeeping and complex naming structures. He introduced a new structure for identifying, recording, and archiving the item for future reference. 

As accountancy evolved over the centuries, single books became books of books, and information grew with a need for another approach to filing complex things. More than the record itself, this was about the mental model [005↘︎] of how complex accounts were recorded and inevitably linked together to track the obvious – the monetary value of subjects.    

Figute03: Alphabets and Numbers 

Alphabets and Numbers

Using numbers became the easiest way to sort things out and give order. (1, 2, 3 and so on, where 1.1 defined the substructure of 1.0). [006↘︎]

Early alphabet systems enhanced the naming convention with 0-9 and A-Z combinations. This allowed us to scale and have more complex numbered systems. Consider health records in the early 20th Century. People signed boxes with the letter A and dividers with Aa, Ab, Ac, Ad, and so on[007↘︎]. Some letter-based filing systems[008↘︎] still exist and deliver value to small GP practices worldwide. 

Figute04: Cards and Boxes

Cards and Boxes

The physical experience of cards and boxes evolves onto the digital filing system. A progressive mental model allows the observer to navigate complex data structures[009↘︎]. This impacts how we see the data and recall information from our available data sources. 

When we need to control someone's data we haven't created, DropBox, One Drive, and Google Drive become increasingly difficult to use. Things can lead to 12 versions of the Friday PPTX stakeholder presentation scattered over 12 different drives, including a cloud drive copy in Slack and Miro. Let’s not forget Teams[010↘︎], either. We just need a link to a server where we can all contribute. 

Figute05: Naming Convention 

Files and Folders

I’ve experimented with thousands of structural models for labelling and maintaining directories. Those findings have been shared and challenged with businesses large and small (agencies and in-house) to find an optimal way to address physical and mental structures.  

“Don’t use this file; we haven’t merged it yet as there are some changes from the previous design system that we haven’t cleaned up!”   – Senior Designer, Banking Institution, UK 2022

The agency usually has PMs who decide, above anything else, the file structure and the rest of the team follows. As a designer, you remember to add whatever you create into folder 05. Design – and rest did not matter. Unfortunately, our Sketch[011↘︎] and Figma[012↘︎] files are no longer on the local drive; they are also in Cloud[013↘︎], Abstract[014↘︎], and who knows where else. 

Arriving at a design team of 50+ people in business units serving three propositions might be a particular challenge where no one owns or updates the design system. And in particular, where no one looks after naming conventions.

Environment

That brings us to the final point, a mental model that can be applied across folders, file layers, and even your email. 

The method is called 3x3 [015↘︎], which describes the human pathways and how we focus and sort a piece of information in pressured time.

We create three “3” mental areas (before, during, after). We used to have folders like IN, WORK, and OUT at the agency. The continuous incremental delivery and versioning challenged that structure ultimately. 

The mental model stayed the same. We still have “before” (research and analysis). We all know the “during” (often translated as the process). And “after” (release and outputs), where we aim to achieve specific outcomes.

Where next 

The above is not rocket science: As a genuine note to all readers, try to look at your current folder structure and ask yourself the following questions: 

1/ Where does my data live? 

– one or multiple locations?
– if multiple, why is it?
– is it necessary or mandatory?

2/Do these places share the same structures?

– If so, can you (or your team) easily navigate?
– If different? (what is the reason behind that)

3/ How much time do you spend organising your data?
– Never (ask yourself how much data you carry that you do not need?)
– Often (how much time you invest and how much time you gain by finding the information quickly)

4/ How much time do you spend looking for the data?

– In your structure 
– In someone else's structures
– If different? (why?)

5/ If you were the chief architect of your data, what would you do differently? 

– For yourself? 
– For others? 

Let us know at @designatscaletm
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm

March 15, 2020

No time to name the layers

Welcome back; this article is part of the series called Naming convention.

The previous articles explored the impact of folder naming conventions. This article discusses the naming convention inside the CX and UI files before integrating them with our engineering colleagues. 

Why does no one care?

If you talk to any outside of the design practitioner circles, no one would consider naming layers or how the work is done as far as it is shipped. Often though, it is the fundamental difference between the practical (speedy, dirty, copy and paste) and integrated (well-organised, connected, regularly updated and automated) way that impacts the real world. 

You wouldn’t care how your herniated appendix is removed so long as the stitches are minimal. So the cavity operation is done by the first-grade surgery student where the private well-known plastic surgeon will carry your stitches on your tummy and final speech that you should be all ok. 

Fun aside, we often hear from our POs and PMs that no one cares. The agile manifesto says, “Working software over comprehensive documentation," making everything else disposable. If no one cares, why should you?

Figure02: Working software over comprehensive documentation

Should you?

In 1996, I was fortunate enough to work amongst some titans of retouching imagery in Photoshop 3.1.0 – I know, but I hear the story. 

We were preparing the imagery from the 96 Tour de France. Almost 10k images have been carefully scanned from original negatives (no DNGs or NEFs, no Lightroom) and are neatly organised in a magazine-led structure. Every picture was converted to PSD and properly layered out, so we can link them to Quark Express. 

There, I was told to: 

“Name the layers properly so that everyone knows what you have done and can read it as a message from the designer.” – Machacek, Design Director, Margaret Studio 1996.

Many times ever since, this simple practice saved me an excessive amount of time in production. It made me more creative when it came to further requests and changes. I could read and change layers and move objects and other parts of the layout without even looking at the stage. 

The argument I often have to prove is “if we do name the layers, it’s a waste of time to name it” especially if we delete them, right?  Sure, we waste more time copying and pasting instead of automating our workflow, which surprisingly is far quicker (about 63% on average) than naming layers properly.

Regardless, if you already name it, you know what you are deleting or removing, not even mention if it's a component from DS; it’s simple as switching off – you do not have to name it or rename it. 

Figure03: Smart Objects 

Smart Objects 

Fast forward more than a decade, Adobe introduced Smart Objects which allows embedded files and advanced versioning. While someone worked on the logo (in Adobe Illustrator), the smart object was linked (and rendered) into all Photoshop files and different breakpoints for desktop, tablet and mobile. We can then easily display different logos and different breakpoints. 

Equally, once the layer coms arrived, we organised our workflow with such precision that 40+ designers could simultaneously work on several PSDs without deleting anyone's work. Good old days when the collaboration had to be under control. 

It also showed when the design ops are done correctly; we can have a dedicated “folder” for all the assets that can be mirrored into a production line. Our engineering colleagues didn't have any questions about where the file or the graphic was or, more importantly, what the file's name was?

Figure04: Next Generation

Next-Gen 

We all very much embrace Sketch and Figma, but with the arrival of all the shiny tools, the legacy of structured design has slowly vanished. 

Having a chance to review some work across the large financial institutions in comparison to apprentice portfolios, the layering and the name Elipse 3975, Square 4598 and most likely Frame 19083 – which makes it hard to export group or groups or groups that logically or inherently belong to each other.

That said, several sources debate the challenge from the perspective of (a dirty) prototype which proves the concept of behaviour and function between work files with linked design systems and codependency between them.
(new article about naming layers in Figma)

Figure05: Design Systems

Systems

This brings us to the final point of naming convention and it's a convention of Design systems. Generally, I’d have one UI designer (or UX-er) running the work file and the other “design system designer” will run the design system file. 

With this approach, you simultaneously build a repository of your future implementation. With “variants” and “tokens”, you can really make something magnificent that is not only pretty but very functional and adaptable to your growing exponential needs.

Figure06: Automation and Algorithms

Automation and Algorithms.

I have to mention something that has been with me for quite a while, and only now are we seeing the first successful implementation of it –  it’s the automation and use of algorithms. 

Given the fact that Google releases new code every couple of seconds, it’s not surprising that design as a function needs to adapt to it. Navigate through the complexity of all your assets in each release, iteration and adaptation add to the complexity of your design ecosystem. Algorithms help you to correctly rename 30.000 elements in your APAC version of your software far easier than 30 designers would over a monotonous 10-day shift. 

Figure07: Where Next.

Where next 

We’ve got the primary, not rocket science, here: As a genuine note, try to look at your current folder structure and ask yourself the following questions: 

1/ What am I working on? 

– a very first iteration of the design?
– or a well-integrated piece?
– or something in between?

2/ Does it matters to me or to others?

– if it’s a singular file without possibility to share it, knock yourself out 
– if you share it make it count – it should be a story.

3/ When someone comes with feedback, listen?

– two things will happen 
– you’ll learn something new, which is always a good thing
– if it’s a critique of something, try to find a way to better it.

4/ Does it take too much time?

– if yes, you are doing something wrong.
– learn about automation and integrated (linked) design files.
– learn what to reuse and standardise. 

5/ Have one document messy and the very same one organised

– spend a day working on the messy one 
– and then spend the day working on the tidy one

Share your thought with us now at @designatscaletm. If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here.

Let us know at @designatscaletm
If you have any questions, please feel free to engage and open the discussion on Twitter so that the design community can learn from what we are doing here. 

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories: @designatscaletm
Direct messages: @designatscaletm

February 15, 2020

Research Section

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

This article will be closing the business pillar of three – Hello, Business and Research. The last section has the most significant impact on the design integration within the product team. This is where the business and the design glue objectives together under a well-researched and well-documented knowledge base that is accessible to the entire team 24/7. 

No one would disagree that well-made decisions rely on well-informed teams or individuals. And that’s where the philosophy behind 3x3 starts to resonate in full. 

“If a man does not know to what port he is steering, no wind is favourable to him.”  – Seneca.

Having a great design and development team means nothing if neither one of them does not know where they are going and what problem they are trying to solve together. And that’s where the research team and this section come in and define a powerful relationship that ties the business proposal with design ambition and development capabilities into something that is: 

  1. Achievable (Capabilities)
  2. Realistic (Business and Customer ROIs and OKRs)
  3. Measurable (based on realistic and measurable outcomes) 
  4. Releasable (Coded and Tested)

The research section in confluence structure includes all customer and competitive landscape analyses. Once completed, we make the most valuable decision for the product. Each department is accountable for its own contribution. 


As one CEO recently commented,

“No research and no understanding of the market means no right decision about direction and product itself”.

If there are no insights or initial landscape analysis, the product answer only the hypotheses of “what if” (unsure CEO) or better “I think” (dominant CEO), and both lead to more lavish spending, and waste of time and resources.  

Figure02: Product Landscape Analysis

What does the research section do?

The research section offers a knowledge hub of competitive landscape analyses followed by behavioural and mental models of existing and prospective customers. It also contains the test of early-stage prototypes analysing the appetite for certain features or desired behaviour. 

“How can we” (curios CEO) allow CPOs and their team to address specific challenges for the business or customer. This allows the having a unique lens for each problem and finding an appropriate solution to a very specific challenge. 

You might probably ask, “all the analysis and every week testing, how do you structure it?” The same as business section automation plays a significant role in this hub. Over a decade of testing and implementation showed the balance between “documenting enough(from the agile manifesto) more importantly “documenting what has an impact” (design at scale™ - reflects versioning, relevant data for design and dev sprints etc.). Several researchers confirmed that strengthening their knowledge of JIRA and Confluence serves well in applying their learnings directly to existing development. That’s why I became teaching JIRA and Confluence for designers, and that is where I gathered a substantial amount of feedback from the design and research colleagues that make this structure resilient.     

Figure03: Powerpoint

The research section does not.

As you can imagine, this clarity took a while; most businesses and corporations were afraid to let it go, the PPTX and Words and Excels from their own systems to really see the power of an integrated function of Confluence with JIRA in real product design development. Equally, the researchers who were fantastic with interviews and customers were not so tech-savvy with the technology  – our design courses change that. 

Even this section was a damp yard of almost 3000-word documents with different names, a person who did the interview not clear or fluctuating objectives for the research, legal management of the research data and so on. Not even mention the fact when the research was handed over from person to person, no one knew what was the action to take “what we have learned.”

Once the team invested the time in standardising these 3000-word documents, Confluence automation tools make this task really easy, engaging and quite fun for both designers and researchers. While our knowledge grew, and our impact strengthened as we started linking our findings directly to an Epic and User Stories. Suddenly our developers knew why they do what they do – it was not a change forced by the CEO or CPO it was a well-researched and documented reason for improving the product. And that’s where the dynamic of responsibility changed to accountability. 

From that day onwards development team required the research to be linked directly to their task – it meant that the User story went through the evaluation and the team is making the decision on real data and not on someones feeling – a practical example can be found as part of the DaS™ Courses. 

For more information, please join the Design at Scale™ Courses that explain the function, impact, and common pitfalls that can be avoided while implementing the DaS™ in your business.

Figure04: Structure

Structure

Let’s look at the Confluence structure in detail:

Business

1.0 — BRAND* Hello 
2.0 — BRAND* Business 
3.0 — BRAND* Research

Design

4.0 — BRAND* Content
5.0 — BRAND* Experience
6.0 — BRAND* Design

Development

7.0 — BRAND* Development
8.0 — BRAND* Releases
9.0 — BRAND* Integrations

I hope you’ve enjoyed the fourth article from 3x3 – Confluence for Designers. Please contact me at @designatscaletm to discuss this implantation in detail if you have any questions. The next article will focus on the Content section and all information-related integration of the copy function in this method. See you there.

Stay tuned; thanks for reading!

Thanks to all contributors, especially Matt Press, for their insight and comments shaping this very article.

Jiri Mocicka is a London-based designer, writer, and design coach passionate about Design at Scale. A flexible method that allows designers professionals to integrate the value of design within their organisation through transparency and well-communicated product design development.
Visual stories @designatscaletm
Direct messages and questions, please follow: @designatscaletm

Your Story
Matters.

Contribute.

We're sorry you haven't found what you were looking for. Let us know your story, and we'll ensure it's broadcasted to the world.

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