CV

Experience

Pivotal CF

2014 - Current

Product Designer

Product Designer on the App Manager team for Cloud Foundry.

RightScale

2013 - 2014

Lead UX Designer

Responsible for UX research, design, and requirements gathering. Designed user flows, information architecture, wireframes and prototypes. Worked closely with a team of Developers, Architects, Product Managers, and Graphic Designers to deliver a new product.

QAD inc.

2012 - 2013

Lead UX Designer

Responsible for defining the User Experience goals and vision for new and existing products. Researched for on premise software, mobile applications, and web applications. Worked with developers to apply accepted usability standards, conduct usability tests, and visited customer sites for contextual inquiries.

2006 - 2012

Lead Quality Analyst

Responsibilities included planning, conducting tests, and analyzing usability heuristics. Also trained and managed several QA interns.

Education

UC Riverside

Class of 2012

Business Economics, BA

3.40 GPA

Training

Edward Tufte

2013

Presenting Data and Information

Taught by Edward Tufte.

NN Group

2013

3 Day Interaction Training Course

Taught by Bruce "Tog" Tognazzini.

NN Group

2012

Basic UX Training Course

Skills

Product Design

Interaction Design

Rapid Prototyping

User Research

Usability Testing

Tools of Choice

Axure

Balsamiq

Sketch

Dot Grid Paper

Languages

HTML

CSS

Self Service - Alpha

Project Goal: Release the MVP

Project Timeline: 3 months

The Company

RightScale is a leader in Cloud Management solutions that enable central IT to manange, govern and optimize their cloud enviornments.

Project Role

I have been the Lead UX Designer for the Self Service product. Responsible for all wireframes, clickable prototypes, User flows, and personas, Usability testing and research. I worked collaboratively with Visual Designer @Jason and @Adrian to build the

Project

After building and validating the prototype, we began building the Alpha release of Self Service.

We had validated the product, we explored the features and settled on an MVP, but we were asked to strip down our feature set further to get the product to market as quickly as possible. We had an Alpha release scheduled 2 months out, with general availability 3 months after.

I spent my time supporting the developers and working with them on designing the finer points of the application. The real challenge was pairing back the features without sacrificing the usability and value of the product.

During the phase of building the prototype, we focused on the end user. For Alpha, we needed to shift focus to the Admins and Designers.

User Tasks for Admins and Designers

Efficiently provide users access to a curated set of Cloud Resources.

Be a point of support for end users if CloudApps fail.

Manage users, sharing and permissions. Grant users access to Self Service without providing access to the RightScale Cloud Management platform.

Our Product Manager managed the early access program (EAP) which consisted of several existing RightScale customers. I assisted him during the bi-weekly reviews with the participants, where we demonstrated upcoming features, and received valuable feedback while we were in active development.

The Designer app was a place for Admins to manage their published CloudApps. Here you can see the helpful context menu that we implemented across our tables.

We wanted to make the publishing experience as efficient as possible for the Admins, so we gave them a way to test their CloudApps before publishing them to the Catalog. Here in the Designer app you can see the Designer can preview the launch modal that the end users will see in the catalog.

It is important for our users to make this portal feel like their own, so we built the UI Customization app.

Customers can preview, save and apply their company color palette and logos to match their branding.

Self Service Prototype

Project Goal: build a prototype to show at AWS Re:invent 2013

Project Timeline: 3 weeks

RightScale had been a leader in Cloud Management solutions, but we wanted to start catering to a new set of users. Product gave me a high level overview of what the product needed to accomplish, and pointed me towards a few competing applications to get a better understanding of what we needed to build.

Research

Research Goals:

What problems do our customers need us to solve with this new product?

How are they currently solving these problems?

Who are the intended users?

We began our research cycle with discovery interviews. The Product Manager interviewed 10-15 customers, and during these sessions I was able to ask my own questions while also listening to what the customers needed from this product.

Patterns began to emerge during the research phase. Many customers had a homegrown solution, others were using complementary products to supplement RightScale, and many were left to devise creative workarounds to solve this gap in the product.

These early interviews were critical to learning exactly what our users wanted and needed. Additionally, by asking specific questions about their workflow, I was able to glean insight from their motivations, patterns, and behaviors that led to designing the right solution.

Affinity diagramming and notes from discovery interviews.

I synthesized our research in to personas, user stories and task flows. We knew there would be 3 main users of Self Service, but for purposes of the prototype we would only design and test the end users experience.

User Tasks:

Browse the curated Catalog for Cloud Applications

Launch a Cloud Application

Use the Cloud Application

Goals for Success:

Give our users an easier product to consume the powerful features of the RightScale platform.

This was broken down into several key value propositions:

Give Admins a portal to design, maintain, curate, and publish Cloud Applications to a Marketplace where users can consume the set of resources;

and give untrained users the tools they need to utilize these cloud resources with little to no training required.

Design

I then synthesized all of the requirements above into an Axure prototype. I still had many assumptions and questions about the users needs, so I tried to design the app in a way that would lend itself to exploring those questions.

Here are two iterations of the Axure prototype. I did an A/B test between a launch modal and a launch Page.

Our team then worked collaboratively to build the HTML prototype using my Axure prototype as a guide. After a few weeks we were ready to get some feedback.

Our completed prototype. Users begin in the Catalog where they can effortlessly launch a Cloud Application.

As soon as the Application is up and running users can begin using it.

We hard coded the prototype to show the flow of what would happen when a user launched a CloudApp.

Now back to our original goal - the Product Manager needed the prototype to show at the AWS Re:invent conference. From the business goals he gave me, I then wrote a script for him to read through during his conversations with customers.

The usability test report that I wrote and posted on our internal Wiki pages.

While the Product team was busy at the conference, I was so eager to get feedback that I also ran a set of usability tests with 5 internal users of RightScale. I soon heard back from the Product Manager that our customers could not wait to start using our new application. I found that internal users shared the same excitement.

QAD Dashboard

I began the project with thorough user research. To get representative user data, I conducted on-site contextual inquiries to observe our users workflows. Coupled with competitive analysis, and analyzing user data, I began mapping out our users needs.

User Stories:

I need a Dashboard to get an at-a-glance view of all my important data.

I need the data to be up to date.

I need to be able to update the Dashboard as needed.

I need to be able to share out my Dashboard with other users.

We then created Dashboards for various roles, a few of the personas we designed for:

Customer Service Representative

Account Manager

Sales Representative

Warehouse Manager

+ 14 more

From these personas, we then contacted several customers that had offices near by and validated the Dashboards with them. We wanted to make sure that we understood our users needs, as this Dashboard project was part of a much bigger undertaking - a Role based system.

Sidenote: From all this research, I hosted a local UX Meetup event to talk on the subject of Role Based ERP systems. View the event on Meetup.

Users can quickly add a variety of widgets to their Dashboard.

The Dashboard allows users to add content from several program types across the platform. These included data tables, Operational Metrics, Business Intelligence Charts, Process Maps, and any URL they desired.

Measuring Success

We validated the Dashboard with several customers by allowing them to be part of an early adopter program. By participating in the program, we got continuous feedback during the development cycle that we were able to rapidly iterate on. Our customers were very pleased by the new features, and being part of the design process.

The Dashboard as seen by a Customer Sales Representative. We used this role for various demos and presentations.

We didn't quite realize the power of the URL panels until we met with various users who told us how useful a DHL or FedEX panel would be during their workflow.

Users could change the Dashboard easily by opening the dropdown here. Upon hover, the panels had additional actions presented. Clicking on the panel would open the Application contained in the panel in a new tab. Also, an action bar would be presented when hovering anywhere on the card. Actions included refreshing the panel, or deleting the panel from the Dashboard.

QAD Portal Prototype

The Portal Prototype was an integral part of moving QAD’s Desktop Application to the web. Our goals for building the prototype were to explore and answer these questions: what is the minimum viable product (MVP) for our users with respect to a web application? What kind of complex interactions, features and functionality can we now take advantage of if we move to the web? Is this something our users want, or are they comfortable with on premise desktop software?

The completed Prototype.

Our team consisted of a one front end developer, a business analyst, and myself as the UX Designer. The Business Analyst was in Europe, so collaborating was challenging. He helped us with the content, and the front end developer and myself worked on designing the visual design, layout, interactions, and information architecture. We set mini releases each week, and tested the new functionality and designs 1-2 times per week. We found that the steady research cadence sped up our design work flow, quickly reduced usability problems, and improved user satisfaction.

Lessons Learned

During the 8-10 weeks of working on the prototype, we surfaced invaluable information. More importantly, as the months went on, we continued learning from the prototype. It was instrumental in deciding how to move forward with a web application. From our thorough user research, we knew what features mattered most to our users. We knew that we had to focus on specific pain points they were currently working around because we didn't have enough mobile solutions. This was great for our team, and a powerful tool for selling our story to other stakeholders. Listen to thy user research!

QAD Dashboard

After the success of our first mobile application (GRS, shown below) we got overwhelming response from our user base for more apps. We ran a few surveys, analyzed our usage data, got weigh in from key stakeholders, and conducted user research across our user base to decide which application to build next. Our research showed that a mobile browse application would provide the most utility for our users. Our browses allow our users to view large datasets across their enterprise. Additionally, the browses can be customized and linked to one another to make meaningful connections.

We built a master-detail pattern that allowed the user to view more about an item, and then drill down to another browse with more details.

Design Process

Working closely with the lead front end developer, we began designing the Mobile Browse app. We started out by listing out user requirements, task flows, and key features that we needed to support on a mobile device. Because of time and technical constraints, we were pushed to focus on the minimum viable product.

We quickly drafted up some paper prototypes, put them in front of key stakeholders and internal users. We continued to iterate on the designs and features from this research and feedback.

We wanted to implement a search widget that was similar to the desktop experience. This was a powerful search tool that our users were very pleased with.

Measuring Success

Our app was scheduled to release soon after a QAD user group meetup, so I proposed a research session during the conference. I was able to conduct in person usability testing on the app, and gathered valuable feedback that we were able to incorporate before releasing the app. Our users were thrilled with the application, and to help us with deciding what to build next. Not only did we find several opportunities for usability improvements by testing with our users, but we also brought that excitement and validation from our users back to our development team at QAQ.

QAD Global Requisition System

Key stakeholders at QAD decided that we needed to release a mobile application. Managers and Executives use the global requisition system to approve and route purchase requests. We were frequently hearing from our users about the different workarounds that they were dealing with to handle approving, denying and rerouting these requisitions while they were out of the office. It was clear that a mobile solution was needed.

Design Process

Being that no one on my team had used GRS, I took it upon myself to learn the system. This was my first project at QAD where work began with a user centered design process, rather than analyzing the outcome and mitigating the usability problems. For me, this was very exciting.

Here is the Desktop Application that the app was modeled after.

I quickly found that there were parts of the system that just did not sync up with our users mental model, and it was astoundingly unintuitive. I scoured through the 20 year old documentation, trying to make sense of things. I was quickly dubbed the GRS expert of QAD, yet I remained unsatisfied with what was still little understanding.

I decided to talk to internal users. I asked them to walk me through their workflow and then explain the parts that were unclear to me. I quickly found out that it was equally unclear to them, and I found some very interesting workarounds they had employed to simply push a requisition through the system.

The native iOS application. We also built an Android application.

Execution and Measuring Success

After thorough research and speaking with the internal users, I was able to channel all the requirements in to a simple solution. We validated the app with our internal users, and external ones as well. Our users were delighted with the solution, and they finally had a product that helped them to better understand the system. It improved their workflow by reducing 5+ steps to complete a task, and allowed them to use the system no matter where they were in the world.