This is a working document to expand on ideas and themes we should explore in our design manifesto and core values. Please note that at this stage, they are in no particular order.

Powerful but intuitive

OpenProject is a complex, powerful tool. One of its key strengths its customisability and its ability to adapt to a range of different needs. It offers users a high level of control and advanced features to allow them to tailor the tool to their needs. This includes complex filtering options, custom statuses, custom fields and a range of work package options.

Nevertheless, it is very important for ensure that OpenProject is intuitive for new users who might not necessarily need that complexity, or indeed be overwhelmed by it.

Our design approach to deal with striking the right balance between making something powerful versus making something easy to use is to have a two-tiered approach: apply sane defaults by standard via an intuitive and straightforward view, but allow advanced users the option (accessible via an additional click) to dig deeper and customise should they wish to.

Desktop-first

OpenProject is not primarily designed for mobile use or with a mobile-first approach, despite the software adapting fairly well to smaller screens in most cases. The majority of features and views are designed to take advantage of a larger screen and more complex interactions (including keyboard shortcuts).

However, we recognise that certain features are particularly adapted to and are useful in a mobile context. These might include accessing notifications on the go, viewing work package contents. viewing and responding to comments and changing a work package attribute. These features will be given particular attention to make sure they are optimised for mobile use.

We consider project planning, scheduling and organisation to not be priority use cases on mobile.

The UX of Open Source

OpenProject has evolved considerable from the time it forked off ChiliProject and Redmine. As an open source project with a considerably long history and a large number of contributors, it still has parts that could be considered "legacy", or parts that have evolved at different paces. There are also similar components that are implemented somewhat differently in different parts of the software. This is quite normal for a large open-source project.

One of the goals of the design system is to introduce more coherence and bring the design up to date. Ideally, we would be able to update everything at the same time and push the new design system to the entire software; nevertheless, we recognise the need for a more pragmatic approach. The design system will be rolled out in phases, with a careful study of the consequences of updating each component or UI token, and the potential dependencies that will be affected.

We recognise that UI/UX has not always been the highest priority for open-source projects and is often neglected, which is somewhat understandable given how open source projects have relatively fewer resources dedicated to it than commercial products. Our goal is to do our part to improve that situation as much as we can, and document our process in the hope that it might help other open source projects looking to implement their own design system.

Accessibility

• Try to support contrasts, font sizes, screen reader compatibility
• Vision, Auditory Sense, Motor Function and Cognitive Ability

Localisation and internationalisation

• We work English-first and then work on translations
• Let the community participate in the localisation too?
• Make sure design decisions are not taken with only English in mind (in terms of text length, writing direction?)

Design Values

• Provide designers with internal standards for evaluation, enlighten and inspire the design principles and design patterns, and then offer guidance and general solutions for specific design problems.
  • Natural
  • Certain
  • Meaningful
  • Scalable
  • Intuitive
  • ...

Branding

• Basic explanation an resources on the branding of OpenProject (logo, colours, typo, iconfont...)
• Brand family (BIM...)

Voice, language and tone

• Definition of the tone and voice used in our products that can be used in multiple languages.
• Usage of acronyms, terms, file names, folders, lists, person and pronouns, titles, capitalisation...
• Usage of numbers: ages, dates, years, numerals, fractions...

The power of this Design System

• Short introduction and points on whats the main advantages of the Design System (consistent, empowering, reusable, scalable, install and go...)

The products and platforms

• Which products and platforms are using currently the DS

The team

• Who is OP and who is behind the DS

Governance model

• How to use it
• How to contribute
• How to maintain

Playbook

• Discover, define, design and deliver practices, methods, meetings and workshops. (https://design.workday.com/playbook)

What's New (release notes) and Roadmap

Naming and shortcuts

• Define how we call tokens and components including its shortcuts and namings