Evolving a Legacy: Helping Enterprises Adapt to the Changing World of Work

At Planview, I was the User Experience Designer for our flagship product, Planview Enterprise. Much of the results from the work I did has not been released. As a courtesy to Planview, I will not share details of my work here. However, I am happy to dig deeper and discuss my work in more detail to prospective employers in person. In the meantime, I will describe generally the approach and process I took for projects at Planview.

Initial Requirements Definition

A typical project would kick off with me meeting with a product manager or the product management team.
At these initial meetings we would often:

  • discuss generally the needs and motivations behind a new design or redesign
  • identify the forces that are driving the new development. (Is this coming from a request from sales, a specific customer, our consulting team, the vp of product, our own team?)
  • whiteboard or sketch out some rough user flows to help make sure we are on the same page for what the potential development could look like
  • identify our assumptions and enumerate pending question for further study

After this initial meeting we would often set up subsequent meetings with internal stakeholders. Because our exposure to primary users was often limited and sacred, we would gather as much secondary “user” information we can internally, often from sales or our consulting team who works with customers everyday.
After these meetings I would recap with the product manager and we’d refine our list of unknowns and begin to put together a plan for customer/user inquiry.

Insight Gathering Through Customer Inner Circle Program

Our primary contact with customers was through what Planview called the “Inner Circle Program”. Interested customers could sign up to be a part of regular meetings, happening about once or twice a month. The meetings, conducted through WebEx, were typically a hybrid of a roadmap presentation where we would share our most recent development plans and a focus group style feedback session. Recognizing the limits of this style of inquiry, I worked with the product management team to enhance our research sophistication and get the most out of these sessions. These sessions did allow us to develop and maintain a collaborative relationship with customers so that we could reach out to them for more targeted behavioral studies such as user acceptance walkthroughs. They were also an opportunity for me to glean some insight into general attitudes and experiences with Planview.

BYO Constraints and Collaborative Design

As the design evolves from an abstract collection of ideas, notes, and scribblings from the various stakeholder interviews into a more concrete visual and mechanical product, there are inevitably additional decisions and assumption that have to be made. I have received an explicit list of constraints from the initial research to drive my initial decision making, but there is also a set of my own constraints that I bring to the table, I like to call them BYO Constraints. These originate from a combination of my own personality and ethos as a designer, my understanding of Planview Enterprise’s specific technical constraints, my understanding of Planview’s corporate strategy and brand direction, and broader insights that I have gathered across projects about Planview’s users.
Wireframes are typically shared internally to test these assumptions that I have made.

Interactive Prototypes and User Acceptance Testing

Once the product team is pretty comfortable with a given design, or if we at least have a sense of what we are not comfortable with, then we will start to put together a plan for additional user feedback. This will often be in the form of moderated user acceptance walkthroughs. I would always push for this methodology as it was the most feasible way that we could get behavioral information from our users.

These tests would often require clickable prototypes. Because many of the layouts were fairly complex and the fidelity of the interactions were usually pretty important for testing, I almost exclusively used Axure as my tool of choice for these prototypes.

Just in Time Mockups and Product Recommendations

The information gathered throughout this process was continually being fed to developers. We practiced somewhat of an agile development process so there was never a time where the product team would hand over a complete set of deliverables or specifications. Information I gathered and articulated through conversation, prototypes and mockups would be used in dev tickets that were created by product management or in direct communication between myself and a given developer working on a particular feature.