This year I was a speaker at the “Resilient DesignOps Organizations” theme of DesignOps Summit 2020 with field practitioners from companies like Intuit, Intercom, Salesforce, Cigna, IBM, Uber, Dropbox, Electronic Arts, and others. And in this article, I would like to share my personal thoughts on the topics that I found interesting from my and other talks.

First of all, I would like to thank Louis Rosenfeld, Dave Malouf, and the whole crew for such a well-organized event!

The main focus of the DesignOps Summit was on People. Jose Coronado covered most of the things within the Resilient DesignOps Team of One, Building resilient DesignOps teams, and Resilient DesignOps Organizations articles. Make sure to check them out! To make our discussion more efficient, I will be covering specific topics in more detail.

The other emphasis points of this summit were around metrics, maturity models, and the DesignOps approach. Let me go through each of these topics and provide my personal thoughts on them.

Metrics in DesignOps

When we are targetting to create or increase the size of the DesignOps practitioners team, we need to show the value. I believe that’s why the community had a lot of questions about metrics.

Personally, I liked how Patrizia Bertini covered everything in detail around metrics in DesignOps. There is no one metric for DesignOps, it’s always based on the context (focus area like design systems, research databases, or design culture), goal (increase the design organization, increase market recognition, etc.), and the customer (design partner, a design lead, or design team). As a result, attention is concentrated on efficiency (saved time in hours × rate in $= value) and the quality that brings an organization to another maturity level (after implementing analytics, all our decisions are data-informed). To be more specific, here are some of the metrics from Patrizia Bertini’s speech:

An example of proving the value of #DesignOps in an organization @legoviews #DO2020 pic.twitter.com/OrjA78N8O6

In my talk, I was speaking about approaches to efficiency calculation. After interviews, co-creation sessions, or workshops — reviewed in the talk — you will be able to visualize the whole process. This visualization will enable you to provide the approximate time spent on each stage, communication gaps between different actors, and the amount of needed investment.

Investment estimate can be calculated by the time needed for migration (for example migrating all the files to another tool), onboarding time for the team, and time for new process support. For example, your team transitions to a new tool (like Figma) —you can create a survey in advance to understand how many people will need time for onboarding (i.e. training).

Once you have a specific practice that fits your needs, calculate the value and the amount of investment needed to scale and support the practice.

Remember, if you can calculate the optimized time, you can calculate the optimization $ value by multiplying the actor’s rate and time saved. Here are interesting slides from Patrizia Bertini, Dave Malouf, Kristin Skinner, and Kamdyn Moore

Focus Areas of DesignOps

My personal view is distinguishing the focus areas: DesignOps is People, Practices, Tools, and Craft. Where each of them is divided into strategic (organization), tactical (streams), and administrative (teams) levels.

However, another interesting idea was brought up by John Calhoun and Rachel Posman, where they shared that Salesforce divides DesignOps into the TeamOps and the ProductOps.

TeamOps - community & culture, learning & growth, systems & toolsProductOps - productivity & delivery, project & program management, strategic partnership with leadership#JohnCalhoun @rachelposman #DO2020 #DesignOps pic.twitter.com/zPUu3GF7SS

Some wondered if ResearchOps is a part of DesignOps. And the answer from the expert was affirmative — ResearchOps is a part of DesignOps. I think it’s a matter of your organization's maturity. If you have a team of DesignOps Consultants, maybe it will be better to allocate more narrowly focused disciplines like ResearchOps, ContentOps, CreativityOps, etc.

But why do we need DesignOps? Personally, my view that is investing in DesignOps will give design organizations more time to focus on Creativity, Innovation, and Research due to optimization and increased maturity. Regarding creativity, Dr Karl Jeffries had an amazing talk!

DesignOps Approach

It was a pleasant surprise, that all participating experts and speakers had the same vision on the DesignOps approach this year — we need to create and test hypotheses first and only then scale the whole approach. Here is a slide from Patrizia Bertini

We have to define the hypothesis we want to test, and define an experiment to test it@legoviews #DO2020 pic.twitter.com/fA0UF1zzql

Some people might think that strict processes might make us robots. But my personal view is that clear practices are needed only for guidance. And it’s the responsibility of your organization to keep them up-to-date and make sure that you have the right knowledge management.

You need to understand the difference between the in-house DesignOps manager and DesignOps Consultant. Here is the approach that I’m using personally:

If you have the access to the recordings from the DesignOps Summit, feel free to check out my speech. I covered the DesignOps approach in detail. And if you would like to take a glance at a study from others, I personally would recommend watching how Patrick Commarford and his team improved the staffing process in IBM.

The project intake process is transparent. The decision is not approve or reject, it is about determine the level of support that teams get from design#PatrickCommarford #DO2020 @ibmdesign pic.twitter.com/ZbWUktU49g

The Future of DesignOps

Wow, I love to think about the future! It helps to specify your goals and have a laser focus on your work. Dave Malouf, Adrienne Allnutt, Jon Fukuda, and Dominique Ward spoke about the Future of DesignOps.

I think our biggest concern is about AI. I liked the reply from Jon Fukuda about it. We are building products for people and AI will not be able to cover that. Design is not about creating beautiful mockups, it’s about solving people's challenges and that is the kind of thing that can’t be replaced with AI. Here are a couple more slides from his talk.

Develop our #DesignOps approach considering the entire system - equipped, aligned, integrated, informed, creativeCan we approach this in a holistic manner? @jkooda@daveixd @aka_adrienne #DominiqueWard #DO2020 pic.twitter.com/BT93s5uN1i

Currently, we are on the stage of standardizing the way how Design discipline works. Large organizations are creating playbooks and sharing them publicly. There’s still have some work to do because the job responsibilities are different from the company to the company. I hope, this issue will be solved soon.

A call to action: let's motivate one another to take part in this change, we need to adapt fast, improve our practices, contribute and help the design community grow and evolve@faridsabitov #DO2020 #designops #design #automation https://t.co/YHgtUUzKbA

After passing the standardize phase there will be a clear understanding of what kind of things can be automated. By automating the routine work, the design discipline will have more time to focus on more tactical and strategic work. Here is the feedback from Dave Malouf on my talk:

Discover redundancies ⭢ create playbooks/runbooks ⭢ create automations ⭢ create tools ⭢ create platforms. All in service to the People.

Here are some examples of the automation in Figma that you can implement in your teams to remove the routine work:

Made a script to generate a list of components used in selected screens in @figmadesign organized by the atomic design. Reply back if you would like to get early access. Planning to add @gitlab integration to visualize the component status as well.#DesignOps #Automations pic.twitter.com/djsTOgRs7o

Added smart spacing prediction feature as @figmadesign plugin🥳 Try here https://t.co/aYVATlZWXp pic.twitter.com/a2vfWB7Z1b

If you would like to use Figma API, here is another example of how to simplify the design review with the FE team. The script generates the component preview from Figma API and pastes it on top of the mobile application made in Flutter. That’s how developers are able to see inconsistencies while writing the code.

If you would like to ask what is my personal view on the future, I will say that within 2 years we will finalize our practices around design systems, then research databases (next 3 years), and finally knowledge management (next 5 years). What are your thoughts? Reply on Twitter!

Thank you!

The Current State of DesignOps. Metrics, focus areas and approach was originally published in xOps Today on Medium, where people are continuing the conversation by highlighting and responding to this story.

I think we all heard stories that “designers are not aligned with Agile development team. It’s hard to plan work for designers because there is no visibility. Design is never done and etc.” And there are reasons for that.

The goal of this article is to show the best practices of how to align designers with an agile team. It will be the first part of the series about Design Management.

Today I’m going to share the best practices encountered during my 9 years of experience. We will cover different use cases and speak about the practical approaches. As a result, you will be able to set up Jira for your design team. If you would like to focus on design management this article is for you!

Why Jira?

There are a lot of other different tools on the market, but when we speak about large design teams in big organizations, Jira is the best tool to go with. Azure DevOps is catching the market quickly because it’s a part of the Microsoft ecosystem but let’s stick with the Jira for now.

Maybe you already use different tools, for example, Trello. But the problem with other tools is that they don’t have enough functionality to manage large teams. For instance, if a design team decides to go with “simple” tools, due to lack of integrations and visibility with the agile team, problems become more crucial. Different streams might work on the same features, design teams might work on a project that is not aligned with the company’s strategy and development might not know the statuses of dependent tasks.

Features like custom issues, boards and workflows help to have visibility in the company and additional tools like Jira Portfolio and Structure help to manage everything at scale.

Let’s start with simple practices of how a design team can integrate into the Agile process. I will cover the main steps for Jira setup, but be minded that for some actions you would need admin rights. You don’t need to do everything yourself, just share these practices with your Jira Admin and provide all the needed requirements.

Custom Issue Types for Designers in Jira

I’m going to use Triple Loop Product Lifecycle phases and business goal project type. Let’s start with a product lifecycle timeline.

Above is the way Jira has all their issues on the timeline by default. Let’s take a closer look at the structure below.

When we understood the default structure, let’s improve it by adding new issue types for the design discipline. It will help everyone on the team to find the right issues and we can change their behaviour based on our needs.

We added two new issue types and both of them are used for Experience Design. Why do we have research and prototyping issues separately?

• Research activities are always high-level, without much details compared to user stories. The main goal is to validate problems, create and test various hypotheses. Main activities like user/expert/stakeholder interviews and usability testings will be conducted. That’s why it is placed on the same level as epics;
• Prototyping activities is the part where potential solutions are becoming more concrete. Since the design is much faster than the development, it’s better to store everything on the Epic level (otherwise, it is too much overhead to create design tasks for every user story). Activities like user flows, information architecture and prototyping are conducted. Every epic has a default experience design prototyping issue type.

As a result, we will get an updated timeline.

To create custom issue types you need admin rights. There are a lot of technical details that you can find on the Atlassian support website. For the majority of the cases, you can just present the structure of issue types to your Jira Admin. For example, a screenshot from this article will be enough.

Issue Fields

When we know the structure let’s cover what kind of information is needed for every issue type. There is an unlimited amount of customisation in Jira, but let’s cover only the main ones.

Description Field

Personally, here I like to provide some background information, To-Do list with some of the things that an assignee needs to prepare, acceptance criteria where a reporter can specify which kind of scenarios and edge cases have to be prepared. And finally, the resources section, where all the links to the prototypes and findings are stored.

Additional clarifications for the screenshot above:

• For the resources section, I made a separate field in Jira and integrated with Jira Automation. This way, when a sub-task is created, information from the parent issue will be inherited automatically.
• As you can see I’ve linked the review issue type. It helps to save all the communications and decisions. Inside the description field, I’m adding the meeting followup with the link to the recording, attendees list, notes, action items, decisions, open questions and resources. So everyone on the team can double-check why we started a new revision.

Due dates

In our upcoming articles, we will cover the visibility, planning and the workload. Understanding the due dates for a specific issue will help us to plan the work in the future.

Components

At this point, it’s better to discuss components with the team. From the experience, the components section can help to search and filter issues in the future. It’s like a cross-project search and can be used with the research database integration.

Side note: it is important to organize your research database properly and have it accessible for everyone on the team. The best examples that I came across so far is by Airtable. If you would like to share your set up, please feel free to do so in our DesignOps group.

Releases

We will cover the releases in greater details a bit later.

Generally, releases are mostly used in Kanban. But that’s the beginning of the next part where I will answer why Kanban is the best way to go with the design teams.

Kanban or Scrum for Design teams?

If you are not familiar with the main principles here is great documentation by Atlassian. We tried to use Scrum in our design teams and we failed, because of the following reasons:

Reason #1: Design is not the same as Development

Design can’t be compiled as in development. There is no right decision. Designers can’t estimate their efforts properly on the Scrum grooming sessions, especially for research activities. That’s why the due dates are important. It’s better to use releases instead of sprints.

Reason #2: More iterations after business, tech and user reviews

We have much more iterations than development teams. We can go through a couple of iterations with the business, then we need to make sure that everything is feasible. Then test everything with the real users and start the cycle one more time. Design teams might have more than 10 iterations for a specific epic.

Reason #3: Designers are not fully involved in development teams

Because of our speed, we are not always dedicated to one development team. We are switching between different teams and projects.

Revisions

Revisions are basically the changes to the design after review sessions. Each revision might have a couple of activities inside, which are specified in a short description as a To-Do. Because of the speed, it’s easier for design teams to specify all the scope of work in the description field and when it’s done to review all work. And if we need to update one more time we can just create another revision and work with it. Here is why revisions are the choice for design teams:

1. Don’t need to create a task for each activity. Just specifying everything in the description resolves the problem with visibility and saves time;
2. Easier to see that specific project or specific epic had too many revisions because the business didn’t have a clear vision;
3. Easier to estimate the work that was done. If we will reopen the design issues we will need to calculate everything one more time and add the results to the total amount. With revisions, you can just estimate the work after and close it when it’s done.

Let’s take a look at our updated structure.

And to be more clear, let’s see how the updated structure will behave on the timeline.

Now we can see that before actually developing something we need to research and make sure that the solution that we are going to develop is valuable on the market. On the example above there is only one cycle with the prototyping phase and we might have much more in the future. Revisions will help you to see all the updates and find the reasons why we are making them.

Story Mapping with Releases

Story Mapping will help us to align the scope of work with the whole teams and specify the releases. More information about the story mapping can be found here.

It’s similar to the Customer Journey Map when on the top section you are specifying phases, steps or epics based on the scale of your project. Usually, it’s used for organizing user stories but I like to use it as a high-level map as well. Bellow, you can show features ordered by priority. Each of these features can become a separate epic in the future.

The goal is to divide all work into releases that we can actually release if we will not have enough budget. By making sure that the whole flow is covered and we have everything for MVP with all dependencies we make sure that the whole team understands the scope of work.

And based on estimations and the capacity that we have we can specify the releases. You can do everything directly in Jira. There are some interesting solutions on the market. But personally, for me, it’s easier to conduct this activity online with the whole team in Miro or Lucidchart.

Let’s go back to our timeline and see how releases are working for our research activities. By mapping them with the releases we can make sure that we are testing the right things for the upcoming releases.

As we know when we are doing the research activities and brainstorming on the ideas, we see how many extra features we could bring in the future. Most of the times some of them are not aligned with the business goal for the project and they are marked as our of scope functionality. It’s important to save them and for that purposes, we can use the idea bank issue type.

UX Debts and the Idea Bank

After every release, we are adding all the ideas that we had to the Jira. The best practice will be to link it to the original epic and perform the same for UX debts. For prioritizing ideas you can use GIST framework, ICE Scoring and Kano model.

You might ask why we are creating new issue types for everything when the problem can be resolved just by labels? Custom issue types will help us in the future to create custom fields, workflows and boards for the next series of articles.

Conclusion

As a result, we came up with a simple issue structure for the design teams and most importantly we integrated our design process with the agile teams.

On the next article in this series, we will start working on visibility, planning for the design teams and the workload. Will cover some of the tools for smart staffing like Jira Portfolio and will see how everything works in a real-life example.

All the best,

Farid

Ultimate Jira Guide for Large Design Teams was originally published in xOps Today on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Purpose.

If you ever encountered a problem when other people in your team were not aligned or there was no unified process, this article might help you address this issue!

After 9 years of experience working in studios, outsource, product, consulting companies and even trying to build my own startups, I came up with a simple classification of project phases and designed a Triple Loop Product Lifecycle.

Its purpose is the creation of an aligned high-level view with all main project phases for a business goal project type. This way, competencies like business, design and technologies are able to map their activities and deliverables.

Your feedback is really valuable, so please don’t hesitate to share the reasons if these practices are not working in your environment. Just add a comment below or write to me directly on Facebook ✌️

Triple Loop Product Lifecycle

The goal of Triple Loop Product Lifecycle is depicting the progression of a project from idea to a solution, where the main focus is on learning and measuring the results.

Nowadays the market is competitive and things are becoming more complex. Each of these phases has its own goals, activities, deliverables; involves various specialists to deliver valuable decisions filtered on each step through multiple iterations. We are only going through the product stream (business goal project type).

Here is the preview of how it works:

On the animation above, each circle represents one iteration that can happen repeatedly. Additionally, collected during an iteration results won’t necessarily be inherited by the next circle. The goal of this approach is to avoid becoming a feature factory and focus on delivering only valuable results (goals, assumptions, hypothesis, insights, solutions, decisions).

Here is another preview as a timeline. You can use it to map your activities and deliverables, plan all the work in advance and make sure you didn’t forget anything.

Let’s quickly cover the main points.

Discovery

The goal of this phase is to answer the question “Why?” and align the team with business goals, strategy and vision. Moreover, it assists in identifying the main problems and planning the work in advance. To achieve faster results use activities like Discovery Workshops, Interviews or Design Sprints. The outcome would be a high-level roadmap, project brief, resource plan and other artefacts.

Learn

The goal of this part is to validate problems, analyze insights and formulate hypotheses to test. Initiate activities like user interviews and user testing. The deliverables would be personas, value proposition canvas, Customer Journey Map, prioritized hypotheses etc. This stage could be repeated once more insights from the experiment and measure phases are collected.

Prototype

That’s where the ideation and low-fidelity prototyping comes into play. It’s not only about information architecture, user flows and wireframes. For example, solution architects could kick off the preparation of high-level implementation diagrams.

At this point, we start to visualize solutions for further testing. As a result, we will get a low-fidelity prototype that will represent possible options.

Experiment

This is the part where the truth might come out, as most of the hypotheses could be tested in the Experiment Phase. Usability testings and other qualitative research methods can be conducted here. As a result, we will get a bunch of insights that will help us in the future. As you might see from the diagram above we could have a couple of iterations with the prototype phase.

It’s important to keep in mind, that it’s too early to draw any conclusions regarding the success of any specific solution. Instead, our goal is to validate hypotheses. Only after releasing functionality on production with real users, it will be possible to measure the created value.

During Experiment Phase, we could test our ideas on a small number of users without any development efforts. Rough mistakes will be found at this stage.

It’s hard to plan the work in advance for the Learn phase and that’s why it’s better to restrict this phase with a specified time frame. Kanban methodology with releases works perfectly at this point.

Build

When we have a clear understanding of why, how and what exactly we are going to build we can focus on the build phase. That’s the phase with plenty of iterations. As a result, we will get a working functionality on the testing environment to evaluate.

We will come back to this phase when there are new requirements and bugs from the Experiment and Demonstrate phases.

Demonstrate

The key is to cover edge cases and test everything that was developed to this point. QA teams are thoroughly examining the product to discover vulnerable parts and bugs before deployment to production. Some companies might have more than 5 environments to test on.

Side note:
It’s important to focus on accessibility. For example, if designers used non-accessible patterns, Accessibility team could spot these issues visually during Experiment OR look for problems in code after development was done during the Demonstration phase.

Improve

At this stage, the whole team is trying to fix the problems and prepare for the release. We might have an extensive number of iterations with the Demonstrate phase at this point.

Measure

That’s the final step to evaluate value created for the company by the efforts made so far. Running surveys, user feedback reviews, tagging, segmentation, feature retention and bounce rates can give a lot of information on how we improved or worsened the main business metrics specified in the beginning.

Side note:
The best way is to release on small groups of people first. You can use different segments, audiences or specific markets based on the countries.

At this point, we have three possible scenarios:

1. Return to the Learn phase and make a more significant improvement.
2. Continue improving the functionality on the Improve phase.
3. Go to the Finalization phase.

Surprisingly, but even after a round of development, some successful companies can roll back new functionalities. The reasons that justify those decisions usually are based on unmet target metrics or lack of desired engagement. By the way, check out articles about the feature flagging for that purposes.

Finalization

If a business understands that the project is not evolving into something valuable, it’s time for Finalization phase. Take a look at the Google Graveyard if you still think that all the projects/features have to adopt whatever was developed. The golden rule — fail fast and pivot.

Different teams have different approaches to development — often some of the mentioned earlier activities and phases are omitted. Therefore teams fall into various maturity levels.

Maturity Levels

Team classes below have specific skills and competencies based on the phases that teams go through. For example, for C class teams, it’s crucial to have product managers and user research team to perform the research activities. E class teams require data analytics and a large user base to ensure that the collected data is relevant.

Recently, it’s desired on the market to be an S class team, since this approach leads to efficient delivery. Therefore Operations is the key. You might have already heard about BusinessOps, DesignOps, DevOps and Design Systems.

These topics are in demand right now. The market showed that increasing the number of employees, does not necessarily yield more results. So the challenge now is not only going for the “right” solutions but also to deliver fast.

Follow me and add me on Facebook if you want to know more about the DesignOps.

Bonus

To set up a common process that helps your team to be more goal-oriented, engage people and make sure that everyone understands how the process works. For those purposes, I’ve created a poster that you can download and print! Please comment or share with colleagues if you found this article helpful.

Please share the photos with hashtag #TripleLoopProductLifecycle! I’m very excited to know if my work helps and motivates people around!

Challenge

It’s not enough just to absorb the information, start adopting in your work what you have learned! I would like to help other people and that’s why I started the new challenge. More information below!

Try to implement Triple Loop Product Lifecycle approach in your teams and write back if you have any challenges. Let’s share the practices and cases here, so we can learn together!

Facebook

Your feedback is really valuable and I would like to know the reasons if these practices are not working in your environment. Just add a comment here or write me directly on Facebook ✌️

Triple Loop Product Lifecycle. Learn, Build, Measure and Maturity Levels was originally published in xOps Today on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Purpose

With the growth of Design practices in Tech, there is an opportunity for DesignOps practices. I think you heard about the problems that designers are not integrated with the Agile. It’s hard to plan and review the work from the designers because there is no compiler that will show all the mistakes and we have more iterations rather than others. My goal is to show some of the practices that can resolve this problem and I would like to start with the basics. Project types will help us in our further discussions.

Understanding of project types will help us to:

• Prepare the right workflows in Jira and other issue tracking systems as a part of Design Management. Will share my personal approach soon, stay tuned 😉
• Present all activities and deliverables specified for each project type, because all of them have different objectives as a part of Knowledge Management;
• Governance rules with the right organizing of deliverables and mapping with other systems as a part of DesignOps practices.

After 9 years of experience of working in studios, outsource company, product, consulting company and even trying to build my own startups I came up with the simple clarification of the project types. Your feedback is really valuable and I would like to know the reasons if these practices are not working in your environment. Just add a comment here or write to me directly on Facebook and I will add you to the meeting for further discussions ✌️

As you can see from the diagram there are no clear borders which project is only focused on the product and which only on operations.

The difference between the product and operations is that the product creates value for the customer and the operations focus on efficiency, speed and quality of delivering these values to the customer.

Strategic Project Type

The place where the business tries to research and find opportunities on the market. It’s the beginning of all initiatives. Of course, not all the initiatives will be taken into the development and even if we will decide to take some of the ways, the market will not see the solution in the first couple of months. It’s like a chess game with your competitors to catch the right market and planning your moves in advance.

Let’s take Instagram as an example and go step by step. I’m not working or connected to Instagram and everything bellow is just my assumptions. Because everyone knows this product well, it will be easier for us to understand the examples.

Example: After the research about the market opportunities, trends and the problems with scaling into the new regions or audiences, Instagram understood that they need to focus on communications and tools to bring more creativity to the app.

As a result, they decided to focus on chat (and that will become our next project type as a business goal project) and face masks (innovation project). And that we are going to speak about next. You can see the diagram at the beginning of the article to understand the flow.

Innovation Project Type

Before spending more budget on the research activities and starting developing the solution, we need to make sure that it’s feasible and we have the capacity and knowledge to achieve our goals. Usually, it’s a small group of highly skilled developers who are trying to develop a proof of concept in a short period of time and we are speaking about machine learning, computer vision, big data competencies that are new on the market.

Again, in some cases after planning the budget and calculating the ROI we might just buy an existing solution that will help us to release this project faster.

Example: To deliver face masks functionality into Instagram and Facebook they decided to buy an existing product called MSQRD. That helped them to release and catch a specific market faster and have people who already know how to work with this technology.

Couple more thoughts about the importance of having innovation projects. I’m separating research into two types. The first one is used to find the user problems and validate some hypotheses with qualitative and quantitative methods and the second type is the innovations. I like the quote from Henry Ford:

If I had asked people what they wanted, they would have said faster horses.

Just think about it. That shows the importance of having specifically dedicated teams for innovations in the company.

Business Goal Project Type

More default and commonly used. The project type with a special goal and the budget.

Example: Adding a chat platform to Instagram as a part of a communications initiative. A clear goal, a lot of dependencies and the touchpoints with the current solution. Starting with the discovery phase where we will understand the problems and will get rough timelines and the resource plans.

Based on this diagram we can see visually how the project starts, where we will have more iterations and what kind of project phases we are going to have. I will cover all the details in the upcoming article.

Enhancement Project Type

When the product is already on the market and we are getting feedback from the customers we can start creating a dedicated team for the support. And for that purposes, we can use the enhancements project type.

A project that is focuses on improving the user experience throughout the app based on funnels data from analytics and feedback from the customers. More bugs and support issues are coming up.

Example: Let’s imagine that after the business goal project type called “Chat Platform” the team didn’t focus on the ability to select libraries from the camera roll on the chat platform. After the release, we’ve got a lot of requests from the people to add this functionality. And that will be the next functionality that we are going to focus on as a part of enhancements project.

In some cases, some of the features from the enhancement project can become a business goal project.

If you would like to know how to organize all your design deliverables in Sketch + Abstract or Figma, stay tuned I will prepare a detailed article about that as a part of DesignOps practices.

Operations Project Type

If you have more than a hundred people working on the product you might see that everyone works differently and the company becomes less dynamic. Operations teams are becoming more popular today. As a result, you might already know about the DevOps, DesignOps, BusinessOps and etc.

Big companies understood, that by having more people in the company it will not proportionally bring more value to the customers. Just having more managers is not enough. We need to think about how ways how to leverage the technologies and tools for automation. Having more clear and efficient workflows. Bringing new practices to the company that could help us to amplify the value and impact at scale. Support and help to the people in the company, so they can perform at their best levels.

Example: Let’s cover only the design competency inside Instagram. I don’t know how many designers are working on Facebook but with the larger team, we need to think about the way of how people are working with each other. Is the development team satisfied with the deliverables? Are the project managers know the availability of the design teams and can plan the work ahead? Can other designers on the team find all research reports from the previous time? How does the business work with designers? Is there a design library and integration with the development library in the company that we can call a design system after? For all of these problems, DesignOps practices can help.

And speaking about the design systems. Let’s cover that next. Because it has a different approach and team structure. I will post more details about the design systems soon😉

Design System Project type

I think you already heard about the importance of having a common design system for your project. It brings more consistency and saves you the time because you don’t need to reinvent the bicycle every time. You creating a lego brick and then building solutions using this bricks.

Example: You might find a lot of similar UI elements in Instagram that are reused in the app on different screens. Usually, for that purposes, there is a dedicated team who is building all the elements and trying to deliver easy to use bricks for other product teams. My favourite publicly available design systems are Atlass Kit, Material Design and Ant Design System.

Conclusion

I tried to cover all the main aspects of the different project types on this article and I will be referring to it in my upcoming posts. That’s the basics that I would like to start with as a part of “Organising Chaos in Tech” series.

Try to implement these practices in your company and at least create boards with custom columns based on the project types in Jira. Try to organize your deliverables and specify the main phases for each project type. I will share all my experience here, don’t forget to follow. I would be interested in hearing your thoughts and experience on my Facebook or in the comments below!

If you liked it, please share some claps 👏 that will help me to post more interesting content here!

Organising Chaos in Design 01: Project Types was originally published in xOps Today on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi Design Community! I think everybody faced the problem of the right artboard naming in Sketch. At my work, I have been testing different techniques and tried to find the best way. I’d like to share my findings with you. If you enjoyed this post, please leave some claps 👏

Pre Story

As for me, I like when everything is organized and structured in the right way. A couple of years ago, I was adding numbers at the beginning of artboards. Within a few weeks, my artboards had structures like “2.8.12.1 Adding story from admin side”. Renaming and keeping the numbers in actual format was taking so much time.

So why you need to add these numbers? And my answer is — the right order and filtering. When you name your artboards randomly, it’s very hard to sort your screens between the sections inside InVision or find a specific one in Abstract. If there are 50+ screens it could be quite overwhelming 🤯

Solution

Try using abbreviations — it makes it working with artboards a whole lot easier!

As demonstrated on the preview above, use the first letters from the “Section Title” within the “Subsection Title”. And for the artboard, add first letters from the section and subsection with the artboard name at the end. Personally, I like to use Behaviour Driven Development(BDD) specifications. Let’s have section title as “Create Email” and subsection as “Wireframes”. As a result, your artboard name will be:

CE: W: When user clicks on “Create Email” button, then show “Create Email Modal Window”

Let’s quickly discuss everything below. In the end, you can find a link where you can download the Sketch library that I’m using for free with all the symbols for headings and Jira previews 🥳

Page Title

The name of the project or “Initiative” that you are working on. Main things to remember:

• It represents a project or initiative that you are working on
• Must be only one on the page

Section Title

Usually, we are using it for the “Epic”. We used it for revisions before, but with Abstract all the problems with version control are resolved. Main things to remember:

• It represents one big feature, like “Epic”
• All other sections are placed on the right side

Subsection Title

Used for different activities like sitemaps, user flows, styles used or wireframes. Main things to remember:

• Subsections are used for different activities. If you have more than one screen, you can show it on the right side
• First letters are taken as abbreviature from the “Section Title”

Artboard Naming

Hooray, here is the finish line! As you can see all the artboards are named by the sections and subsections they are placed in. If you will name and organize things properly, just by looking into the artboard name will give you an idea where it placed in a two-level hierarchy. You can use our own techniques, but I’m using that for Epic → Activity. Main things to remember:

• First letters are taken from “Section” and “Subsection” as abbreviations
• You can name them in the Behaviour Driven Development (BDD) format for wireframes

Why it’s better?

Invision

You can easily sort your screens in InVision based on the first letters and move them into sections. You can also add Jira ticket code into section name in InVision. So others can open the Jira epic issue and read all the updates

Abstract

You can easily find screens in Abstract by searching by the first letters. Also, you can see that we are adding Jira issue code to the name. It will help us to understand which project (Initiative in Jira) is working on this file

Download the library

Inside the library, you can find a lot of extra things that will help you to organize your work. Check out notes and artboard states! Download here 👇

faridsabitov/Sketch-Interactions

If you would like to contribute or just say “Hi 👋”, please do it in Spectrum. And big thanks to EPAM.com and DesignSpot for all the support ❤️

You can write to me directly via mssg.me/farid or find me on Instagram or Dribbble as @faridsabitov

Best practices of artboard naming in Sketch was originally published in DesignSpot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Plugin for Sketch to create connection flow arrows for creating user flows, sitemaps and many more. Saves hours if you are doing them in Sketch.

Just select two objects and click on “Plugins” → “👉 Connection Arrows” → “Create Connection” and voilà! It will create a connection with arrow 🚀

🥳 Bonus at the end of the article

Motivation

In our day to day activities, we are creating a lot of diagrams in EPAM. I realized that most of my time is spent on connecting and drawing arrows for the diagrams. There are some tools like realtimeboard for doing that, but personally, I like doing everything in Sketch 😋

I searched a lot and couldn’t find a plugin, that was able to create a simple arrow between two selected layers. That’s why I started to develop a plugin, that could help me with that.

The cool thing about this plugin is that it creates vector shape arrows and adds all the arrows to the bottom of the layer list as a locked group. Because of that, arrows will not disturb you while interacting with all the other layers and you can draw a connection with any type of layer 🕺

Download Plugin

You can find the most recent version here or install in via Sketchpacks 😍

faridsabitov/Sketch-Connection-Flow-Arrows

How it works

Create a connection

Select more than one layer in Sketch and click on “Plugins” → “Connection Arrows” → “Create Connection”

Update all connections inside artboard

Select artboard where all the arrows are stored and click on “Plugins” 👉 “Connection Arrows” → “Update Connection” → “From the Selected Artboard”

Delete connection between two layers

Select layers that have a connection and click on “Plugins” → “Connection Arrows” → “Delete Connection” → “Between Selected”

Extra Features

Inside settings, you can find more features like arrow direction, spacing, and auto-align 😍 If you need anything else, please write to me on Spectrum 👇

Sketch Arrows

Arrow Direction

By the default you will have an “Auto” mode, that will draw arrows based on the position of the second layer but if you are creating user flows or sitemap, where all the arrows are pointed in one direction, you can specify it in settings.

Arrow Spacing

For saving time and not moving all the layers one by one, you can pre-define spacing in settings. When you will create or update connection between two objects, it will automatically move the second layer for a specified amount of pixels ✌️

Auto-align

If your second object is misaligned for less than 5px with this option turned on the plugin will auto-align the second object based on the direction. So you don’t need to spend time aligning everything 🤘

Specify own hotkeys

If you would like to speed up more, you can specify own hotkeys inside Mac OS settings. With the same approach, you can specify hotkeys for any other actions in Sketch

More detailed tutorial 👇

Bonus: Sketch Interactions Library

I’m happy that you’ve read the whole article and I have something more for you! 🥳

faridsabitov/Sketch-Interactions

If you would like to contribute or just say “Hi 👋”, please do it in Spectrum. And big thanks to EPAM.com and DesignSpot for all the support ❤️

You can write to me directly via mssg.me/farid or find me on Instagram or Dribbble as @faridsabitov

Sketch Plugin: Generate connection flow arrows for sitemaps and user flows was originally published in DesignSpot on Medium, where people are continuing the conversation by highlighting and responding to this story.