Recent posts from Jason Taylor

We had a recent visit from the National Computer Science School (http://www.ncss.edu.au/) where students experienced the software development environment first-hand. We made them some funky t-shirts and I was to believe that was the end of my responsibilities for the event. Our very own Chris Owen (Senior Confluence Developer) had other ideas! Chris asked if I would write a post on: my experiences as a user interface designer; and ways to get started in the industry. This post is for all the future user interface designers out there!

When I started out, the position of user interface designer didn't really exist in Australia – there certainly wasn’t any tertiary education available. Trained in traditional graphic design at TAFE, our year were the first to have computers - of which, no-one knew how to use (especially the teaching staff!) My computer class was spent helping classmates as I was already comfortable with using computers to design and illustrate - this was a time when Letraset was all the rage and our use of computers would predominately involve typesetting. We would create an illustration by hand, create typography on the computer, print it out, and then trace it on to the illustration to be inked or painted. We really had to work things out ourselves!

Fortunately, I answered an advertisement for a graphic design position within a software company developing trading applications for Reuters. I attended the interview and got the job - causing much consternation among my peers and teachers who, at that time, didn't comprehend what I would be doing (neither did I really). They wondered why I didn't want to work in advertising as a graphic designer.

While at the software company, I was lucky to have a Manager who understood human factors and really helped to develop my skills in that area. I began attending all the courses on user interface design that I could find, leading me down the path of user-centred design. User-centred design is a method that involves end-users and client stakeholders in the design process. It's an important discipline to understand for any flavour of designer.

Becoming involved in user-centred design, with a background in graphic design, enabled a multi-disciplinary approach and opened a few more doors then otherwise possible. Generally speaking, the roles involved in user-centred design include: user researchers; information designers; interaction designers; and visual designers. The people working in user-centred design arrive from many and varied disciplines that include: psychology; anthropology; business analyst; technical writer; industrial design; and of course graphic design.

Over the years my experience has grown with the industry and includes: an innumerable amount of research sessions with users; working with some of the smartest people in the business; attending and presenting at conferences; teaching user-centred design; and developing online visual styles for many large corporations. Arriving at my present location involved: a fair portion of luck; some time spent unemployed; and a lot of trial and error. For those of you just starting out there’s no shortage of user interface design work, however, there is a shortage of talented user interface designers!

My experience as a user interface designer has included consultant roles on projects that differ from client to client. Consulting provided a huge level of variety and helped to build an excellent understanding of the end-user and their experience with my designs. My preference these days is to work in-house where, over time; I can gain an in-depth and detailed understanding of how our products are used and hopefully, provide a satisfying experience for our customers.

Consultant or in-house designer aren’t the only divisions in user interface design, there’s a wealth of disciplines to encounter whether you prefer: academic pursuits and research; talking to and understanding people; making pretty pictures; or just making the world a better place to live in. It’s really down to what you want to do!

About Jason
I work in the Design team - a small group of three that includes: a Designer (that’s me); a Junior Interface Designer; and a Design Engineer. While we don’t employ strict user-centred design techniques, we do draw from a wealth of knowledge gained through my experience as a user researcher. We also eat our own dog food - meaning we use our own products and all design work is implemented on our company Extranet to be critiqued by one and all. You can find me on Linked In: http://www.linkedin.com/in/gooey

To get you started in user interface design here’s a small list of useful resources:

Australian companies:
The Hiser Group (www.hiser.com.au)
Different (www.different.com.au)

Professional associations:
OzChi (www.ozchi.org)
Usability Professionals Association (www.usabilityprofessionals.org)

Very useful reading:
The Design of Everyday Things by Donald Norman (http://www.jnd.org/books.html)

Method

The process for designing the Page Restrictions user interface in Confluence involved:

• Collaborative design with the Confluence developers and Technical Writer.
• User walkthrough with a sample user and paper prototype.
• Iterative development through a variety of feedback sources.

Understanding the model

One of the key challenges for this project was to understand and usefully implement Inherited Space Permissions.
Following is a diagram used to illustrate and discuss Inherited Space Permissions.

Permissions versus Restrictions

A minor challenge for this project (and the participants) was the difference between Permissions and Restrictions. Page and Space security in Confluence is set by granting permission to a user, however, in this instance we wanted to restrict certain users from viewing or editing a page - turning the entire model upside down. We found in the early stages that it was quite easy to slip back into conceptualising the model as permissions based. We also found the same problem when walking through the user interface with our sample user. We amended the problem by labelling interface elements appropriately.

Initial Designs

Following are a set of designs that illustrate the evolution of the Page Restrictions user interface.

	The first cut of the design followed the existing Page Permissions user interface. At this point we attempt to illustrate the inherited Space Permissions.
	Inherited Space Permissions are illustrated to their full extent within this design. The design at this stage is overly complicated and very hard to use.
	Another attempt at illustrating the Inherited Space Permissions. At this stage we decided to look at other ways to include or display this information.
	We're getting closer to a viable user interface solution with this version. The Inherited Space Permissions are simply listed within the 'Type' column of the table.
	Inherited Space Permissions are now illustrated within a separate table and positioned above the Page Restrictions to indicate the hierarchical relationship. Labelling and language has also evolved to provide the user with more context as to the function of Page Restrictions.

User Walkthrough

Context...

This walkthrough was performed with a single subject utilising a 'working' prototype of the Page Restrictions functionality. This walkthrough was highly informal and the subject's experience with the Confluence wiki was of a medium-level.

Scenario...

HR would like to hide a page (in Confluence) containing confidential information. This page would be hidden from the organisation and only viewed by the HR Director and the HR Administration Assistant. Additionally, editing of this page would only be done by the HR Director. HR is especially concerned about the confidential nature of their page content.

Findings...

• When presented with the scenario, and a page on Confluence, the "Restrictions" function was found quite easily.
• The section on Inherited Restrictions was unclear and potentially confusing as it required a deeper understanding of Permissions and Restrictions on a Space level.
• Choosing the "Users" link was accomplished quite easily, however, as the 'Users' dialog didn't appear immediately, the subject then proceeded to enter a users name into the entry field on the right.
• The entry field on the right was found to be confusing (received an error message) as there were no examples of what to enter in the field.
• Our subject also felt that it was unclear as to why there were two sets of controls to perform the same action.
• Our subject attempted to add users (or groups) that they wished to 'restrict from viewing' the page and didn't comprehend that the current model would in effect, do the opposite.
• Our subject felt the model was confusing and that they would not be very confident using the functionality to set page restrictions.

Recommendations...

• Provide a concise and easy-to-understand explanation of Inherited Restrictions.
• Change the radio button labels to better describe the model and the outcomes.
• Provide a stronger split (visually) between the 'Choose' and 'Enter' modes of adding Users and Groups.

Final Design

Following is the final Page Restrictions design implemented within Confluence.

Conclusion

The Confluence Page Restrictions project was the User Interface Team's first opportunity (we're only about 4 months old) to work collaboratively with Engineering. The process did take a little longer than expected, however, it was a great learning opportunity for our team and an excellent chance to bond with some Confluence developers. The outcome - while slightly committee driven - is a clean easy-to-use piece of user interface that fits well within the existing Confluence elements. The visual design also fits well with the existing look while at the same time setting new standards for visual design in our products.