How is Unity designed?  How can I contribute to this process?  Why did you make thus and such decision? The Unity Design Team is frequently asked these questions, and this article aims to de-mystify our design process and highlight the different ways in which volunteer contributions can help improve the Ubuntu user experience.

Before diving into the design process, let’s take a look at the types of contributions Ubuntu receives.  Ubuntu contributions can be divided into two equally valuable categories: whole project contributions and piecemeal contributions.

Whole project contributions are autonomous projects created by a single developer or a group of community developers and designers working together.  One example of such a project is the excellent http://ubuntu-tweak.com.  Some user experience design tasks require frequent ongoing high bandwidth dialogue between design team members; this is easier to achieve when a small group of contributors take responsibility for the end to end delivery of a project.  Whole project contributions empower the project contributors to take complete control of all aspects of the user experience design.

Piecemeal contributions are contributions that help one individual aspect of a larger project.  Examples of piecemeal contributions include bug reports, small patches and suggestions on how to improve public design specifications.  Coordination is required to ensure that the piecemeal contributions fit together into a coherent whole.  Thus some of the user experience responsibility is ceded from individual piecemeal contributors to the project’s steering team.  In the case of the Ubuntu desktop, the design decisions are coordinated by the Unity Design Team.  In this environment, many elements are contributed by external designers and developers, but the areas of user experience design that require high bandwidth, frequent communication are dealt with by the Unity Design Team.

1. Divining the future

Before we get started on designing anything, we need a long term vision and strategy of where we want to be in several years time, and a high level roadmap of what we need to do in order to get there.  My personal take on the Ubuntu vision is that Ubuntu aims to “help humanity by creating a fully open source free software platform that becomes the platform of choice for all computing devices and form factors”.  By virtue of reading this article you are probably one of the small minority of the population who cares and feels passionately about the benefits of open source computing.  But when the majority of people consider buying or using a product, they make a decision based on cost, personal utility, and user experience.  ‘Open source’ versus ‘closed proprietary software’ doesn’t often come into the equation.  So if we are going to succeed in making Ubuntu the platform of choice for the world, one of the things we need to do is deliver a user experience that surpasses the standard set by our closed source proprietary software competitors.  And to do this we need a vision to aim for, of where the world is going to be in 2, 5, and 10 years time.

To help shape our strategy and roadmap we listen to what the brightest minds are saying by:

• attending conferences
• reading articles, blogs and forums
• watching people’s behaviour
• reading and watching sci-fi books and films
• and trying to live observant, interesting lives… 😉

How you can be a visionary and help shape the world

If you have a vision of the future or ideas about new ways of doing things, make yourself heard.  Everything from talks at conferences to ideas posted on http://brainstorm.myasnchisdf.eu.org/ are thrown into the Ubuntu mixing pot, so if you have a great idea, tell people about it.  The more time invested in exploring your idea and communicating it to the world the more influence it is likely to have; a paper presented by a PHD student who has spent a year exploring a particular topic has a better chance of being influential that one or two forum postings.

2. The first step in designing a feature; what problem are we trying to solve?

The development of a feature starts as soon as resource becomes available.  After selecting the next appropriate item from our roadmap, the first questions we ask are “what problem(s) are we trying to solve?” and “what are our objectives?”.  One useful tool to help define the problem is to explore the problem using user narratives, and think about the impact of the problem on different personas (user archetypes which represent patterns of behaviour and common goals).  Another useful tool is to undertake requirements capture with members of the target audience.

How you can contribute to defining the problems

If you are suggesting either a new feature or a change to existing functionality, first state the problems you are trying to fix.  This opens the door to exploring different possible solutions, and ultimately finding the optimal way to meet the requirement.  Including user narratives in bug reports/mailing list postings/etc… can open up productive discussions that explore different ways of tackling the problem.  They also make it easier for others to understand the problem you are investigating, and therefore improve the likelihood of a solution being built.

3. What thinking has already gone in to trying to solve this problem?

Once the problem that we are trying to solve is clearly defined, the next step is to assemble the previous thinking that has gone into the problem area.  Understanding what has gone before and the current state of the art is the starting point from which new connections can be made, concepts built upon and extended, and new ideas created.  Mailing lists, bug reports, and forums are scoured for pertinent information and products relevant to the problem space are examined.  In addition to the collation of previous thinking, fresh research can also be conducted to generate new insights.  This solid understanding of the existing problem space is a elemental ingredient of the design process.

How you can contribute to the background research

If a discussion on a design problem is taking place, either in your own project, in a bug report or on a mailing list, feel free to add pertinent information from related fields or descriptions of how others have tackled related problems.  Throwaway opinions are cheap, but considered  background research is a very valuable contribution.

4. Ideation

Ideation requires high bandwidth communication between all participants, both for the rapid expression and debate of ideas, and to ensure that everyone in the multi-disciplinary group rapidly gains and retains a shared understanding of the problem space.  When starting a new project at Canonical, we have found it very beneficial to get all the developers, visual designers, UX architects, etc… who will eventually work on the new feature together in a single physical location and spend a week brainstorming and exploring ideas.  In addition, these design exploration sessions help gel the feature team together, and the interpersonal bonds that are established improve team communication and set a positive tone of discourse that persists throughout the entire course of the project.

During these ideation sessions, we:

• Spread out all gathered information and explore patterns and structures.
• Jointly brainstorm and sketch ideas.
• Discuss all areas of the problem space, propose and iterate multiple ideas for tackling all the different aspects of the problem.
• Examine the problem from different angles; user costs and benefits, technical possibilities, strategic direction, competitive landscape, fit with roadmap, etc…

At the end of this stage we will have a collection of ideas for solving the problem.  And this collection of ideas will have been discussed and examined by the whole feature team.

How you can participate in ideation

At a small scale you can make piecemeal contributions to ideation by participating in bug report discussions and offering different ideas for solving the problem.  As a larger scale you can get involved in ideation by joining or starting a community project team that is focused on delivering a feature.  Propose an idea, gather some developers and designers together, and start your design process!

5. User Experience design

User Experience design starts with the ideas generated in ideation, and through an iterative process evolves the concepts and fleshes out the interaction details.  Typically a UX architect will take the lead on designing a feature, and as they work through this process they will continually bounce ideas off other members of the feature team and other designers.   User testing is also utilised to provide feedback and inform the evolution of the design.   The UX architect’s work will also be reviewed with the overall UX lead to ensure consistency and linkage with all the other projects that are being designed and developed in parallel.

User Experience architects have a number of tools at their disposal for designing and defining the functionality of a feature or product.   Multiple tools are used simultaneously in order to approach the design from different perspectives; for example wireframes show grouping and hierarchy of elements at a specific moment in time, so they are frequently combined with use cases or sequence diagrams to ensure that the user journey centric viewpoint is also considered.

For very tactile and interactive elements, designing through prototype iteration is an invaluable technique.  An example of this in action is the recently released launcher reveal prototype.   In addition to defining the functionality, user experience design also involves taxonomy, association mapping, and personas.

How you can participate in User Experience design

As user experience design builds on top of steps 1-4,  before starting the first task is to make sure these preparation steps are complete.  In the case of adding a piecemeal UX design contribution to a bug, this involves reviewing the bug discussion and satisfying yourself that these preparation steps have been adequately completed.  If you are working on a whole project, make sure that all the previous steps have been conducted jointly with the other members of the project team.

Then start designing!  Look at design patterns that can be utilised, and keep an open mind by looking at mobile and web patterns in addition to established desktop design patterns.  Some good starting points are ‘About Face 3: The Essentials of Interaction Design’ by Alan Cooper, ‘Designing Interfaces’ by Jenifer Tidwell and also the pttrns mobile app design pattern showcase.  Approach the design from different perspectives; to learn more about the mechanics of using use cases to take a user journey centric approach I recommend the excellent ‘Writing Effective Use Cases’ book by Alistar Cockburn.  And keep looking at the design through the eyes of the personas you are targeting, otherwise you may end up designing the product just for yourself!

The artifacts you produce will vary depending on the projects requirements, but should include at the very least elements of layout design (wireframing), functional design (use cases, prototypes, etc…) and Information Architecture (hierarchy maps).

6. Visual design

Visual design is the marrying of form and function, it affects user confidence and comfort and makes for a compelling experience.  As we work through each level of the design process, we are both iterating the design and adding further detail.  We start with coarse brushes making wide strokes and work our way to the point where we are using fine brushes to refine the final intricate attributes.  Human beings perceive visual information before they perceive analytical information, and Visual design is about reducing the mental workload for our audience whilst delivering a delightful and cohesive aesthetic experience.

How you can participate in Visual design

If you are working on a whole project contribution, fire up your design programs of choice and start iterating the visual design!  For piecemeal contributions a great place to start is theme, icon and wallpaper design.  For a good example of a great community visual design contribution take a look at the Faenza icon theme by ~tiheum.

7. Implementation

Development resource is the biggest bottleneck to getting new features implemented, so the most valuable way you can make piecemeal contributions is by taking items from the bug list and submitting patches.  Implementation is also part of the design process, because as a feature is built even more understanding is gained and further refinements are iterated.

How you can participate in implementing new features and fixes

Pick a bug from underneath either the “Design changes signed off but not handed over” header at http://people.canonical.com/~platform/design/ or “Upstream projects that can be worked on” at http://people.canonical.com/~platform/design/upstream.html .  If you have any questions about a bug ping either myself (JohnLea), swilson, or nuthinking in #unity-design on Freenode IRC .  The Ubuntu wiki Unity page is good place to start finding out more about how you can help with the implementation of Unity.

8. Identifying user facing bugs and QA

After a feature lands it is time to start identifying bugs.  A good starting point is to look at the UX specification of a feature, and check that the implementation matches design.  Where there is a divergence, citing the relevant part of the specification in the bug report is both useful and will also raise the bug’s priority.  On the other hand, designs are never perfect and it may be that there is a bug with the design itself.  In this case it is also useful to cite the issue in the relevant UX specification as part of the bug report.  Unity UX specifications are available at http://design.canonical.com/the-toolkit/ , and we are currently working to increase the number of specifications that are publicly available.  Also all the design bugs that are currently queued for implementation are publicly available at underneath the “Upstream projects that can be worked on” header at http://people.canonical.com/~platform/design/upstream.html .

How you can participate by reporting bugs

If you are reporting a user facing bug affecting any part of Ubuntu, make sure the bug is marked as ‘also affects project’ ayatana-design.  The bug will then be triaged by the Unity design team, and if accepted it will enter the stack of bugs that are awaiting implementation.  Sometimes a bug will be marked as ‘Opinion’.   This means that the issue is acknowledged but the exact change request detailed in the bug is not currently scheduled for implementation.  This may be because further consideration is required, or because a project that will fix the bug in a different way is currently in the pipline.  Bug reports are one of the most useful ways you can contribute, every single bug that is reported to ayatana-design is reviewed by the Unity design team.

9. User testing

This will be coming soon in a subsequent article…