)
This article originally appeared on Stackable Design. Liz is a usability professional working on all things User Experience at Red Hat. You should follow her on Twitter.
The OpenStack Juno Summit in Atlanta was a major turning point for User Experience professionals working on OpenStack. Not only did we have 3 specific design sessions around UX work and 1 talk on the persona work we’ve done, all with great attendance, but we’ve committed to a number of actions we will be taking over the course of the Juno development cycle. All of these actions will improve User Experience work within the OpenStack community and the best part is that we will be working as a team to do this.
Better Communication…
The first session that we had at Summit around UX was an hour and a half long design session to talk about all things User Experience. It was great to have almost everyone working on design and user focused work in one room together brainstorming on how we can work better as a team moving forward now that there are more than 2 of us 🙂 One major step forward that we agreed on is that we will start meeting bi-weekly over IRC. We had our first meeting already and the communication channel is so much better already. There were just about 15 people who attended (a mixture of developers and designers) representing at least 7 different companies that I’m aware of. We covered a few basic topics during the first meeting such as a standing schedule of times for future meetings. But this meeting will eventually be important for us all to be on the same page around what we are designing towards for a specific release. We also invite anyone working on any project within OpenStack who may need some UX guidance. This gives a specific time and place that is published for anyone looking to get their requests on our radar.
Making it Easy for Folks to Get in Touch with the UX Team…
Coming to our bi-weekly meeting would be a great option. Also, if you prefer IRC and have something you’d like to contact us about right away you can find us in the #openstack-ux channel on Freenode. We agreed at summit that we will standardize on using the tag [UX] on the developer mailing list for communications as well, so if it’s an e-mail you’d like to craft and send, adding this tag to the subject line will be sure to get our attention.
Prioritizing work on the UI, CLI, and API…
A big topic within the UX team currently is around how we can be sure to evangelize User Experience work that can be done for projects that don’t include a UI. We’d love to be able to contribute resources with 100% focus on UX work towards CLI and API efforts, but we unfortunately don’t have anyone with bandwidth to take this on currently. We are thinking it would be a good idea to reach out to folks in each project to be sure they know how UX could help with things like consistency of CLIs and APIs. If there is anyone currently working on these projects who have interest in UX type work, it would be great to connect with them and help drive forward their current UX efforts. Keep an eye out for more discussion on this topic within each of the teams. Also, if you currently work on a team and are interested in bringing more UX focus to CLIs, APIs, or anything else, let us know and we can do our best to help out!
Tracking UX Tasks…
UX tasks are a bit unique in the way that the outcome of the tasks normally influence tasks that already exist or need to be created in other projects. Storyboard is a tool that has been created within the OpenStack community that is being designed and developed based on the OpenStack task tracking process needs. The Storyboard team has been amazing to work with and have been really interested in getting feedback from all of their users and potential users (including the UX team!). They are currently focusing on the features that are needed for users to transition over to using StoryBoard. The UX team has some requirements that are different from other projects, such as attaching images to stories, but the Storyboard team has been very responsive to getting these features in for us. We have already decided to move over to using Storyboard as a way to track out work as soon as a few infrastructure issues have been ironed out. This will be a great way to continue to give early feedback to the team as they solidify the first version of Storyboard for all of their end users.
A Standard Design Review Tool…
We’ve been attempting to find a great design review tool that we can all use to share and get feedback on our designs as a team. We haven’t had any luck with finding a great open source tool for this, but we are still searching. One tool that we’ve considered using is called InVision. With this tool, we can upload images and keep revision history of images. Reviewers can come in and view these images and provide feedback directly on the images in the place that the comment applies. A conversation can then take place on this topic right inline to the design. Having one tool that everyone can subscribe to would make it easy to take our design communication to the next step. If you have any suggestions on open source design review tools, please let us know! In the meantime, we will continue to use a mixture of InVision and the mailing list to get feedback on our designs.
A Standard Design Tool?…
We talked a little bit about whether we need to standardize on one tool for design work or not. We all ultimately agreed that since there are a lot of stages of designs (ranging from sketching to high fidelity) and people have preferences and access to different design tools. It makes sense to not standardize on one tool, but rather to have design template files for a number of different tools that folks can use. This file would include all of the basic design elements used in Horizon designs today. We will most likely start with templates for tools that a few of the very active designers are using (InDesign, Balsamiq, and maybe Axure). If there is a designer who starts contributing in the community and wants to use a new tool, they could put together a template for that tool and contribute that to the community as a first step. These templates will eventually live on the UX wiki for designer consumption.
Juno Design Priorities….
Since we had a few design sessions within the Horizon track, we were able to discuss some of the specific design work that we’ve been doing and would like to continue working on through the Juno cycle. We discussed the results that we got from running the baseline Horizon Usability Testing and all agreed that we should continue to make design proposal updates for the Launch Instance Workflow, Error Messaging Guidelines, and Inline Help Guidelines within Horizon. We also proposed some ideas about improving the Overview Pages within Horizon. This work will continue to move forward this release based on feedback from the Horizon developers and operators in attendance. Another big focus during the Juno cycle will be around finding the right place for the Tuskar UI work that has been done. This UI is starting to touch more components than just Horizon and TripleO and will continue to grow throughout the next release. And of course, we will continue to push our Persona work forward and strive towards having a final first set of personas to use as we design new features.
This isn’t an exhaustive list of things we plan to accomplish in the Juno release cycle, and some of these will continue throughout releases moving forward. But I’m proud of the incredible progress we’ve made as a new group that is still forming within such a large community of lots of projects. Are there items that you think the UX team should get involved with in the community? Drop me a note if you think so and we can add in new stories to Storyboard 🙂
Best,
Liz
Image credit: cropped from "User Experience u and x flashcards" by James Royal-Lawson
Brittany Solano
Superuser
