A

Action items: Action items are shown to the user at the workspace and project level; action items are TODOs that the user is expected to act on in the context of the workspace or project.


Activities: Activities are a unit of work at the project level, activities are assigned to project team members (designers) and the team is expected to work on assigned activities. The platform provides multiple aids and governance on activities to ensure completion of work on time and with the required quality.


Activity dates: Start and end dates are one of the key attribute pair that defines an activity assigned to one or more project team members. The owners of the project typically plans the activity date and the platform records the same as planned dates. Internally, the platform creates the actual versions of the dates when the user begins the execution (these changes are shown in the Timeline view for Plan Vs. Actual analysis).


Activity permissions: Activities are accessible to users who are assigned specifically to one or more activities in a project. Assigned users have the authority to work activity, upload documents, upload best practices, update measurements, etc. 


Activity status: Activity has system provided status values e.g. NOT STARTED, IN PROGRESS, IN REVIEW & COMPLETED. 

  • Activity assignees can set the status to IN PROGRESS and IN REVIEW.
  • Project owners have the authority to review the activity and set the status to COMPLETED. Additionally, Project owners can also reject the activity which will update the status to IN PROGRESS.


Activity workflow: An activity workflow is a simple (yet very powerful) approval workflow between the activity assignees and project owners; activity assignees can select relevant project owners to get their work reviewed. Project owners have the autonomy to review the work and approve/reject the activity. All users are notified by the platform (across multiple channels e.g. Actions items, Email, Slack, etc.) to keep them on top of their responsibilities.


Alerts: Alerts are important platform notifications that the user must know, it's surfaced in Workspace home and Project home with contextual navigation to the module (e.g. projects) to act on the alert. 


Allocation & Utilization: This is one of most powerful features offered by the platform, it can be explained as follows:

  • Project level allocation: When a user is allocated to a project by the owner, the platform computes the availability of the user in the context of the project start date and end date and recommends a percentage allocation (this can be 100% or less than 100% depending on user's availability). The project owner can change the system recommended allocation based on owner's discretion. The platform showcases allocation in % with corresponding hours value auto computed based on Work time settings in Teams.
  • Project level utlization: The platform starts computing utlization when is user assigned to an activity. 
    • The user is over-utilized when the total time computed based on activity assignment exceeds project allocation for the user.
    • The user is under-utilized when the total time computed based on activity assignment exceeds project allocation for the user.
    • The platform recalibrates utilization when the user completes the activity (e.g. if the activity is completed before the planned end date then the actual completion date is used to compute net utilization). 
  • Workspace level allocation: This is essentially a report for Design leaders to understand the health of an individuals or group of individuals assigned to various projects in the workspace. The platform auto computes overall allocation (considers many complex cases like overlapping projects, linearly stacked projects, etc.) which will enable design leaders to continuously calibrate the health of the team.
  • Workspace level utilization: The platform computes the overall utilization based on activities assigned to the user, this will enable Design leaders to check how well the team is consumed in various design initiatives. 


B

Best practices: Best practices are a part of Design standards, allows Design leaders to identify and configure best approaches/references for any design related topic. Best practices in the platform is a a very flexible module, allows users to upload organization best practices, associate them with Design activities for teams to refer while working on the same. The core intent is provide execution aid for better quality and efficacy of design outcomes.


Billing: The billing system in the platform is powered by Stripe, the unit of sale is a contributor.  The following permissions are paid: Super Admin, Admin at the workspace level and Owner, Contributor at the project level. The platform does not charge for Observers (Workspace) and Viewers (Project). The Billing system in the platform exposes the user to payment details, estimated payment for the next billing cycle and invoices for past payments.


C

Comments: Comments are unit of collaboration in the platform; comments can be associated with documents, activities and potentially more business artefacts in the near future. Comments can be tagged, comments can have attachments; tagged comments triggers omni-channel notifications (Mentions in Action items, Email notification, Slack/MSFT Teams notification with the ability to respond for channels like Slack without going to the platform).


D

Design activities: Design activities are a part of Design standards, allows Design leaders to identify and configure standard units of work for any design related topic. In addition, the platform all allows Design leaders to assign Best practices to design activities, this enables designers to refer to approaches / practices and execute their unit of work. Design activities can be added to a Design process or can be added to projects.


Design maturity: Design maturity enables Design leaders to understand the competence of the design team based on multiple dimensions e.g. Process, Strategy, Knowledge, People, Culture, and Leadership.


Design process: Design processes are a part of Design standards, allows Design leaders to configure standardized way of working by identifying activities that needs to be executed, duration of those activities, and associated details. Once a process is in place; Design project managers can launch projects within minutes and ensure predictable design execution.


Documents: The journey of design execution results in generation of many types of documents (design mock-ups in Figma, design jam outcomes in Figjam, research documents in Google drive, persona documents in Google slides/Figma, user testing outcomes from a platform like usertesting.com the list is endless); Documents in the platform enables users to upload evidence of execution which internally aids to building a context powered repository (which in turn contributes to building a very deep organization knowledge system).


Document tags: Documents in the platform are tagged based on the context of generation/upload e.g. documents imported from Jira are tagged, handoff documents are tagged, evidence documents are tagged. Tagged documents aid easy discovery of documents in the platform.


E

Estimated plan cost: Estimated plan cost indicates the price you have to pay for the workspace in the next billing cycle.


G

Goals: Goals in the platform aid alignment between Business and Product with the Design team; the goals framework is flexible to track intra team goals (e.g. design goals). Goals provide a way to measure the progress made in the aforementioned alignment using metrics. 


I

Integrations: The design ecosystem is highly heterogeneous, design teams and designers use a plethora of tools (design tools, testing tools, document tools, measurement tools, etc.) to aid their work. The integrations workflow offered by the platform connects with various tools to aid strategizing, planning and executing in the platform. In many cases, integrations (with platforms like Jira, Figma, Slack, Teams, Google Drive, OneDrive) ensure seamless co-existence of the design universe with parallel universes like product development and enigneering.


Invoice: A commercial document between Cubyts and you that outlines the terms of sale, and provides information to how to make the payment.


M

Mentions: Mentions are important platform notifications that contain comments where the user is tagged, it's surfaced in Workspace home and Project home with contextual navigation to the module (e.g. projects) to act on the same.


Metric categories: Metric categories are used in conjunction with Goals, whilst Goals state the ambition, metric category sets the direction of what has to be measured to achieve those goals e.g. Adoption or Acquisition.


Metric: Metrics are used in conjunction with Metric categories & Goals, whilst Goals state the ambition and metric category sets the direction, metric is what is finally measured e.g. number of customer sign-ups for Acquisition, then number of feature runs for Adoption, etc. 


O

Objectives: You can this module to define your corporate, team, project objectives in terms of Visions and Goals, align them with execution and measure the impact of Design.


P

Payment cards: Payment cards in billing is a list of cards added for payments, one card is selected as a default card for processing payment.


Plans: Platform supports a Free (forever) plan and a Teams plan with a freemium model; each plan has a specific scope in term of exposed features and functions.


Projects: Projects in the platform will enable you to conceptualise, structure, plan and execute Design initiatives with your team; you can collaborate with your stakeholders (customers, product managers, etc.) and share the outcomes of designs in products like Atlassian Jira.


Project dates: Start and end dates are one of the key attribute pair that defines a project with one or more project team members. The owners of the project typically plans the project dates and the platform records the same as planned dates. Internally, the platform creates the actual versions of the dates when the owner starts the project.


Project permissions: Projects are accessible to users who are assigned as Owners, Contributors or Viewers. The platform exposes or authorizes the user to perform actions on the project based on the assigned permissions. 


Project status: Project has system provided status values e.g. NOT STARTED, IN PROGRESS, & COMPLETED. 

  • The project status is automatically set to IN PROGRESS when an activity is set to IN PROGRESS.
  • Project owners have the authority to review the progress of the project and set the status to COMPLETED. 


R

Reports: This module is the DesignOps visibility layer for Design leaders; provides insights on Projects, Teams, People and aids in mission critical decision making.

Repository: The Repository module is the central piece of the platform, this is the place where you will find all your documents (that are created across various projects, across various impact measurements, across various tools that you may have integrated, etc.); With Repository, you will also be leverage the Organization knowledge at the point of consumption with the intelligent AI-driven repository functions like Summaries, Q&A, chat with document, etc. (which will be coming soon on the platform made available based on a plan that you have purchased).


S

Seats: The total number of seats in your workspace contributes to your final bill, the following permission types are considered as valid seats for billing in the platform:

  • Workspace permissions: Super Admin, Admin.

  • Project permissions: Owner, Contributor.


Subscription: A subscription represents that you have either purchased a free plan (for zero value) or a paid plan (e.g. Teams); a subscription has an end date and you are expected to renew the same before the end date (the platform will auto-renew the subscription if you enabled the same).


Standards: This module will enable you to manage your design standards e.g. Design process for execution, Design activities as a unit of work, Best practices to aid completion of work, and Design metrics to measure impact of work.


T

Tasks: Tasks enable activity assignees to breakdown their work to the lowest atomic unit; task brings the highest level of predictability from an execution standpoint and enables the activity assignees to present their progress with absolute authority.

 

Team: Teams represent people in your workspace who participate in various parts of the platform (e.g. participate in project, execute activities, manage goals & metrics, etc.). With Teams, you can not just manage the platform permissions; you can also manage the health of your team by analyzing the allocations of your team members, by looking at utilizations across various projects and therefore ensuring a well balanced design team (that blends well with your stakeholders).


Team permissions: Permissions allow you to assign authorization to your team members, permissions are exposed at the workspace and project levels. The following permissions are paid and contribute to the total number of seats:

  • Workspace permissions: Super Admin, Admin.

  • Project permissions: Owner, Contributor.


W

Workspace: Your workspace is where people can work together, integrate their favourite tools (e.g. Google drive/Jira), find documents from repository and learn from standards. The platform creates a personal workspace for yourself when you sign-up for the platform. You may be part of multiple workspaces based on invites from your colleagues. Note: You may use your workspace as a shared workspace for your team to come together and collaborate.