Towards a UX Strategy for GNOME (Part 4)

This post is part of my blog series on GNOME UX strategy. The other parts in the series covered background research and analysis for the strategy, then outlined some high-level goals and principles, followed by an outline of recent design work which fits within the strategy. This can all be thought of as answering “what” and “why” questions: what should GNOME be doing, and why?

In this, the final post in the series, I’m turning to the question of “how”: how can the GNOME project can deliver all this? For me, this how question is just as important as the what and the why. Having an effective strategy means nothing if we can’t successfully deliver it.

This post is primarily about design and development process. I’m going to draw on my experiences working on the GNOME project, as well as methodologies from the wider software industry, and recent experiments that have taken place in the GNOME project. Agile is clearly present, but it’s just one element, and has necessarily been adapted to an upstream, open source context.

While these reflections on development process are an important part of the strategy I’m laying out, they hopefully have more general relevance to our work in the GNOME project and beyond.

The process matters

The naive view is that software quality is primarily determined by the character and skills of the individuals who have worked on that software. While these individual capabilities are undoubtedly important, they are only one part of the story. Indeed, I would argue that the design and development process is just as important as the skillset of those doing the work.

One reason for this is that UX work is never a solitary endeavour – it involves multiple people with different specialisms. How we work together is critical to success, because each of those specialisms don’t just need to be aligned, but also need to feed into one another.

In my time working on GNOME, I’ve been involved in some really successful UX initiatives, where we’ve delivered new features or updated versions of our software, in a way that has pleased and even delighted our users. I’ve also worked on initiatives that haven’t been successful. I’ve reflected on these, and have identified a number of recurrent issues. These include:

• New features that have been delivered in an incomplete state
• Implementations that have significantly deviated from the intended design and UX vision
• Usability or design issues which have been identified post-implementation, and have been subsequently unaddressed
• Designs whose ambitions have surpassed our engineers’ abilities to deliver them
• Rough and ready designs that have gone on to be implemented before they have sufficiently matured
• Designs which have been incompatible or out of alignment with the technical plumbing that they’re built on top of

I’ve previously argued that driving up UX quality is critical to the future success of the GNOME project. If we are to do this, issues like these have to be eliminated from our development practices. We can’t succeed if they occur in core development initiatives.

The good news is that all of these issues stem from the design and development process, and can therefore be avoided. This is also a real opportunity to learn from the wealth of experience that we have in the GNOME project, and develop best practice approaches.

What we need to do

There are three main things that I think we can do to improve our design and development processes.

1. Embrace iteration

A great man once taught me that design is all about iteration. He wasn’t wrong: designs that have passed through a lot of revisions are usually superior to those that haven’t. The same is true for software development.

Many of the issues that I identified above are a result of a failure to incorporate iteration into the development process. Iteration is key to eliminating bugs, but it is often also critical to ironing out larger design issues. Despite all our expertise and experience, it is impossible to anticipate every potential UX issue, or fully understand how a design will perform in practice. We therefore have to assume that many implemented features will contain issues that have to be addressed.

The first and most important step in embracing iteration is to change the way we think about the design and development process. Iteration has to be treated as being essential and non-negotiable. The time and resources that are required for iteration must be accounted for at the outset, with the first implementation being seen as just one step in the process.

If you, as a designer or a developer, don’t have the time to iterate on a piece of work, you probably shouldn’t be doing it in the first place. I’ve been guilty of this is the past, and it can be a hard habit to break. It’s so tempting to make drive-by design recommendations, or quickly implement a new feature that you’ve been wanting for ages. We must all resist that urge. High-quality software takes time and care.

The other way to embrace iteration is to build user testing and feedback into the design and development process. This isn’t hard to do, and has been successfully done in the GNOME project. For example, earlier this year, Clarissa Borges successfully ran user tests on a development snapshot of Files, which allowed us to refine design changes prior to release. Another example: right now, we are using paper prototypes to get real-world feedback on potential Settings changes. These tests can take mere hours to design and conduct, and can save weeks of developer time.

2. A closer relationship between design & development

Design and development aren’t separate domains. Designs need to reflect technical realities. Developers need to be familiar with the UX vision that they’re implementing. Designers need to be involved in the development of the underlying technologies and platforms. This requires shared understanding between designers and developers, at all stages of the process.

A good number of the issues I identified earlier in this post are what happens when that shared understanding is missing. This leads to all kinds of problems, like designers over-estimating what developers can achieve, or not fully understanding the technological constraints, or developers implementing something different from the UX vision.

It has become my firm belief that the more interconnected that design and development are, the better our software will be. A close relationship between these two specialisms prevents problems, helps shared understanding, and increases efficiency.

I’m going to describe four things that we can do to bring design and development more closely together.

First, we need to ensure high-bandwidth communication between design and development, throughout the process. This communication doesn’t have to be talking or messaging – it can be sharing of mockups, screenshots and screencasts, and testing of development code – but it does need to happen frequently.

Second, designers need to treat developer resources as a design constraint. Design work has to be speculative sometimes. However, when it comes to sitting down and implementing features or changes, it is vital to fit the design to the amount of developer time that’s available.

Third, we need to champion transparent design. Transparent designs reflect how the underlying technologies work, and don’t try to present a different picture. They are good for all the reasons that reducing technical complexity is good, plus the fact that they avoid leaky abstractions. Transparent designs sometimes expose issues with the underlying technical architecture, which can be painful, but also exerts pressure in the right place.

Fourth, designers need to get their hands dirty, and touch the code. This can take many forms, including using GTK for prototyping, editing CSS or GtkBuilder files, or making simple code changes. This is hugely beneficial! It’s vastly more efficient for designers to make simple changes themselves, rather than having to go back and forth with developers to make them on their behalf. In turn, these efficiency savings enable a higher level of precision and quality, since they allow designers to be far more specific and wide-ranging in their polish work. Having designers directly involved in development is also a fantastic way to improve the platform, since it makes us aware of how it works, and makes us even more invested in improving it.

To make this last point happen, designers need to push themselves to get involved in development (I have a rule for myself: don’t ask someone to make changes you couldn’t have a go at making yourself). However, we also need developers to make their projects designer-friendly. This means using things like CSS, GtkBuilder, and high-level languages.

3. Time-Based Coordination

The third and final thing that we can do to improve our design and development processes is to coordinate around blocks of time. Coordination for upstream projects is tricky. However, for many of the things that I’ve described above, we need to have shared expectations for how and when work will be done. It is only then that we can do things like testing of in-progress software, or have conversations about how much developer time is available for a particular initiative.

One possibility here is to organise ourselves around sprints, and Georges has spearheaded some really successful experiments in this area. It’s a simple idea: he divides his time into blocks, and gives the design team advance notice of what he will be working on and for how long. We can then ensure that he has the designs he needs. We can also ensure that those designs can be implemented in the time he has available, and even arrange testing to happen in the periods between time blocks.

It would be great if more developers embraced this approach!

Conclusion

It’s taken a while, but we’ve got to the end! If you’ve stuck with me for the entire blog series, well done, and thank you. I hope you’ve found it interesting, and maybe even useful.

For me the best outcome of this series would be if some of these ideas could be taken up more widely by the GNOME project (or other Free Software projects), and I’d love to discuss strategy or development process with other contributors.

This last post has been especially important to me, because it reflects my own developing practice and concern with successful UX delivery. I genuinely think that these techniques could revolutionise how we work, and am already seeing some major improvements through their adoption.