Welcome to the Design and User Experience team

    From The Document Foundation Wiki
    This page contains changes which are not marked for translation.


    We provide information on these pages about what we do, how we work, and how you may contribute. We have task for everyone who is interested to join.

    What we do for LibreOffice

    User experience design (UX) is the process of enhancing user satisfaction by improving the usability, accessibility, and pleasure with LibreOffice products. It encompasses traditional human-computer interaction design, and extends it by addressing all aspects including branding and design.

    Usability engineering is based on structured methods for achieving efficiency and elegance in interface design. We run surveys and quick polls to get insights on how users work with LibreOffice.

    With this knowledge we start with generic human interaction guidelines. Workflows are designed with two personas in mind, Benjamin to target beginners and Eve for the advanced user. As stated in our manifesto we focus on

    • Simplicity by default with Full Functionality on demand
    • Consistency over Efficiency
    • Usability over Graphical Design

    Of course we follow all UX principles too.

    We also take care about accessibility, branding to the visual design including icons, and support the QA, marketing and development teams.

    What you can do

    The simplest ways to contribute to LibreOffice are to submit bugs and enhancement requests to our bugtracker or to review and comment on the reports of others. If you think something in LibreOffice breaks a UX principle or guideline, it's a UX bug. Learn more in the blog post about Tickets on Behalf of UX, or in general from Fabiana Simoes's GUADEC presentation about How to not report your UX bug.

    We have tasks for everyone from the very beginner to advanced developers. LibreOffice calls simple tasks easyhack, and together with the keyword “skilldesign” you may search the bugtracker.

    A number of tasks are not listed in the bugtracker for some reason. For instance, create a new page at the wiki, draft a guideline, or create a mockup are better managed outside Bugzilla. For this purpose we use this wiki. Many tasks can be done by everyone, some require creativity, and other need more usability knowledge.

    Bug reports and feature requests needing UX evaluation are marked with the keyword needsUXEval. Feel free to add your comments and even sketches to the reports. Another approach is to look at unconfirmed feature requests with a critical eye. One task of the UX team is to help decide on what features should not be added into the core application.

    How we work

    Usability is about users, so we basically observe, talk, interview, watch videos, and read comments to get an impression of what our users need.

    We start new topics with the reference to the bug tracker, followed by the description of current state and how competitors solve the problem, in order to get a common understanding. The intended features are listed formally as functional requirements and non-functional constraints to the design. With this input we scribble mockups using Penpot, Pencil, or LibreOffice Draw and eventually, after a couple of iterations and discussions, the proposal is published on our design blog to get input from the community.

    Open tasks

    We always have open tasks for creative people with no doing expertise, as well as more advanced topics for experienced usability engineers. Non-coding tasks are for instance:

    • Create new templates
    • Design new artwork such as banners, icons, etc.

    More advanced topic would be:

    • Scribble redesign mockups of dialogs
    • Draft a guideline

    All tasks are listed on our Whiteboard and Blueprints pages. And finished proposals can be found at the Whiteboard archive.

    Who we are

    We are people from all over the world with a wide variety of knowledge and different backgrounds.

    Feel free to add yourself to the list of team members.

    Get in contact