The team I worked on included developers and designers. However, there was no official UX person on the team until I got there. Since I find that there is often confusion and misconceptions on what UX does, I chose to hold regular meetings with the broader team to talk about UX, and the value it can bring to an organization.
This was my first official agile project and I needed to get up to speed quickly on it. To do that I did research online and bought several books on the topic. At that time (2011) there wasn't a lot of info on managing the process from the UX perspective. I chose to create various deliverables that would work well with the project. One of the biggest challenges is the addressing the misconception that agile is a paperless exercise. Instead, I chose to document for items that needed clarity and could only be communicated via documentation.
This was a unique project since it was completely customized for the client. Because it was based on the unique processed of the existing document management system, our team was blazing a new trail. While we designed for the existing process, we also looked for ways to improve it. The tool had roots in project management and document publishing, so I looked at various competitive applications to get familiar with the UX and how we could adapt it to our project.
UX teams are often a natural enemy of trees - creating hundreds and hundreds of pages of documents. Talking to developers however gave me a different perspective - often times they don't even read the documents. And sometimes the documentation isn't really necessary. So, I recommended to create a pattern library that could be used by both developers, designers and UX for common patterns. This would help reduce documentation while ensuring consistency.
Lead UX Designer,and managing the agile UX process.
Senior Designer, Senior Developer, Project Manager
Agile, holding daily scrums and collaborate and working closely with developers.
Omnigraffle, Boostrap 2, Adobe Creative Suite, Excel
Design does not live by wireframes alone. Below is a representative sample of various supplemental tools that were used to help shape the design.
We didn't have the scope to do extensive user research to create a detaoled user persona. At the same time we needed to better understand who we were designing for. This is more likely the typical situation I encounter in a given design project. So, I typically like to create what I call simple assumptive personas. This means thinking about the acerage user types then quickly coming up with a list of goals, needs and tasks. To hekp drive this, I find it helpful to talk to SMEs and even the project team. The example on the left shows a template that can be used to create simple personas - particularly in an agile environment. Since there were many commom elements used through the project, going forward I wanted to find a way to reduce documentation inefficiencies. So, I proposed to create a design pattern library. To do that, I identified common page elements and began to create an HTML version using Foundation.
Although the project was 'agile' there were instances where we needed to document complex system interactions. This approach is consistent with commonly-held agile methodologies to document things which are necessary and cannot be communicated effectively by other means. For example, the entire system flow for the process spanned across various external systems and users with numerous touchpoints and interactions. As a result, I created a 12-page user flow in Omnigraffle that depicted these flows. This helped development to better understand the entire process.
I helped drive the method and process for the creation and management of the user stories. I chose to store each story in an Excel document. This made the process easy since there were less than 100 stories for the entire project. To help create the stories, I worked with a BA, developer and SMEs. The story was circulated among the tema for final review. I then created estimates, working with the developer to help create the sprint cadence.
I believe that sketching is an important part of the UI creation process. I try and make things as simple as possible by sketching first, rather than commiting things to a wireframe design. This gives me the opportunity to quickly explore more options. In some cases I will use office supplies such as sticky notes to mock up the design. To the left is a mockup of the actual sketch I created to help define the UI for a product catalog. In this approach, I used a side-by-side view of the products (left) and objects (right) which could be applied to the product design. Through iterating with designers, the UI was refined before it was created as a final wireframe document.