Intuit Developer
Partner Program

Phase 2: Build and launch

Skill focus
  • Content writing
  • Interaction design, wireframing, prototyping, visual design
  • Mobile-first responsive design and coding

Challenge: Design, prototype, and test an MVP partnership website by coordinating and guiding an external development agency on the Intuit mobile-first design and development process.

Hypothesis: If we create a compelling partnership program microsite, we will see an increase of quality integrations, partner applicants, and QuickBooks end-user usage of the partner integrations.


(NOTE: This is the second part of a 2-part portfolio piece. Part 1 is the research, definition, and program prototyping.)

Context: With a solid foundation of research and clear path forward, my next task was to create the public-facing touchpoints for the developer partner program in collaboration with a development team specializing in the Salesforce platform.

The organizational need was for the incoming partner leads to fill out a form that would be saved in Salesforce. That being so, the decision was made to build the new touchpoints on that platform.

At the time, two other partnership landing pages existed. One was for general inquiries that encompassed every type of possible Intuit partnership, and one was for QuickBooks partnerships non-specific to the Developer Platform, as pictured below:

Left: General Intuit partnerships website. Right: General QuickBooks partnerships landing page.

Problem our customers were facing: Though we had the concept of a tiered partner program, there was no property that talked about it, and without awareness of what this program could offer, there could be no new applicants.

Business objective: Create a new property that would highlight the benefits of the Intuit Developer Partner Program and display the partner tiers we are proposing, leading the interested party to fill out the Salesforce partner application form before creating their developer account.

This project's primary customer: The stakeholders at 3rd party partner companies who are building and marketing their integrations.

The ask from Intuit: For us to research, evaluate, propose, and build a tiered partnership program as a collaboration between the Intuit Partner Management team and the Intuit Developer Platform team (my team).

Role: Design strategist and principal designer, technologist
Team: Developer Platform and Strategic Partners
Status: ongoing
Content strategy

Constructing a benefit narrative

The partner microsite was mostly a content product, as its single MVP objective was to funnel new leads into the sign-up form. As such, coming up with a hierarchical page information architecture was the primary task, leading them through a content narrative.

Before a design was wireframed, I worked with my content writing partners and other subject-matter experts to determine the story flow. The resultant structure was:

  1. Introduce the core benefit of partnering with Intuit as an integration developer in a single statement.
  2. Share some of Intuit's most appealing virtues from the lens of a prospective partner looking to join a worldwide leader.
  3. Use social proof to backup the claims with recognizable brands of existing partners in the business and fintech industry.
  4. Re-center the focus on the prospect and share the high level benefits they will get by partnering.
  5. Broaden the content by talking in-depth about the program, what it offers to all partners who join, and what the prospect will "get" out of it.
  6. Introduce each tier individually with benefit-focused content that illustrates how we have something for every size and state of partner business.
  7. Re-iterate the call to action to sign-up.

This page content sequence was designed to go back and forth between setup and payoff. When the order of how we wanted to page narrative to flow as decided, rough wireframes were started to determine the general placement and layout of elements to support the story.

Left: an AI hierarchy — Right: hierarchy turned into rough wireframe

Turning concepts into content

Working on the design and content in parallel, once the rough placement and sizing of page elements were wireframed, a separate document was created for iterating over the marketing copy we wanted the incoming partner prospects to see.

I took off my research and interaction design hat and put on my writer's hat, following the narrative scaffolding. To do this, I conferred with another team's content designer on how to come up with a basic voice and tone guideline for this property, and then used that guide as the rubric for explaining the benefits as outlined.

For this property, we knew that developers saw us as peers and that they responded best to language that was plain, conversational, and conveyed a sense of being a partner, not a customer.

The content was written and shared with the extended team, who gave their input and comments. After several drafts, the final copy was given to a content designer for a final edit and approval.

Content for page drafted by me, with contributions from team members and content editors.

With the content created in parallel, I was able to take the drafts as they were produced and integrate them into my Figma mockups, as seen in the next section.

Highlighted skills

A new property with a familiar feel

When it was time to create high-fidelity mockups, the program itself, the page narrative, the wireframe, and the content were already determined, making my task as a designer a lot simpler than if I'd had started from the low- or high-fidelity stage. I could use the research and planning done in advance as blueprint to follow and accelerate the time to shipping the product.

The organization uses the Intuit corporate design system, which gave me the blue color palette (as opposed to the green-based QuickBooks palette). Content was entered and shared with the team through Figma, allowing non-design stakeholders to see the progress live and contribute their thoughts in real-time.

The goal of the microsite

For the MVP, we needed 2 pages. First, the landing page that would introduce the partnership ecosystem and explain the benefits of the program, and then a second page which would show all the benefits each tier offered in a comparison chart.

The design objective was to let the content do the talking and keep the designs as simple and unobtrusive as possible. Using the wireframes and the Intuit Design System guidelines and patterns, the mockups were as follows:

Highlighted skills

Final validation before coding

The designs was validated with a group of customers for content, clarity, and if it resonated with their idea of a comprehensive partner program. With that confirmation of resonance, we were ready to build and launch the first iteration...

However, the agency building the site was not familiar with the Intuit Design System responsive grid SCSS, a system which I myself authored (as seen in the Intuit responsive grid portfolio piece).

This meant I would be coding the front-end of the microsite myself in order to reach our deadlines and the attention to detail needed for what had to be a mobile-first, responsible Intuit property.

Build & learn

Building a program for the future with the tools of the future.

One major accelerant to this phase of the project was the existence of the mobile-first responsive SCSS grid package I developed for two years previous (as I describe in this portfolio piece).

The grid package made the development of the site was fast, easy, and ready for all devices from the start. It may not sound like much, but at Intuit, this was a gold-star accomplishment as we slowly make our way closer to mobile-first development processes and adopt the system I created.

Through a rapid-fire series of sync-ups, I write the SCSS and Pug (html) needed on a module-by-module basis, handing it off to the agency so they could paste it into the Salesforce platform code modules.

They were ecstatic to be better this kind of support and mobile-first, responsive code, as were my Intuit stakeholders, many of whom were seeing a mobile-first responsive property built for the first time.

The code I wrote for the .scss and .pug that was imported into the Salesforce Builder by our dev agency.

Shipping the product!

There is not much to show or say about the development process: I wrote the SCSS and Pug, testing it so that it was a code-perfect expression of my mockups, and chopped it up into components for the Salesforce developers.

The results were a working mobile and desktop site that represented the agreed-upon, scoped-down MVP of the site that was shipped.

Final site, mobile-first and responsive in design and code.

All that was left was to turn on the faucet and let potential partners start seeing the pages as-shipped, something that was done in Fall of 2020! Results are still coming in as Intuit continues to evolve it's 3rd Party Integration Partner strategy, but the early success of the work shown in parts 1 and 2 of this project are promising!

(I can't say much more without venturing outside of what is okay to share.)

Highlighted skills

(If you arrived here without seeing Part 1, be sure to check that out first!)

Reflections & learnings

This was a massive project that spanned many months and the entire breadth of my design skillset. The research that went into the partner program resonates in the organization and is referred to daily, coming up again and again in meetings, from the leadership team, and our internal partners.

What I am most proud of

While the final result is what is seen by the public, what I am most proud of is the deep, qualitative customer research I conducted that set the trajectory for the entire program and strategy. It was not just user-experience or user-interface research, it was fundamental business strategy.

The connection and empathy with the developer customer is a crucial, irreplaceable thing that we sorely lacked. Even if the solution changes, the core research about the developer partner will remain steadfast into the future.

Helping the organization know its customer is the highlight of this project.

What I would have done different

I would have liked to connect with a broader range of partner personas. The ones who agree to be interviewed are typically more engaged and eager to share. Finding a way to talk to the ones who did not want to be interviewed because they lacked confidence in us, lacked excitement about our platform, or because they felt like they were not important would have given a more nuance insight.

What I would do next

I believe that the conclusions based on the empathetic research remain true, and that meeting our partners in a relationship is the right decision regardless of how we scope it.