;

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

February 20, 2020

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

The content section is controversial; 

“Why would anyone copy every single document to confluence? They wouldn’t unless they can link them directly to the live  code or have a rigorous regulatory process.”

And that’s what we have built – literally.
If you are a business with no written content and the only copy you are dealing with is an “OK” button, skip this article altogether and make yourself a nice cup of coffee. However, if you are a business that has to review many documents across different seasons, versions and stakeholders to update your product, you are in the right place.  
Outside the definition of the content strategy, language guidelines, naming convention, and tone of voice across the product, we focused on day-to-day copy tasks that need to be done. Confluence versioning, positioning, rights management and sign off process helped us enormously. 

Wordsmans (including females and males) are probably a less acknowledged part of the team. Yet without them, our product and service have little to no character. Their work creates the difference between the success and failure of whatever we designers do. Of course, we all can define and write the UX copy for a “Buy” button. Still, very few designers or developers can de-touch their experience and create a compelling story that supports the design and function and resonate with a broader audience. 

Figure02: Algorithm-driven Content. 

What does the content section do?

That’s why we have the Content Section in Confluence to help us utilise all knowledge about the story behind the product or service. Yes, you can write a copy directly in code, and some design software using the plugins allows that.  What happens with season updates, reviews, overall sign off process for different language mutations or several studies when it comes to legal documents for public view. 

We all have different challenges. For a brief moment, imagine five different business units that are loosely linked together yet inherently, from the customer perspective, act like one. Try to capture where your copy (story) will repeat, be elusive, misleading or contradicting if you have 20.000+ pages of content across 500+ domains. 

On top of that, each (page) document, regulation, T&C, help or just simple payment mechanics must be reviewed by the legal, risk and governing representative acknowledging the validity of such information. 

Figure03: Content location and versioning.

With confluence and simple “Include macro”, we have distilled all documents of all the propositions mentioned above with over 20k live pages of products and services into one comprehensive proposition. 

Complete reduction of Microsoft Word documents scattered all over the business followed the automated revision of repetition of the paragraphs on different sites. A simple example will be the footer that has 42 different links to T&C – after our automated exercise, there was just one link to one T&C.  

Review and automated sign-off from 2-20 members of risk, legal, insurance and BAU (business as usual) speed up the transparency amongst departments that equally provide the live copy to our developers integrated through a simple JSON file. 

Figure04: Why does the one location matter?

I have the privilege to work with the finest copywriters in both customers facing and legal/risk departments, which has significantly impacted my appreciation and humble understanding of the profound impact of well-written English. It equally supports the ambition of automation that reaches the development sooner than the code is released live without formal approval. 

Detailed versions and structuring can be found in Design at Scale™ workshops. 

Figure05: Content at Scale.

What the Content section does not?

The first it’s not a dump yard of World documents mentioned above. The problem with uploading the document to confluence means they are partially searchable, yet they are not part of the versioning. 

Uploading one document over another – is the practice of some less experienced copy teams. This will only mean that you’ll have the information in one place but no interactive, and there will be no chain of quantitative information about the document (page) unless you download and open the document. 

This increases the complexity of naming convention – forever challenging for every team, especially if you inherit the structure after someone else.

Word vs Confluence page – Word as an attachment to the confluence page can not be integrated into the code. Whereas the confluence page can be easily translated to the source code – .jason

Changes in Word can not be tracked in Jira, making it hard to manage and work a schedule. If the Confluence page is signed off, we can link the page to Jira and schedule for deployment.  

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: Confluence 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. Please contact me at @designatscaletm to discuss this implantation in detail if you have any questions. The next article will focus on the Experience section and all information related to navigation, and mental and behavioural models connecting the Research and Content. 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

February 10, 2020

Business Section

Overview

Welcome to the third article of the 3x3 series – Confluence for Designers looking at the communication structure for medium and large organisations to achieve transparency, which leads to frictionless and smooth design delivery.

I often hear from businesses colleagues, 

“Why would we need to share all our updates with our team over a confluence?“ 

The reason is quite simple – transparency plays a vital role in building trust in a constantly changing environment. If you do not trust your team to deal with all the necessary information about the business, how can you trust them to build the right product for your target audience?

“In other words, there is a close relationship between those who invest the time, energy and thoughts into a #business2design relationship – so should you.” 

You do not have to go too far. Harvard Business Review is full of compelling articles about businesses succeeding thanks to the design, though very few mention the many designs that succeed thanks to the transparency of the business unit. But what does it mean in practice, and what does it look like?

I suppose in my case; it goes a little deeper than INC, HBR, coDesign or other articles. It started as a mindset of the Bata family and workers who ingrain transparency and, in some respect, so-called “brutal honesty into their weekly working routines”. Suppose a trait of all the families of that era was to survive. Sharing information about progress, ambition, challenges, and approach was vital to everyone's success. Transparency kept everyone to be involved – to care. Everyone is part of the picture – everyone is accountable. 

Let’s fast-forward a century and look at how these traits support digital product design delivery globally.

Figure02: Strategy. 

What does the business section do?

Business sections of the Confluence structure are designed for a specific function. The function of business is to define, manage and oversee the delivery. And that’s where the design integration and automation come in.

It includes the Core and Aspiration Values, Products Strategy, Road Map for delivery, and Roll-out plan. Exclusively it holds a product definition in editable (including the versioning) form. Close monitoring of ROIs, OKRs, Road Maps, budgets, planning, legal, risk and other timelines  —  you name it. All for the product owners to justify the project feasibility and all necessary aspects of the successful launch in easy and shareable form. 

“Undoubtedly, the transparency makes the team more involved in cost-saving activities – in other words, how best we can achieve X.“

To give you a little flavour of how this could help both business and design, let me bring a short story that represents the best of the business section. 

An Italian Product Owner has joined the extensively large product team. Two months later, I joined the team and worked alongside his teammates. Instead of sharing the set of word documents and excel sheets common among these professionals, I was positively surprised to receive the link to Atlassian Confluence. While going through the initial set of organised documents in a very business-oriented way, I spotted an opportunity for collaboration and co-ownership of several verticals that were tied together. 

See the fact of having all text documents in Confluence; you can run some pretty basic scripts start to simplify the overall message over +3mil words. That soon leads to consistency and joined outcomes shared across OKR, KPIs, and the overall rolling strategy for the product. Design is not a “colouring in” function but carries the definition of all core behaviours. 

After a couple of initial sessions about the proposed strategy, how the design can help facilitate transparency upstream to C-Suit and how the automated monitoring can save us time on reporting across three programmes, it led to an agreement to build a small proof of concept. 

We quickly gained control over three products’ design delivery and product strategy with this concept and soon acquired two more to build a robust, scalable platform. The following five months showed that our little ambition saved us 22% of the time on reporting and 16% on translating the information from one stream of information to another (simply copy and paste). That was pretty significant, saving two days from a five-day workweek.

The product owner gained group-wide recognition and responsibility, and the designer moved to the design director role. This only shows when the business opens up and shares its strategy and the challenges; it’s easier to adapt and drive the innovation forward with a necessary adjustment while keeping an eye on one (or many) products. 

It’s important to say here that the elementary knowledge of Atlassian products is essential. Moreover, the impact is not in the design area only. It’s spread over the weekly and monthly reporting, daily stand-ups, team and disciplines rituals and delivers a vital engagement missed in many integrated teams. 

Figure03: Word vs Atlassian

What the business section does not?

If the business section becomes a damp-yard of PPTX, WORD and EXCEL documents is better not to have it. For a straightforward reason and its duplicity of information. If you are already working on One Drive, 365 or Google Drive and your documentation, structure versioning, especially business documentation, is in good shape (and easily accessible, linked together and connected to code), do not change it – if not all the above shows you an opportunity for transformative future.

A simple example here would be the midsize company or studio already documenting their basic finances in the business in Office 365. Copying all documents to Confluence makes no sense. Copying the documents that are relevant to the product team that creates the product or service is essential to their knowledge – especially if the information in PiD constantly evolves at the beginning of the project identification. 

Two most common questions here:
“Can we achieve a collaborative effect while identifying the product in Office” (or any other collaborative platform) – the answer is YES.
“Can we achieve an interactive document that represents the current status of a programme or product” – the answer is NO (unless you spend 3x amount of time linking your word document with Trello, Asana or Jira to get up to date updates)  

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 third 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 Research section and all information related to understanding and its integration. 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

February 5, 2020

Hello Section

Overview

Welcome to the first article of the 3x3 series - Confluence for Designers, where we’ll be looking at the communication structure for medium and large organisations to achieve the transparency that leads to frictionless and smooth product design delivery.

Colleagues often ask me: 

“Why would we repeat the brand or product name in the structure?“ 

The reason is quite simple. 

While your proposition might be created in isolation to start with, it will soon grow alongside other parts of the business. Once your product or service has a specific name or can be introduced across the company without ambiguity. A unique name or an abbreviation means it will be widely recognised and fundamentally easy to locate in the future. 

Figure 02: The info icon in a triangle.

Hello section does

The primary purpose of this section is to inform your colleagues about necessary updates related to the essential operation of the team or business. Any product team of any size will usually be part of a department or function. Therefore, a chain of responsibilities and feeling practical information in your hub is not just wise but highly beneficial to anyone who will collaborate with your team in the future.
It allows you to deal with a question like “where is the latest org chart”, “who is responsible for X” and finally, “where is the dialled number for zoom”. 

It also contains onboarding information for new team members, such as setting up email, signature, installing software, dealing with hardware and logging into different parts of the company’s ecosystem.

 
The interactive org is based on the team’s maturity in some cases. Charts help the wider team navigate the responsibility chain. If this information is in the form of PPTX, it’s pretty common not to be up to date or miss correct names and associations with an existing team. This simple fact wastes 28% of onboarding to locate the accurate information and get set up correctly. It also shows the team’s to mature – for this topic, let’s wait a bit as we prepare a specific series about the product team’s design maturity. 

The WoW can be inherited from the more dominant organisational functions, but it is always good to have your version. Here is why; the centralised operation team does not know your challenge's specifications or the workflow your team needs to go through. It’s an advantage for any new designer joining the team to visualise their understanding of how they deliver design work. At once, you’ll understand it, and second, your CPO® will reuse it in his next presentation to stakeholders.    

It eventually becomes a complete library of the product engagement strategy that makes your team’s work stand out. More importantly, this section shows that you understand the bigger picture beyond a designer’s daily responsibilities and slowly start owning it.  

Figure 03: The question mark

What does the hello section not offer?

While implementing this structure has proven vital for the transparency around the product, there are also some pitfalls along the way: slow business response, clarity of provided information, politics or silos, and possible duplicity of what exists somewhere else.  Let’s look at a few. 

Slow Business Response – this is usually the case where everyone is busy delivering and has no time to do anything else. In this case, it’s your call; do you want to build different alliances and strengthen your relations with others or just deliver the daily task?

The clarity of provided information – shows that business acts from the scarcity model; This is an even more significant opportunity for designers to drive innovation by clarifying everything through the design delivery process and improvement.     

Politics and silos – Careful here; exposing someone's incapability could be your fast route out of the team and soon out of the company. Do not ask your boss what he does not know, and do not make it a problem – no one likes them apart from designers, philosophers and scientists. Make it shine if you are in the bubble (aka silos). It is your territory now, and if it works well, others will copy it and help you scale it.  

Duplicity – the first thing is that everyone will tell you it exists somewhere, but no one knows where. Suppose you find it, great. If it’s good, use it; if not, update it and link it back to your team. Either way, the exposure for designers is limitless. 

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 first part. Please contact me at @designatscaletm to discuss this implantation in detail if you have any questions. The next article will focus on the Business section and all information related to making money. 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 1, 2020

Discovering 3×3

Many designers worldwide ask the same questions repeatedly “how do we deliver our design at scale?”. In other words, how can we adapt to the change where our remits start and finish?  

The answer to this question is widely defined without considering different methods or disciplines contributing to the delivery process. Linear processes like “the stage and gate” where deliverables are in large “thrown over the fence”, which we proved do not work for 90% of digital product development. The second method taken from the agency world of storytelling in 1996[00], called double-diamond, allows visualising the delivery process linearly, emphasising diversion and conversion. It worked like magic for a decade or so, where digital designers communicated how complex design propositions are to make them simple.    

This short article aims to answer the above question and offer “a different perspective on delivering design at scale” without losing control over a holistic experience while continuously supporting our engineering team by delivering the increments. 

“If you can't describe what you are doing as a process, you don't know what you're doing.”  —W. Edwards Deming

What if, instead of forced workflow for designers, we develop a fluid space  (let’s call it Hub for now) where we all follow one another. Extending the inherited linear workflow for any unique proposition to a flexible and exponentially led approach allows us to share and see all information.  

Moreover, it allows designers to transition from a sequence led, redistributed and chaotic communication into a robust, transparent and scalable Design Centre of Excellence that offers product teams clarity and facts. Leave behind the communication channels like slack, groups, teams and mail; we can look at the communication as commonly shared knowledge as such and reuse it to our benefit. In other words, the knowledgebase captures all information into one single ecosystem for product design delivery.   

Figure 02: Three Pillars    

Discovering 3x3

We all have seen the structures organised around products, or products of products, around disciplines or business units. Despite the challenge of all the above, I’ve remained explicitly focused on the information structure of digital product hubs. With well-documented feedback from all disciplines, I’ve crystalised a communication structure around any process.

We learn that each part of the business prefers its perspective or lens on the product. Companies look at the numbers, speed, and spending. On the other hand, the design looks at the consistency, patterns definition, plus functionality or desired behaviour where developers seek a clear BDD (or TDD) definition and resources to reduce refactoring ultimately. 

And that’s where I discovered the three by three (3x3) framework.  

Business — focus on the operation, budgets, vision, and objectives,  including team structure and onboarding. 

  • What do we expect from our proposition? 
  • Who do we compete with?  
  • And how do we address the differences in our product?

Design —concentrate on the content and experience of the final design proposition, including assets management. In other words, how this thing looks, feels and behaves. 

Development —concentrate on sharing information about APIs, databases, and data migrations along the way, tracking the releases and integrating what we have built.

This straightforward framework allows everyone to maintain and digest information in a specific way. Equally, redistribution of the content immediately leads to complexity reduction and simplifies the communication around the topics.

I have separated them into a series of articles to get a detailed overview of the problem and see all the parts in the actual products’ context.

Figure03: Philosophy

The philosophy behind

We believe that transparency is the key to success and that every team member is here to contribute. We do not build on responsibilities and duties; we thrive with our accountability and contribution. We all help define a better future – for us, the product,  the business proposition and the cause we all proudly follow.

Figure04: Three pillars

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

The next article will concentrate on where we store the information about the team, meetings, and bits that make the team connected and well-lubricated so that no one can ask where is “X”? 

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