So, this is the second talk related to Open Project. I don't know if anyone went to the
talk about integrations yesterday, anybody? All right, designers, I get it. So, this is
Practical UX at Open Project. So, I've been working there for a year and a half, and these
are musings about the things I've learned, things we've gone through. It will all become
clearer in a second. I'm Parimal, and that's a very elaborate site to tell you. My name
is Parimal, and I'm a UX designer at Open Project. So, I think we can start with, I
think we can all agree that the UX in Open Source could use a little bit of work. I think
it's fair enough to say that, right? We know the reasons, but very quickly, some of the
challenges we've had. Data design. When you have data design in software, in Open Source
tends to have this sometimes. It is not necessarily intuitive, which makes it less attractive
to new users, because they're comparing with a lot of other newer tools, and they tend to
have all this shiny stuff, right? There tends to also sometimes be inconsistent behavior.
The good thing about having contributors, all sorts of contributors over the years,
is that it's open, anyone can do things, can add new features, but if you lack a consistent
coherent design language, then you do have the problem of inconsistency over time. There's
also a lack of investment in designers. Now, this is, I think in general, in Open Source
there's a lack of resources in general, right? Not always, but there tends to be this problem,
and design does not tend to also be the priority for a lot of projects. There's also this tendency
of Open Source projects being engineering driven. Not necessarily a problem, because
this can generally mean a very fully functional, very feature-rich software, let's say, but
that does not necessarily translate to beginner-friendly software, as we don't manage to again attract
new users. UX and accessibility tend not to be immediate concerns of developers if they're
not necessarily topics that concern them directly. This also means that these tend to not be
prioritized for that same reason. However, there are some positives to UX and Open Source,
and that's that UX has also taken this dark turn through all the sort of the Facebooks
and the Microsofts and the Googles, where there's a lot of dark patterns, and UX designers
and a lot of companies are encouraged to produce these dark patterns. We tend to not have this
in Open Source because we tend to want to create things that people like, and we're sort of
bound by these values. I think the fact that we're in our foster means we sort of have
these values, and there's a spirit of sharing, which is why we're all here, and things are
getting better. I think that some of the talks at foster are showing us this. That's the
sort of point of where we're starting, but then we joined Mark and I. He's not here,
but hi Mark. We joined Open Project in August 2021, and we were quite impressed because
Open Project, for quite a small company, decided to invest in two UX designers, which was quite
a big deal for an Open Source project of about 30 developers. We have a product team of the
two UX designers and the CEO. We take product decisions, but then we also try to work on
the user experience. The reason I joined Open Project, because I come from a background
of working in agencies, communication agencies, different world, was all the values that you
guys share, that we all share, and seeing that a company was willing to put the resources
in. And the goal was to improve user experience. What does this mean for Open Project? To
tell you this, I'd like to tell you a little bit about Open Project, because otherwise
you won't know what I'm talking about. Open Project is an Open Source project management
and collaboration software that looks, I'll show you the screenshots in a bit, but I thought
I'd tell you how we're organized, so you get a sense of perhaps compared to other Open
Source projects. We have about, I said we're a team of 30, about 15 devs, full stack, front,
back, all that. We've got three product people, like I just said. We've got one QA, which
I'll sort of connect to the user experience a little bit, because if we can't test, it
doesn't quite work. Business marketing, some HR, and then sales and support. That's it.
That's our entire ship. We've got two versions, the free community version that you can just
download and install anywhere, and the enterprise with the support, quite a classic model. You
can install it on premises, on the cloud. We also offer hosting within the EU, if you
don't want your data sent anywhere else. You can see some of our major clients, including
Berger-Bahn, who spoke earlier. The values that are very important to us are the privacy,
the data security, digital sovereignty. These are things that we're very, very passionate
about, as are a lot of other projects who are speaking today.
It looks like that. List of work packages, tasks. This is actually what we're using to
work on the new version that we're going to release in a couple of, well, we'll see when
it gets released. It'll be released this month. We work publicly using open projects, obviously.
You can see a bunch of features, some epics we're working on. You could filter by priority,
by status. I think you get the idea. You could go into a bug report that I submitted. This
is all public, by the way. If you find a bug, you can also submit one. You can see the description
there, the activity where you can really exchange with other users. You can tag them. That's
very important to us as well. Connect to other files. We talked about integrations. We have
an integration with Next Cloud. If you upload files to Next Cloud, you can link to tasks
and work packages in open projects. I think that's a very common view, a canvance view
if you want to drag things around. We have that too. We have a team planner. If you want
to organize your team and see who's doing what and reassign tasks, you can do that.
That gives you a sense of what the product is. Let's go to UX at Open Project. Some things
have happened since I joined, since Mark and I joined. We now have a design team. Previously,
we didn't have one. It wasn't a priority. It was quite normal as well. Now, we have
two UX designers and a test person, a QA person, Ivana. We used to do Markovs in PowerPoint.
It did the job. Now, we're working in Figma. Hopefully, we can move to Penport at some
point. We had a rudimentary style guide of HTML elements. Now, we have a growing design
system with reusable components that we're going to look at in a bit. It was quite engineering
driven. You can see that in the design as well. Now, we're working alongside devs to
get some early feedback. We're not at loggerheads. It's not devs versus designers. We're trying
to work from scratch and get early feedback. These are things that we are changing within
our way of working. We all know the benefits of better UX, but for us, we realize that
even clients that have used our software for a very, very long time, if we can optimizations,
even minor, that's worth the time and effort. Of course, attracting new users is very important
to us. We're not trying to only be the open source project management tool. We're also
trying to compete as an alternative to the proprietary tools. The challenge is, if you
read the abstract, that was something I promised and I will try to deliver.
Us designers have a temptation to want to say, be helicoptered into a project and design
everything from scratch. I see that. I'll put something on Figma. Let's do this. It's
not that easy. I think you guys know this because when you're working with an open source
project, there are certain contextual constraints, let's put it that way. It tends to be quite
large open source applications, so you can't just change one thing and propagate it throughout
the whole application. For example, the same element, say a drop down or a button, can
appear very differently in different parts of the application, but not just visually.
It might be implemented differently in all those places as well. Because again, multiple
contributors over the years, no coherent design language. Sometimes you can even have
different code layers. In our case, we have Angular and Ruby, which means the views aren't
rendered quite the same way everywhere. The time, if you come up with a new design, it
has then to be developed and that time, that's time and effort that's competing with new
feature developments, with maintenance, with bug fixing, and general dev time. You can't
just say, I've designed this, implement it, and we'll move on. You've got to balance it
with all these other things. Of course, we realize that when you design a new feature,
the requirements are very different between pro users and new users who are used to certain
ways of working. You say, oh, no, we're going to change something completely. The risk of
that is, of course, the classic XKCD, I don't know if you know this one. There are 14 competing
standards that you're like, oh, you can't have that. We need to develop a one universal
standard that works with everybody and then you end up with 15 standards. We don't want
that. Of course, data analytics helps often. It helps you get a sense of what users are
doing, what they want, whether they're getting stuck. You could use Google Analytics or you
could not use Google Analytics like we do and not have the data because it's very important
for us not to track our users. That makes our work slightly complicated because we don't
quite know what people are doing, but it's very important to us that we don't do this,
especially because, again, the data would not necessarily be within the EU.
Having said that, we managed to ship our first big feature when we joined Mark and I. It
was a notification center. We were very proud of it because we didn't have any process,
no UX process, and we still managed to do it. Because before this, all notifications
in OpenProject were email-based. If you sort of had a new work package, a feature, someone
answered it, added a new requirement, you'd get an email alert. You couldn't follow it
within the application. We designed this. Extremely proud of it. It did ruffle some feathers
because we said, all right, now the emails are only going to be digests, not for every
single notification, but some people will be used to this. We are extremely proud of
this feature, but we also learned that you've got to ease users in with these big changes.
Perhaps we need to start small. Small means sort of manageable, developable, maintainable,
testable, don't scare existing usersable. That's sort of what we mean by small, reasonable,
in other words. So when you want to change these things, there's a couple of different
ways to go about it. You can change one thing everywhere in the application. So let's say
a button. The button that we had doesn't quite work. We want to change it. We want to make
it better. You could make that button the same, the new version, everywhere. But then
individual pages would not be consistent, right? Or you could change everything in one
page. It takes the settings page. We're going to update it with new components. We're going
to make it standard. But then that standard, across pages, it's not very standard, is it?
You just changed the problem a little bit. So the approach we've gone with is we want
to standardize the elements first. Remember how I told you that the same elements could
be implemented in different ways in different places? Well, what if we first standardize
the implementation, the HTML, the actual code of that element, and then we can modify it,
can we, once we come up with some sort of consistent way of doing it? That'll also help
us understand how these elements are being used and the different variations we'll need.
I'll give you an example. For a design presentation, this will be a lot of words, hasn't it? More
images, please. This is the date picker that we used to have, and that's the date picker
we have now. We changed it because we introduced a new feature, which was taking Workweek into
account, so sort of being able to say that Saturday and Sunday are holidays or could
be a Friday, depends on your company. So when we did this, we took the opportunity to upgrade
it, and beyond this sort of aesthetic change, you'll notice that was an opportunity for
us to then work on all these elements, to try to better define what a button should
look like, what an action bar should look like, what the blue, when you time across
the application and you're changing the focus, what that should look like, because that wasn't
very consistent either. So we took this opportunity, sort of new feature development, to create
these components, and not just things that are visible, but also things that are invisible
like this, which we didn't quite have in the past. So that does mean that for now, you
won't find this in all across the application. They're parts of the application that don't
respect some of the things we've defined, but we're going iteratively one step at a
time. And to do that, we need a design system. We call it the single point of truth. So
it's a spot, and if there's a component that has not been included in the design system,
we say it's not been Spotifyed. They can't really sue us. So what is a design system?
For us, it's sort of a consistent, dependable, reusable and documented set of things. These
things could be styles, colors, spacing, things I showed you. Could be components like buttons
or text boxes, any of the little components that bigger interfaces are built out of. And
then patterns that are a combination of these things. And the last bit is very important.
You've got to then document it and tell people how to use it, when to use it, what to do,
what not to do. And of course, as being an open source company, we publish all of it
in our website. So anybody can go and look at it. So now when we say spacing to, everybody
knows the developers, designers and the testers know what that spacing should look like. Same
thing for action bars, with the different variants. And then we go to our website and
then we try to explain those variants and how to use it. And this is public in our website.
It's not complete yet. We're still working on our design system. So now all elements
are there. But we are working on it. How's the speed? Am I speaking too fast for anyone?
It's all right. Okay. Well, I'll take a bit for break and bring some water. You can appreciate
our design system. So in some startups, they say build fast and break things. We can't
afford to do that. That's not our mantra. Our mantra is to build slow, iterate and test
things. I say test things. We've not quite done it yet. That's our goal for this year.
So we want to balance UX optimizations with feature dev. But like I showed you with the
date picker, perhaps if we spend 40% of our time with feature development, we take that
as an opportunity as well to optimize and maybe choose five core elements and then sort
of fold them into our design system and try to make those consistent. Which requires sort
of that means that there will be imperfection and there will be inconsistencies within the
application. Our goal is to accept that imperfection and to keep moving. Because again, the developer
doesn't like when things are inconsistent or some developers want it to be pixel perfect.
Well, sometimes it's not going to be. And for those of you who speak French, the better
is sometimes the enemy of the good. And sometimes you got to accept the good enough to move forward
to where you want to be. Very philosophic, I know. So the learnings for the past year
and a half, it's very happy to be able to put that half symbol there. I thought it looked
quite cool. So the first thing is you can't just join a project, be helicoptered in and
magic won the whole thing and say, great, we want to just change everything. Let's do
it. Upgrade it to 2024. You need incremental upgrades because you need everybody in the
company to believe in what you're doing. Be convinced it's worth the effort. And luckily
we have that sort of project. But it's not an easy thing to do because there are competing
requirements, competing priorities and how companies should use its time. So that's important
to accept, incremental. Standardizing things now means a lot of time spent now. But down
the road it gives us more time to do more relevant work. It's less time because things
are already standardized. If we change the color, if we change the design, it will change
all across the application. We need to be pragmatic, try to make something a little
better with every release, not go for everything in one release. But sometimes we do want to
go for those big changes like we did with notification center. It might ruffle some
feathers, but those changes are required because we have a vision for where the product needs
to be. However, we've learned, perhaps the hard way, that we need to ease our users in
who are used to the old system, help them understand why we're doing it. And in that
regard, we also plan on communicating more from the product team, perhaps publishing
the why and the how of how we work, why we take certain decisions. And finally, we could
learn from other open source projects as designers, I mean, because developers do it quite a fair
bit. I don't think we quite have that culture amongst designers. And we're currently working
on theming, and I saw a presentation by Matthew, Matthew Brea from Proton, who was in Paris
where it was last year. And he was explaining how his company worked on theming and all
the things that he did that were wrong and where he learned from. And we were able to
use that and learn from it, and that helped save us time, sort of get a better sense of
what we were doing. So thanks to Matthew, who's not here, but I think that that sort of sharing
is very important. We should do more of that. And we really hope that this presentation
maybe hopefully one day can help someone as well. So what are our plans for 2023 then?
More UX. Shocking, I know. So more UX, so more work on the design system, continue working
on it rather. More testing, because we've not really done any testing now, we haven't
had the resources, but that's one of our plans. Even a basic hallway test where we ask five
people what they think and if they understand the feature, is some input. We want to integrate
more with other tools. Part of doing that is to take the design system and make it easy
for someone creating a plugin or trying to integrate with OpenProject to use those design
elements as well. So that's one of the reasons we're working on the design system as well.
And of course, better theming like I just mentioned, and accessibility is something that we have
in mind, but we could do a lot more. We could be a lot better at that. So that's one of
our goals. And of course, we've got the usual suspects, the ongoing optimizations, and new
features along the way. The goal, of course, then is to have more users who say they picked
up OpenProject for the UX, not just because it's open source. Of course, we want them
to pick up OpenProject because it's open source, of course. But if they say we try to
do a bunch of tools, we think you guys have really good UX, that's our goal. But why
do I stop there? Let's go further. A broader goal, broader goal, is to build an alternative
to Microsoft 365 with all the other actors, some of whom were here, fast and right. So
next loud, OpenExchange, Elements, XWiki, Collaborer, with all these other players, let's give users
an alternative that's respectful of their privacy, that is open source, and that respects
data sovereignty. And if you're passionate about these things, I'm certainly not telling
you that you should, you know, that these companies are hiring, but they might be. Just
saying. Thank you very much for giving me some time. And if you have any questions, I'll
take them now.
Thank you. Yes. A lot of what you said reminds me of when I was at the OpenProject network
doing some of the things that we were built on, like Spray, and it was very, like, component
messy, change it here, but not change it here. My question is, how beneficial or not is having
your CEO on your product team? That's a great question, actually, because it's, for us,
it's, designers can also go too far. So we can also have, because we want to change things
very, very quickly, but there are some very pragmatic questions that are also development
related, but also, let's say, related to the product roadmap. We think it's quite helpful,
because then we can have the discussion internally and align ourselves rather than be at loggerheads
again with, because, like you can have designer versus developer, you can also have designer
versus product. So we try to avoid that. So we think it works well. Yeah. Yes. Sorry.
So the organization I work for, my university, I've been paying enterprise users to open
projects, probably like a year and a half, two years. Glad to hear it. So I use it, like,
every day. I really like it. Universally, 100% of the negative feedback I've received
from my colleagues on OpenProject have been explicitly related to the UX. Yeah. And so,
and then pretty much all the positive feedback I've gotten from my colleagues have been related
to specifically the UX improvements that you showed like last, you know, 10 minutes. So
these improvements are really important to us as an organization, but I realize that
especially in open source products that are oftentimes very privacy focused, from my perspective,
it seems like usually it's a very lab-first adopters. Yeah. Priority among all of the
customers, regardless, because there's just not an easy way to measure. Do you have any
suggestions as an organization that's paying for the product that really appreciates this
work and wants it to be done by, I don't know, like your boss or someone that, you know,
this work is important to us and matters and what. Okay. So I'll try to repeat the question.
Yeah. So you said that one of the biggest complaints with OpenProject was the UX and
some of the positives in the recent times have been related to the UX. And the question
is, sometimes the early adopters tend to be the loudest and tend to get heard the most.
So how do we get better at listening to the community in general? Yeah. Okay. Customers
of OpenProject. So what recommendations would we have to them? Well, we have two things
we can say. First of all, our community discussions are open. So if you feel very passionate about
a feature or a certain optimization, we really welcome that feedback and we will engage with
you. It can be sometimes a bit tough to be on all fronts. So sometimes it's true that
feedback can be a bit lost. We tend to track it with both an OpenProject. But our biggest,
perhaps a recommendation would be to engage with the community directly via, yeah, via
community. And also if you have an idea, submit a pull request. That's also very, but that's
not fair for a lot of people because, yeah. Well, thank you for using our project. Yeah.
Yes, we will, we will test more. We'll start small with how we test. And this quarter actually
we have quarterly goals and so I'll go to test more. And there's a question back there.
Perhaps it's the last one. Hi.
Do you respect the science to come to your projects being open source in the US? How?
Oh, other designers contribute. Oh, we've not had that yet. That's a good question. We
might have to talk about it. So we have our design system that's quite open and everything.
I mean, you could submit a pull request for pretty much anything, including our design
system, but we've not quite had external developers. We are obviously interested so
we can talk. Yeah. Thank you. Do we have time for more questions or are we? One more question
if there is. Oh, hi.
Thank you. Thank you. I'm curious since you haven't done much user testing so far, you
mentioned, how have you been able to prioritize or how have you decided on what, for example,
things you want to release first like notifications? That's, that's, yeah, that's a good question.
When we first arrived, there was a question of what the priorities should be. But there
are a lot of issues with Open Project through feedback we've got from our users that we
already know about. We already have a backlog that's, I wouldn't say considerable, but we
do have a backlog of known issues. So we thought we'll work on those first because we know
that customers have told us that there were certain improvements and notification center,
which was a passion project actually initially within the company. But it was also because
we got some feedback about improvements that we could do. And it was also a feature that
I think was quite required. It's quite a basic feature as well. So we were very happy to work
with it. Thank you, everybody. And if you have any questions, we can get them.