Gliffy Project

Blank page B2B product design

Director of UX & Product Design

GP-Canvas.png
 

What We Built

Gliffy Project is a visual communication tool for product development teams:

It closes the gap between vision and execution by putting visual documentation at the center of the product development process, so that all members of a team will always work in context of the big picture plans that describe their complex projects.

 
Screen-Shot-2018-12-08-at-1.48.43-PM.png
 

Key Responsibilities

  • Led ‘zero to one’ product design process

    Defined and drove entirely new product development for Gliffy, from initial blank whiteboard to launched product.

  • Facilitated design workshops and sprints

    Built team alignment and direction through highly collaborative, rapid problem-solving sessions around product strategy, directional evaluation, turning research into actionable product direction, etc.

  • Defined product strategy

    Partnered with senior leadership to explore and define: what should we build and why? How can we best set ourselves up for business success? What high-ROI actions should we pursue and what should we postpone / not do?

  • Led user and competitive research, problem discovery, and solution validation

    Defined and conducted interviews, surveys, and direct observation with goals of defining our problem space, user pain points, and prototype validation.

  • Managed and led design team

    Hiring, team mentorship and coaching, quality of work, timing and prioritization, tools and workflows, design system, team and individual goals / OKRs.

 

Design Strategy

Gliffy was looking to grow its core business, increase value to existing customers, and capture new customers by adding a new product to our existing lineup through these goals:

Create a new Gliffy product that achieves these business goals:

• Continue our focus on software teams—specifically in product development.

• High usage, both frequency and breadth—ideally daily use across core product development team functions (engineering, product management, and design).

• Expand upon Gliffy’s visual “superpower”.

• Strengthen Gliffy’s relationship and presence in the Atlassian Marketplace.

• Mandatory multiplayer / inherently viral—teams use the product together, and adoption snowballs through natural usage.

 
 How might we expand our product line-up, add value to existing customers, and increase product usage with a new Gliffy product?

How might we expand our product line-up, add value to existing customers, and increase product usage with a new Gliffy product?

 

Research And Problem Discovery

It was important for us to deeply understand how to bring value to our potential customers. Through existing customer, non-customer, and competitive research, we identified the following three pain points that product development teams consistently face:

1. Scattered communication and project documentation

  • Team communication is scattered across email, IM chats, meetings, wikis, and task management software.

  • It’s difficult to keep track of current status, what’s done, what needs to be done, etc.

2. Ticketing systems are text-based, while people and products are inherently visual

  • It’s time-consuming to understand how written tickets relate to visual designs, user flows, software and information architectures, and complex systems.

  • Details get lost in translation, leading to incomplete and inaccurate product experiences, wasted work, increased cost, and frustrated teams.

3. Complex projects need a single source of truth

  • There is no single, up-to-date destination for teams to see what needs to get done and why, the current state of their projects, and short-term versus long-term vision.

  • Development teams are often guessing what’s needed due to unclear or hidden product requirements, slowing progress and limiting their ability to succeed.

 
 Look from different angles to build understanding of the problem space.

Look from different angles to build understanding of the problem space.

 
 Map the problem-space to find hidden opportunities.

Map the problem-space to find hidden opportunities.

 
 Simply talking to customers isn’t enough—team-based note-taking and interview processing leads to better pattern identification, and deeper, more meaningful insights.

Simply talking to customers isn’t enough—team-based note-taking and interview processing leads to better pattern identification, and deeper, more meaningful insights.

 

Design Pillars

With a clearly defined audience and high-value problem to solve, the team started to think about potential solutions that fit the problem space. As we began concepting, though, it became clear that we were still lacking some focus—the team would be able to move more quickly and efficiently by setting tighter constraints around what we’re willing to take on, and what we’re not.

In order to establish broad boundaries for the design team to get creative within, we defined some clear—and sometimes controversial—design pillars:

  • Pillar 1 - Consumer-grade enterprise product

The stigma is that enterprise products are stuffy, dated, bloated, inefficient, and ugly—products with little regard for user needs, polish, or delight. From the start we’ve acknowledged and embraced that user expectations and the bar for quality, efficiency, and craftsmanship is as high in enterprise as it is in consumer products, and only getting higher. We’ve held ourselves accountable to this, across broad experience direction and the nuance of every pixel and interaction.

  • Pillar 2 - 80:20 Jira functionality

Jira is a deeply complex product that enables teams of any size or structure to run agile development any way they like. Our goal is to enhance the experience of using Jira, not replace it. It’s a product that’s widely used, and not only would it take forever to rebuild all the functionality that it provides, it would be a massive waste of our time and effort. Our goal is to enable the 20% of tasks that 80% of Jira users do day-to-day to be as efficient, visual, and compelling as possible.

  • Pillar 3 - Mandatory multiplayer

One of our key business objectives was to increase overall breadth and frequency of Gliffy product use, so building an inherently multiplayer / multi-user product was a driving pillar behind every design decision we made. This is a product for cross-functional product development teams—it’s not for teams of one—and its user base will grow through use of the product’s core functionality. 3rd-party product integrations, notifications, and team-based mechanics like live collaboration and organic invites exist specifically to create value for teams working together, as well as organic product growth.

 

High-Level Exploration And Validation

With a solid foundation in place, we began to think broadly about how a new product might relieve some of the pain that product development teams feel around cross-functional communication, scattered documentation, and complex, text-based task management tools.

This involved a ton of whiteboarding, sketching, looking at other products both inside and outside of our space, and building prototypes to test and understand where we’re on track and where we’re not.

Some pieces came easy, while others took endless rounds of exploration, prototyping, user testing and validation to get right.

 
 All the ideas; a few strong, many weak.

All the ideas; a few strong, many weak.

 
 Focusing in.

Focusing in.

 
 Learn from other products and solutions in and outside of the market.

Learn from other products and solutions in and outside of the market.

 
 Compare ideas at higher fidelity.

Compare ideas at higher fidelity.

 

It was important for us to understand the benefits and deficiencies of potential directions with low initial cost to the team. As a rule, these validations were done quickly and with as little upfront effort as we could manage. The goal was speed and ROI: do as little work as possible to give clear form to an idea, and then get an honest read on its strengths, weaknesses, and potential to benefit our users.

Once a hypothesis was formed and its strongest potential direction agreed upon by the team, it was given rough shape in a prototype and shared with current users, beta testers, and / or research subjects depending on which phase of the project we were in.

 
 Many prototypes and conversations inform where our ideas fall short and—most importantly—where potential lies.

Many prototypes and conversations inform where our ideas fall short and—most importantly—where potential lies.

 

This cycle of build > test > iterate > repeat allowed us to evaluate a ton of different directions, and weigh the pros, cons and trade-offs with both the internal team and external testers. Every conversation helped inform what made sense for users and what didn’t, and where the product’s real value lay for teams.

 
 Low-fidelity prototypes help prove initial product value and inform high-level design decisions like general information architecture early on.

Low-fidelity prototypes help prove initial product value and inform high-level design decisions like general information architecture early on.

 

Scaling The Design

As a small team creating a complex product from scratch, efficiency was critical to maintain momentum and set us up for success. It was important that we clearly articulate the granular interactions, UI elements, and components that enable our product experience in a way that doesn’t create a lot of communication overhead or effort for our team.

Shared symbol libraries, well-defined style guides, and interactive / animated prototypes provided the means for us to systematize the design, and communicate the nuance of the product experience for validation, team buy-in, and successful implementation, while minimizing the need to go back and re-work elements when direction changed.

 
 Well-defined components make design fast, efficient and consistent across the team, and reduce missed details in code.

Well-defined components make design fast, efficient and consistent across the team, and reduce missed details in code.

 

In order to be successful in pixel-perfect UI and interaction design implementation, we embraced:

  • Component-based design

    Minimize guesswork for engineers by clearly communicating how disparate UI elements combine to form complex components / screens, various states, responsiveness, etc through component-based design, style guides, and interactive / animated prototypes as needed.

  • Version control for consistency

    Share and version control all design elements and components with the design and engineering teams, so we’re always working on top of the same foundation.

  • Component quality control

    By maintaining a tight design system and component library, the team is forced to make conscious decisions on when and why to add new components versus re-using existing ones—no more one-offs that look identical to another component or element (+/- 1 pixel).

  • Lego-block iteration

    Enable the team to focus on higher value problems like the experience rather than the padding (or font-size, or color…) by building screen designs with state-based components. Update the parent component and cascade its changes across all instances in all drawings across every team member.

  • Efficient implementation

    Well-articulated design elements enabled our dev team to mirror the Sketch components one-to-one, as designed, leading to implementation efficiencies across the entire team.

 
GP-Symbols-Shadow.png
 

Building Value For The Product, Our Users, And Our Business

Screen Shot 2018-12-09 at 2.12.37 PM.png

This process has led our team on a long and challenging journey—from initial “blank whiteboard” questions of what a new product at Gliffy might be, do, and look like, into initial user research, problem discovery, concepting, directional validation, multiple closed betas, all the way to launch and now growth while running live.

Since launch, we’re now seeing multiple product values prove out as we grow our customer base:

  • A more efficient Jira experience

    By leveraging visual documents—be it a flowchart, wireframe or screen design, or even a napkin sketch or whiteboard drawing—rather than text, what was once a multi-paragraph Jira issue describing complex visual information like product interactions, user flow, or component state is now reduced to a couple lines of text. These issues are also then consumed more efficiently and effectively when they show instead of trying to tell a story that is inherently visual.

  • See progress, dependencies, and gaps in the plan at a glance

    By spatializing and grouping tasks directly on top of visual documents, teams can quickly see work relationships, any gaps in the plan, and progress toward successful completion. More detail is captured and consumed with less effort across the team.

  • Team harmony through pipeline efficiency

    From design through engineering and ultimately QA, the product development team maintains a clear understanding of what needs to be built and how every individual task fits into the big picture of product and user experience, so better work is done more accurately the first time—with fewer do-overs.

 
Screen Shot 2018-12-09 at 2.18.28 PM.png
 

Available in Atlassian

Our team uses Gliffy Project to build Gliffy Project. It’s helped us clearly communicate big picture vision alongside granular tasks, leading to more efficient development cycles, less wasted time and effort re-doing work by getting things right the first time, and happier cross-functional teams.

Gliffy Project is launched and available for free trial and purchase in the Atlassian Marketplace. 🙌

 
 Gliffy Project “canvas” experience—where Jira issues and visual documentation come together for clear team communication.

Gliffy Project “canvas” experience—where Jira issues and visual documentation come together for clear team communication.

 
 Gliffy Project “project overview” experience—a single source of truth hub for all project-related visual documentation, Jira boards, and external documents

Gliffy Project “project overview” experience—a single source of truth hub for all project-related visual documentation, Jira boards, and external documents

 
 Wireframe example with Jira issue details.

Wireframe example with Jira issue details.