;

April 1, 2020

DoD — Check List for Designers.

Throughout the Design at Scale™ mentoring, I have observed little understanding of “the definition of done” among designers. It’s no wonder — in 2019 while working with 27 different teams, I asked what their Definition of Done (DoD) is and how the design represents itself alongside other disciplines; the answers were shocking.

Before we dive into details, fun facts and the bitter truth, let’s cover the basics of what the DoD in Agile development stands for.

Definition of Done is an agreement on which basis the Scrum team defines the optimal software development deliverables to be good enough.

I ask all the Certified Scrum Masters in my circles what the DOD checklist is. (specifically including insights, research, testing, customer experience and User Interface design).

To my surprise, there was no appreciation for the continuation of sharing knowledge beyond delivery. And as the design is not considered part of working software (for many companies), carrying this information from release to release and other iterations that might benefit from such knowledge is not indispensable.

Figure 02: Checklist illustration showing three columns.

“Most fear is just bad management of our own mental faculties.” — Brendon Buchard

Why do we need the DoD Checklist at all?

Definition of Done

Simply put, every team member should understand what “done” really means in their area of expertise. The work in Agile teams is based mainly on mutual trust between team members nowadays distributed in different continents, time zones and systems. Therefore, having the exact definition will be (without additional verification) a precondition of a successful contribution. When a specific thing is marked as “done”, all parties accept “a good enough” increment that allows the following Contributor and Product Owner to proceed.

Checklists for User Stories and Sprints help us stay productive. Each member needs to have great tools to boost team productivity. Of course, even the best document is not a substitute for good communication within the team. However, we should use every possibility to make our process easier and more transparent, and the DoD Checklist is one of the best ways to do that.

“Doing things is not the same as getting things done.” — Jared Silver

An example of Design at Scale — DoD

When we decided to create the DoD in our company, we put together “a shortlist of areas that we should own and control to deliver the highest possible quality software”. We created two checklists that help us verify our work on two stages of the software development process.

Figure 03: Example of the user story checklist

1. DoD checklist for a user story

Product Focus: Let’s begin with the elementary increment of any product delivery. The single User Story contains user (customer) requirements and initial assumptions combined in a single backlog item. Thus, we do not control only the quality of written code but also the quality of the elements that define our process from end to end.

Business:

  • Does the story describe the user’s desired behaviour?
  • Does the behaviour represent the customer value proposition?
  • Can we monetise the behaviour and improve the customer experience?
  • Have we produced the desired experience?
  • Are we helping the customer to achieve their objectives?

Experience

  • Do we communicate the right message CTA (Call to Action)?
  • Do we have the right tone of voice?
  • Does the user understand what is expected from them?
  • Are we using consistent Design Language across the proposition?
  • Do we have a Design System or equivalent?
  • Does the Design System reflect the equivalent in the FE code?

Development

  • Have we produced the code for presumed functionalities?
  • Does the QA pass without errors?
  • Were the unit tests written and passed?
  • Was the project deployed in a test environment?
  • Was the project tested on devices/browsers listed in the project compatibility requirements?
  • Was the QA (Quality Assurance) session performed and passed?
  • Was the documentation updated with the latest status link to Figma, XD, etc (if it exists)?
  • Was the PCR (Peer Code Review) performed?

This creates a balance between all parties and reduces the tension especially between remote parts of the team.

Figure 04: Example of Sprint Checklist

2. DoD checklist for Sprint

Process Focus: In the following stage, we decided to control Sprint outcomes. The checklist can easily represent the team workflow. Now the entire team can see if all the implemented features fulfil their original requirements and pass the acceptance criteria.

  • DoD for the Customer
  • DoD for the Business
  • DoD for the Experience
  • DoD for the Design
  • DoD for the Development
  • DoD for the Release
  • DoD for the Integration

“… under conditions of complexity, not only are checklists a help, they are required for success.” — Atul Gawande

Figure 05: final.final.suer_final.cluent_fina.pdf

Fundamentals

At first glance, it might come across as overwhelming. However, in software development, a well-orchestrated Definition of Done can make a significant impact. Not only on the daily interactions and communication but also on the product being delivered on time and accepting all industry criteria.

DoD’s decreases miscommunication within the team or team of teams mainly when all members have been equally spread across different time zones. This avoids verifying the work several times and reduces the conflicts arising from missing information or clarifying the proposition. As a result, team members can now finally build trust in the form of tribes.

Business

Well-defined DoD allows the business to reduce time to market and prevent unnecessary spending on something that will never see in the hands of real customers. Well-implemented DoD in your Product team can make up to a 30% impact on reducing code refactoring and the time to market, including the cost of the project in one go. Inevitably DoD improves the overall team communication whether you sit next together or in a different continent or country. Precisely defined criteria prevent the team from conflicts arising from misunderstanding and the inevitable creation of silos. All the above makes the average team a better team.

Creative

Well-structured DoD allows creative teams to share a vision in a safe environment and invite everyone to review never-ending interactions of prototypes without ever facing adverse reactions. Inevitably it will enable the discussion about design in progress or done, which is a more significant challenge for every Product team. And last but not least, it allows the design teams to work in a more exploratory way where the increments are done in a more centralised manner.

For example, while delivering a set of buttons, iconography, colours or responsive image definitions in one go, the development team works without changing their own ways — more on this topic in Dual-Track Agile article.

Development

And finally, the DoD represents the safety of the development team. To mention just a few, Reza Mehman wrote a Checklist, “Proof of Concept”, that looks into the definition of done for proof of concepts. The ProductPlan startup has written a very good article about their “Definition of Done” from the development perspective that’s definitely worth reading.

To Avoid

However, we must be careful. Too detailed DoD Checklist could lead to wasting huge amounts of time on unnecessary formalities. We must also remember that this document is not a cure for all the problems, tensions and challenges.

It can’t replace good team communication nor precise function requirements. But, if it is a part of a well-functioning process, it could resolve many problems and help save a significant amount of time for something more pleasant than overtime work.

Final Check-List

What are the benefits of a checklist in the user story and the sprint?

Customer Lense

  • Customer-facing improvements — a statement later used for initial pitch and further project direction.
  • Process-based improvements — helping us advocate for the financial impact of the product or service.
  • Service-based improvements — influence, trigger, activate and reward the user for their loyalty.
  • End2End improvements — simplifying the proposition into one diagram allow the business to visualise what has been forgotten or misused.

(Please visit the resources below for detailed info about this topic)

System Lense

  • Service level requirements — definition of SLA
  • Functional requirements — Consider all disability factors.
  • Interface requirements — Overall accessibility, including the colour, button and UI size animation etc.
  • Security and Compliance requirements — Legal and Risk
  • Architectural constraints — This refers to technical architecture.
  • Operational and Migration requirements — not only if you’re considering moving from one system to another.

(Please visit the resources below for detailed info about this topic)

DoD–Checklist for the Prototyping (POC) Phase

  • What problem does the POC solve?
  • Innovation vs Invention — understand the difference?
  • Who is the target audience, and what are the main characteristics?
  • What is the unique selling proposition?
  • What is the product or service strategy for the next 1–3–5 years?

(Please visit the resources below for detailed info about this topic)

DoD–Checklist for a user story

  • Is the User Story verified?
  • Have the build & tests been confirmed?
  • Are the assumptions met?
  • Have the project build and unit tests been written and passed?
  • Is the increment deployed on the production platform?
  • Can we test on devices/browsers?
  • QA (Quality Assurance) session performed + resolved?
  • Is the refactoring completed?
  • Is the configuration or build changes documented?

(Please visit the resources below for detailed info about this topic)

DoD–Sprint

  • Better team communication — CPO® planning and update
  • Standardised process and operations — CSM® reviews
  • Better task estimation — Duration, Prioritisation, Impact
  • Better R&D flow — Integration of test result
  • Contextual Experience — Behaviour achieved
  • Integrated Design Framework — All bugs fixed
  • Software quality assurance — QA and Refactoring
  • Less refactoring — Deploy and test on the production platform.
  • Well-tested features on each release — Product backlog updated
  • Smoother Integration — Sprint marked as ready for the production

(Please visit the resources below for detailed info about this topic)

Resources

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 writing about his passion for Design at Scale — integration and design operations that builds excellent digital products.

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

March 12, 2020

Integration Section.

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 and smooth design delivery.

This article aims to address the most overseen part of our operational presence and the inevitable future. Our products and services are constantly connected and integrated with other products and services, consuming each other's data, commands, and interactions. The complexity of these connections has become overwhelming and sometime misunderstood. 

Let’s take a fashion retail startup as an example to explain what the integration section can offer to your team and business in the most simplistic way.

Figure02: Integration Layer

What does the Integration Section do?  

The integration section looks at the company ecosystem.

In the Hello [001↘︎] section, we have discussed ways of working which reflect the Google Workspace with drive, sheets, documents, mail and presentations in one ecosystem. Followed by Slack, Messenger and Teams as they collaborate with bigger brands who use the Office365 package.

In the Business [002↘︎] section, we look at the software for resourcing, HR  and accounting – let’s say FreeAgent [003↘︎] or Xero[004↘︎]. Followed by the legal software managing their T&C[005↘︎] across multiple countries. That comes down to fulfilment centre software [006↘︎] that operates their livestock.

For the Research [007↘︎] section, they use TypeForm for surveys[008↘︎] as well as Qualio [009↘︎] in combination with Google Workspace.

When it comes to the Content [010↘︎] section, they use Google Documents in combination with Shopify [011↘︎], which is problematic from the versioning perspective that it already makes their business less adaptable. 

In the Experience [012↘︎] section, they are more fortunate as this also combines the Design [013↘︎] section. After Trying out the inVision[014]↘︎, Mural Board[015↘︎] and miro board[016↘︎], they settled on Figma[017↘︎] offset full integration with their project management tool.

The Figma plugin allows them to export all media platforms as the Marketing Management Tool [018↘︎]. Klaviyo [019↘︎] with integration to Shopify [020↘︎] offers a simple yet effective combo to run and scale from 10 - to 10.000  products without massive overhead. 

This brings us to Development [021↘︎] park, which is solely relying on Shopify and Vercel integration with 3rd parties API. 

Last but not least, the Releases [022↘︎] section is driven by Asana [023↘︎], which is fully integrated with their App and online store etc.  

This is just a glimpse of what simple business these days needs in order to survive and thrive in the era of digital scale. And staying on top of the all integration one startup must have is quite a job if you do not have a dedicated Dev/Des./Biz. Operation person you need, you must have this section – for your own safe and secure integration with other businesses.

Figure03: 80/20 Information Ration.

The Integration Section Does not include.

Apart from the obvious, this section MUST NOT include any password for any services that the business holds. This will jeopardise the safety and security of the team and all customers using the product. 

That also applies to any customer data. For that reason, the Copy team developed a list of 30+ random profiles reused in visual prototypes and so on.  

The Integrations section SHOULD NOT include a print screen of the service and its settings. Yet, in some cases, if you run your server, you can have a fully comprehensive manual on how to set things up – only what is reported to the product itself.   

Adding or removing the note has to be approved by the team. Approval systems for SLR were mentioned in the Development section [024↘︎] 

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 final article from 3x3 – Confluence for Designers. @designatscaletm is open to all your related questions about the 3x3 method or any other topic we are discussing 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
For direct messages and questions, please follow: @designatscaletm

March 10, 2020

Release Section.

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

This article will be addressing the trsnaprency within the team as well as outside by automating everything we have just discussed and in previous secions – Hello [001↘︎], Business [002↘︎], Research [003↘︎], Content [003↘︎], Experience [004↘︎], Design  [005↘︎] and Development [006↘︎] sections combine here in Release [007↘︎]. 

To recognise here is to see this all as writing the right story; according to HBR’s [008↘︎] Leadership Legacy book [009↘︎], Robert Galford[010↘︎] and Regina Fazio Maruca provide a disciplined approach to framing the legacy by focusing on right actions as well as shaping it over time. Instead of hunting the deliverables, goals and deadlines to the point of crisis, Your Leadership Legacy enables you as leaders to craft your work and build the legacy under the premise of group experience rather than personal satisfaction. 

The Release Section focuses on the transparency, community, ain inclusivity of people's terms. It invites everyone to consume, some to react and very few to act – the mental model of the decision-maker, influencer and doer.[011↘︎] 

Figure02: Image

What does the Release Section do? 

The primary purpose of this section is to provide an overview for all non-JIRA savvy designers, business people or anyone else outside of the team unit and be able to see and contribute to the course of the outgoing delivery.   

Outside of Business and Experience pillars, the essential part of Confluence is the automation and beauty of intertwined, co-related pieces that create a holistic overview. 

Looking at the 17 years of my history with Atlassian for the first six years, this section did not exist. I was reporting above, but I do not need to communicate elsewhere. 

With an increasing need for performance monitoring in JIRA, and incapability (or no need of control) of some members, this section becomes a monitoring hub for all releases. For less mature teams, we created a single destination that unifies the ultimate picture in the most digestible ways possible. (Upside; no one has to visit JIRA anymore – that was a revolution for some stakeholders)

Rather than communicating different boards and search parameters, We created the Release hun that contained the pages like MVP, Alpha, Beta, CR1.0, CR2.0, etc., where each release has a list of Epic and User stories in the form of a list. For a couple of years, this has been an imported excel table to Confluence. Still, now it’s an interactive, well-intagrated part of JIRA populated specific way so that observers can see only what is related to specific releases. 


Each version (less complicated in the beginning and more complicated in the end) has a defined structure to help observers navigate and act on things in their remits. Instead, everybody is trying to do everything. 

Structure:
/ YYMMDD MVP Release
/ YYMMDD Alpha Release
/ YYMMDD Beta Release
/ YYMMDD CR1.0 Release
/ YYMMDD CR2.0 Release
  / HLR
  / Release
  / Bugs
  / Resources
  / Budget
/YYMMDD CRX.X Release 

The structure above represents each release and substructure part of the specific release. 

HLR – I tend to include the page with HLRs for two specific reasons. A/ simple copy and paste for any stakeholders who might interact with the team, and B/ easy to track the original assumption and agreements against the reality. 

Release – is a script looking at the specific release through which we can display Backlog, Planned, In Progress, and Done.
(For more complex release solutions, please DM me) 

Bugs – having bugs on a separate page allows anyone to see the challenges in a straightforward overview as the dashboard instead of looking for them in between different tickets. This allows the designers to see what needs fixing in the design world and what needs to be fixed in the dev world. Very practical page, especially prior to release. 

Resources – mostly applicable for bigger teams as I’m seeing different budgeting and resource software where everything is here in JIRA + Confluence. Reporting at a glance of how much time we have and how much time is calculated for the delivery dictates the resource needed it. 

Budget – as with any work, we need to understand how much we burn and what we deliver. Velocity diagrams are good, but I found burn charts even more practical, especially advising StartUps.     

As a caveat, once the release is closed (fullfiles DOD and all QA) pushed live, we reprioritise the following disclaimer and optimise for the next significant drop. This allows designers and developers to add what we have missed in terms of monitoring and adjusting the view for specific stakeholders. Finally, the page with all blockers simply highlights the obvious–what needs to get fixed before the release.

Figure03: Image

The Dev. Section Does not include.

Apart from the obvious, which is static information and form of documents that are not in any form related to the delivery, this section has no downside. As its fully automated, it either exists or not.

The only thing that could go wrong is that someone with admin right changes the JQL [012↘︎] script and jeopardises the algorithm that sorts the search parameter. Other than that, all data are driven by the JIRA. If people correctly move their tickets from ToDo to In Progress and Done, nothing affects the outcome.  

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

March 10, 2020

Development Section.

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

This article will be opening the third and last pillar that utilises – Development [001↘︎], Releases [002↘︎], and Integrations [003↘︎] sections, building from what we have discovered, acknowledged, redefined, tested and designed to this very point.

“Documentation is like sex:
when it’s good, it’s very, very good;
when it’s bad, it’s better than nothing.”

— Dick Brandon

Every product team aims to empower developers to deliver well-written code that is easily deployable. The focus here is on the handshake between these two different functions and mindsets that neither one wishes to document.

In the same way, as the Design or Experience section is design-led, the development section has its specifics. Especially when it comes to setting up the environment, listing the APIs or reporting the releases in one place – every team I have worked with has a different method how documenting code. 

Note of the author: Please acknowledge that the fact that whether I can read the code does not make me a developer. I have been fortunate enough to work with some very talented people in the industry who positively influenced my perception of how best we all can collaborate together, and for that, they have me undivine respect. The following is just a glimpse of what the unified knowledge base could become.   

Figure02: Double Diamond Is part of every successful design delivery.

What does the Development Section do?

This section is about the development and how the entire thing is set up. Starting with High-Level Requirements – HLRs[004↘︎], System Level Agreements – SLA[005↘︎], TDD[006↘︎] or BDD[007↘︎] agreements in place and technical parameters for each release.
Many development teams came to me throughout the years and commented on the structure. Sharing their ideas and insights would help them to be more connected. The majority of them were amazed by the level of consideration of all disciplines and the transparency model between them using my advice and previous learning. Document resources, APIs, calls, scripts, security protocols, databases, and even linking all notes from BitBucket or any other code repository – all well automated with algorithms to reduce the complexity of documenting and sharing.

Structure:
/ HLRs – DOR, DOD etc
/ SLA + SLR ≠ System Diagrams
/ iA + Task flows
/ Backend – Vercel, Google or Azure settings  
  / BackUp notes (automated)
/ Front-End – testing mirrors and
  / Release notes (automated)

The overview of the section starts with HLR [008↘︎], which defines the project or product. That also set’s the tone for what methods and routines are used—listening carefully to Product Owner – CPO[009↘︎] and Scrum Master – CSM[010↘︎] makes a massive difference.

“I often advise designers to question everything in this stage as its defines how well they are integrated within the team.“

SLA[011↘︎] + SLR[012↘︎] – for non-tech led designers, SLA stands for  System-level agreements. I encourage my team to read these documents to find out how best we can solve the customer problems by understanding these written definitions.
iA[013↘︎] – previously mentioned in the Experience section [014 ⁇ ] has a different meaning in the development world. I’ll encourage you to run this test as a maturity evaluation of your team. “Ask each team member what is the definition of Information Architecture – in other words, what do they mean if they mention iA to someone in the team?” [015↘︎]

Back End – is all bout the logic and how the entire system works. Whether you have a full-stack developer (doing pretty much everything) or a dedicated team of backend engineers having a divided subsection is good for understanding what happens behind the curtain and what you can influence. 

Front End – I’m seeing FE Engineers more like Creative Technologist [016↘︎] nowadays. And therefore, their world is very much linked with ours, which makes us integrated from the very beginning of the project. This makes their reporting / documenting slightly more manageable as they have full access to our work which they can and should reuse.

Above all, the section must include links to real code examples, features, prototypes, and versions to document and see the progress of the real invention – the latest iteration of the product or service we are currently building.  

Figure03: We never discussed the double diamond method as is not relevant to product delivery.

The Dev. Section Does not include.

I’d like to take the opportunity and talk about a particular challenge in documenting, and it's the language barrier. Most of the time, poor documentation does not mean poor language (in our case English).

Millions of designers and developers are not native speakers, even more, native writers. As it is close to my heart, I have wrongly avoided it too, for some time. I was afraid to describe the functionality because I had no extensive vocabulary to do. Even more, learning English through French as Czech gets even more confusing. Despite my insufficient vocabulary, I always wrote simple notes next to each snippet of the code or wireframe I made. And that’s how I got better. 

I was part of the remote development team and had profound resistance to documenting anything – not because there was no understanding or knowledge. They are tremendous backend developers with extensive knowledge in data migration at scale. Yet, describing what they have done in English becomes extremely challenging, if not traumatising. 

My approach to such a challenge the team was to divide the problems into two categories. Things that happen and can be automated and therefore communicated without extensive description – were a significant win. The team put themselves forward to find appropriate JQL – Jira Query Language [017↘︎] and automate the hell out of it.
The second part took longer, and it was worth every minute spent on it – as it made the entire team closer. It encouraged writing simple notes about what was done and how to extend the note, what needs to happen, and why. Soon enough, we have snippets (in other words, paragraphs) that other team members like BAs and CX designers can take and amend in no time and start building a so-called knowledge base. 

Reaching sprint 6 (week 12), we gave the team comprehensive documentation between three continents, timezones and languages. 

Three things happened:

Well-diverse teams were now glued to the one source of truth, which reduced the communication overload on other channels and focused on the knowledge base. 

Simultaneously, the team saw that the knowledge base saved their production time. They were not forced to look for the information further and started building interest in documenting exclusively as a part of their daily routine.
Followed by the celebration of the first release, all members agreed that we reduce meetings to 5-10 min catch-ups in the morning (StandUps) and evenings (DropOffs) where each developer presented what has been delivered – the increment [018↘︎]

This creates a set of new challenges, but every business wants to have these challenges – engaged contributors strive to deliver their best without ever feeling not enough concerning their location, language barrier or outputs.

Quote

“We can easily forgive a child who is afraid of the dark; the real tragedy of life is when men are afraid of the light."  – Plato

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 fifth article from 3x3 – Confluence for Designers. @designatscaletm is open to discussion about detailed implantation. The following article will focus on the Release section and all information related to tracking, ever seeing, and maintaining transparency.
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
For direct messages and questions, please follow: @designatscaletm

March 5, 2020

Design Section

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

This article will be closing the Design pillar of three – Content [001↘︎], Experience [002↘︎], and Design [003↘︎]. This section has the most significant impact on the design integration within the product team. Here is where the design is correctly translated and paired with business objectives under the umbrella of a well-integrated design system well-documented rationale behind the design implementation.

“The purpose of the design section is to communicate design artefacts in a non-visual way to the wider community of professionals that uses the design outputs to generate the meaningful outcomes for the customer in the broader context of the business.”  – Jiri Mocicka, 2016 – Sky

Does it mean we need to copy our drive or export every iteration into a separate PPTX and then upload it to Confluence so that everyone knows what we are doing? 
Of course not. In the world of automation, scripts and algorithms are designers' best allies. To automate your daily routine, report less than 5% of your productive day (roughly 20 minutes). In comparison to hours spent on Slack to ask the most obvious question, “where is the latest screen?”

Especially when your design software is integrated with the company software ecosystem. Remote drive for daily backups, your screens are integrated with JIRA (or any other project management tools), and your work (Figma Boards) is linked to Confluence (or any other form of Wiki) to keep your colleagues fully informed. Then and only then, you focus five hours a day on creation.   

Figure02: Design Section.

What does the Design Section do? 

Structure:
/ Brand Vision
/ Brand Strategy
/ Design Principles
/ Manifesto
/ Brand Bible
/ Design System
/ Feature List – feature 01, 02, 03 etc
/ Component List – component 01, 02, 03
/ Product
  / Alpha – Release 
  / Beta – Release 
  / CR1.0 – Release
/etc.  

As you can see from the list above, the first item is the Brand Vision – every product or service must have a brand vision. Millions of designers move objects on the screens and ask your customer what they think and do not understand the Brand Vision through the research. Make all the information tangible, descriptive, easy to digest, and qualify. That way, your team grows wiser and makes smart decisions.    

The same comes down to Design Strategy – how is it manifested internally and externally, and how does it affect the team and the product. The more specific you are in your definition better the outputs will be produced (not necessarily more), and desired outcomes will be achieved.
Design Principles align with CX principles – one that represents the desired behaviour (an action) under the emotionally led connection (expression or need). Inherently it focuses on principles defining the experience and overall guidance for the product. Interestingly enough, some proposition does not see it as vital to creating or having one. When asking different team members what the product stands for, I usually get ten different answers–go figure how these teams can even make it to actual release.
Brand Bible – replicates what the static predecessors did. Only in digital, live, constantly evolving form that is completely intertwined with your future product. Several companies have their own bespoke solutions and one that chooses to be fully integrated with other providers. The choice is yours. 

Figure03: Brand Bible is not about colouring in.

Design System – most (none) designers think of the design system as a sketch file that orchestrates the rest of the files. Where in fact, the Design System is a logical response to a complex landscape of requirements and objectives in a visual form that is fully integrated across the business to deliver consistently and well thought through outcomes.
It has never been and design thing only. 

Feature list – looking into the last state of the feature and its functionality. Let’s take the login feature as an example; the logging seems different in different releases. Supports other APIs and security protocols, integrate with different SSOs and evolves in UI. That’s all documented in “words” in the feature list.  

Components List – This is a little easier as it represents the Design System. This part can be automated and changes less frequently than the above feature list. Think how many times you change the default button? The Component list, once created, can be maintained with little effort. 

Figure04: No assets delivery available

The Design Section Does not include.

Simply put, the designers do not like documenting. Therefore anything around documentation is quite a topic for more excellent debates. However, every designer expects other disciples to document so that we all can work simultaneously together – what a naive perspective, don’t you think?

Historically we have had PSD’s, AI’s, FireWorks, even InDesign files, and later Sketch to the least Figma. Outside of Figma, all the design apps carried out the challenges with versioning, and assets management, including measurements, just to name a few. (For those interested in running the documentation with these dinosaurs of the design industry, drop me the DM to discuss it separately – still possible if there is a discipline). 

Three main pitfalls of using the design section for: 

Asset’s delivery – With the arrival of Figma and the capability to share individual pages/views, it is relatively easy to document an entire pattern library in a few weeks. This completely cuts the middle man and the delivery of the assets in scale – while dealing with different language mutations, releases in different markets and content updated at the same time. Equally, delivering assets through any project management tool, including JIRA, is definitely NO.  

Comments on Design – Equally, the comments on design moved from inactive to active places. Even though I see some traditionally set up companies still working in Sketch, Figma exporting a PNG and uploading on to an inVision, or miro to gather feedback from the team. This means running two software versions and two different places for comments, which could quickly multiply with Slack and three stakeholders giving additional input in other areas. 

Figure05: Communicating design

The ultimate destination for the product – the last and the most concerning pitfall is to overpower other disciplines and make the design section the most prominent. While this creates tremendous pressure on the design, the other disciplines stop contributing because the design always tent wins. An unhealthy dynamic leads to a derailed team and a lousy products in the customers’ hands. 

In this case, everybody loses as no one really plays the part of building common knowledge with their peers. Design as a visual discipline should support all the others – to create diagrams, charts, reports and so on.  That’s how you make the transition between all other departments and glue them together. 

The design's biggest challenge is that it thinks it is in the centre of the business where in fact, it is in the middle of the process that makes the company the centre of excellence.   

“Don't confuse legibility with communication.“ – David Carson 

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.

Figure06: 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 fifth article from 3x3 – Confluence for Designers. @designatscaletm is open to discussion about detailed implantation. The next article will focus on the Development section and all information related to coding, deployment and versioning.
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

February 25, 2020

Experience Section

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

The experience section helps synthesise the knowledge from – Hello  [001↘︎], Business [002↘︎], and Research [003↘︎] in one place, expanding the footprint of the design team and creating a better connection between disciplines and departments that wishes to consume or interact with such information.

“The ambition here is to create an up-to-date, transparent, flexible and easily accessible place that allows the entire team to connect and stay in the know.” – Jiri Mocicka, Sky 2012

For some teams, the experience is everything, yet very few teams protect and leverage the power of the commonly shared knowledge. 

Figure02: Experience Feed Station

Before we dive in, it’s important to say that the first three sections are the feed station for the other three sections to come. Think of the first three sections as a shopping basket that you can constantly access for the information and wisdom from the original idea of project initiation. Everything that happens in Content [004↘︎], Experience [005↘︎], and Design [006↘︎] sections is transformed through the design process to represent the future state and its iterations. 

Figure03: R/GA

More than a decade ago, the titans of the R/GA UK Digital Innovation Agency of the Decade[007↘︎]  – as many other agencies of that era, produced a tremendous amount of detailed documentation in PDFs.

Our motto was: 

“Clarity, precision and strong point of view.”   – Ilia Uvarov, VP, ECD of Design R/GA

The ambition went beyond the current need for documenting behaviours, navigation and behavioural models. It created the backbone for the project, management and the team to follow in times of resonance and despair. The clarity achieved by the structured document allows everyone to start from the same page. Precision in documenting every ambition made the R/GA outputs one of the best I have seen in over 20+ years of practice. The strong point of view communicated in such an organised manner made the RGA interaction team the best. 

The scale and constant changes (client feedback and iterations) inevitably build the pressure between producers and interaction designers who tried to stay on top of the complex (technically speaking) documentation representing simple (profoundly well thought through) model for the product or service.

And that was the point where the agency and product team thinking divided. Despite progressive thinking and fast adoption culture, our debates about a less attractive and more functional approach were impossible to sell.  Especially when we are inviting our client directly to a living document.

What back then seemed impossible is a decade later the reality. Product teams I have built around the propositions ever since were always defined around a joint (less attractive yet very functional) redistributed documentation model. This mode was called “the power of one” – One language, One Location, One team, One product that gave birth to Design at Scale™. [008↘︎]

Customer Experience is different for every business, team or product, yet many teams start with an approach one fit’s all. Is it Blueprint, Site-map, information architecture, user-journey and persona that fits to double diamond or is it where the project is and what we are building?
90% of projects I have joined (and assumed that the majority of designer agree) has no documentation that describes the business objectives, what problem are we trying to solve, and what experience are we trying to build for our customers? 

That is why in the majority (8 out of 10) implementations, I thrive to build the centralised 3x3 proposition. By standardising each discipline's knowledge base and transparency about their contribution to the product or service, we enhance each project by 32%.[009↘︎]

Figure04: Real-time decision making.

What does the Experience Section do?

Structure:
/ Vision
/ Strategy –
/ Blueprint – Experience Mapping
/ CX Principles
/ Architecture –
/ Modeling – Navigation Model, Behaviour Model, Mental Model.  
/ Feature List – feature 01, 02, 03 etc
/ Pattern Library + Component List.
/ Product
  / Alpha
  / Beta
  / CR1.0

Starting with a vision and a simple mission statement or, let’s say, a manifesto is the best thing – why do you do what you do. Include you, Words(wo)man, and you’ll see how crystalised experiences are created. (make sure that your outputs are well integrated with your knowledgebase) [010↘︎]
Strategy – focuses on the experience strategy; in other words, how things are connected and what makes sense for your particular customer. (ask yourself; does the strategy evolve or is it fixed – based on the answer choose the approach and channels that supports it)
Blueprint and other types of experience-led mapping should be in one place so that everyone can access them within one or two clicks. In my case over the decades I have moved from Confluence (working for product companies) to InDesign documentation exporting tons of PDFs (working for agencies) back to Confluence – haven’t found a better tool yet. (meaning combination of Figma to Atlassian) [011↘︎]
The Information Architecture section combines all thinking behind the technical representation of iA and a sort of content architecture. I’m preparing another series of articles looking into specific outputs in relation to Design at Scale™ [012↘︎].
Feature and Component list utilised the full knowledge of these attributes and expected behaviours that all need to possess. What is important to mention here is that the focus is not on the quantity to document everything; instead, it focuses on clarity and relationships between features (creating desired behaviours) and components (holding + dealing with different data).

These pages are constantly updated where only the latest states that are most relevant are available. Essentially, it allows the business and engineering to see the progress in real-time. Contribution is encouraged throughout the whole development cycle. Depending on delivery model BDD[013↘︎] or TDD [014↘︎], we include User Testing Scenarios and Design Sprint Knowledgebase. 

Figure05: Experience Utopia Cluttered Communication 

The Experience Section Does not include.

In essence, the Experience section is a living, breathing organism to any project or service. Any designer needs to maintain this knowledge base to the highest possible level and refer to it at any time when a question about specific topics is raised.
 

The complete opposite picture of this so-called experience knowledgebase is Slack combined with a remote drive, full of documents that communicate different things without ever referring to another. It is essentially a dump-yard of files and images that are remotely related and mostly outdated as the team spends more time chatting in specific Slack channels rather than creating or documenting the proposition. 

Three main pitfalls of the Experience Sections are: 

Static / embedded files – We have touched on this topic in previous articles. The Experience designers create many artefacts in different software mainly based online. It’s been increasingly difficult to find what is the latest version of the site map on the miro board or mural service design workshop that unified the Service design Blueprint. Presenting a static file diminishes the capabilities and potential re-usage of such artefact in future iterations to come.      

Information duplicity – The statistic shows that even one person has roughly 20-30% of duplicated content. Think of your photo on your phone for the moment, multiple drives and backup solutions. Information duplicity is a real threat to any productivity as the file, information or decision you are looking for can be (and most likely is) replicated somewhere else.
Amongst other factors, this makes you and your team 20% less productive. A well-defined naming convention[015↘︎] across all your files [016↘︎] is one way to avoid that. 

Recreation and misalignment – In the medium to large-size teams, certain artefacts' recreation is inevitable. Think of the business containing five units and operating in different sectors, having a different voice and visual language tones, yet a common experience model. To align such a proposition is a real challenge for any design director yet for the design practitioner. 

We often hear: 

“We often hear; My team is too busy to unify and standardise, we must deliver first! ,yet the opposite is true.“

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.

Figure06: 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 fifth article from 3x3 – Confluence for Designers. @designatscaletm is open to discussing implantation in detail. The next article will focus on the Design section and all information related to design function.
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