Getting crisp on hurdles, both technical and experiential in nature

Apps.com was determined to be a complete reboot, meaning we had a clean slate, but also ran the risk of repeating the mistakes of the past if we did not learn from them.

The pragmatic technical hurdles to learn from

One "must do" aspect of this replatform was the SEO penalty by Google's algorithm for being unfriendly to mobile users. The entire Apps.com property had no mobile features, no responsive features, and the CSS/HTML was generated by an abandoned stack that was unsalvageable.

The path forward chosen by the engineering team was to build Apps.com on a new stack from scratch, keeping the business logic but abandoning the unsupported legacy code. A breath of fresh air because now, we could build the mobile-first, responsive capabilities correctly from the start.

As the most experienced design technologist in the organization, I wanted to offer all the help I could to the engineering team to make sure we baked in what we needed.

The pragmatic user experience hurdles to learn from

There was no customer research or design documentation available on Apps.com usage, and no personas or "Jobs to be Done" to rely on. We had historic knowledge and assumptions, which meant our task was to establish and validate who the customer was and their needs.

Establishing the current state of customer expectations and experiences

The baseline understanding of Apps.com was that it was used by three customer types

1. Small business owners looking for integrations to help their work
2. Accountants looking for integrations to help their practice
3. Developers looking for marketplace platforms to build their integrations

Establishing a new understanding of customer and Job to be Done

Research interviews were conducted with a variety of the presumptive personas, taking the needs, pains, and Jobs to be Done from each and blending into a combined outlook on what the new iteration needs to do.

The core "job" of our customer was summarized as "I am trying to reduce the time needed performing the administrative tasks of my business so I can focus my energy on growth and making more money." The customer does not want to be finding integrations, they want more time.

With that, the research allowed us to arrive on three core experience principles:

1. The marketplace should do its best to surface relevant apps using available customer data if they are a QuickBooks user already.
2. Looking for solutions is an ad-hoc experience prone to mobile experiences.
3. Search and browse fulfill two different motivations and should be optimized for a user who had an idea of what they want (search) or needs to see related information to narrow down (browse).

Competitive analysis of the state of app marketplaces

An evaluation of direct competitors and similar experiences was done, looking for patterns and inspiration. Cursory UX audits of parallel marketplaces were conducted to note what external practices could be adopted and fell within Intuit's expectations for a good customer experience.

Moving forward with solid assumptions

With principles, a baseline Job to be Done, and a snapshot of the state of app & integration marketplaces, we were ready to move to the 2-pronged design and develop parallel phase.

Designing with pixels and code in parallel

The design path for Apps.com consisted of a loop that went:

1. Create quick wireframe concepts based on research learnings and the QuickBooks Design System patterns
2. Test mobile-first and responsiveness in live prototype
3. Narrow on concepts via design review and/or user validation
4. Increase fidelity of mockups and code and repeat

The amount of concepts for the key touchpoint on Apps.com went very broad at first, then narrowed through review and testing. Our mindset was "perfect is the enemy of good" as we surged forward toward an MVP launch.

A pair-designer effort of tight iterations between design and code

The task redesigning Apps.com was large, and there were two product designers working on it as a team; myself and another Senior Product Designer who was hired new to the company for this work.

We worked on the tasks in tandem, trading files and swapping back and forth. When an approach felt 80% stable, I would adapt the html/css prototype to match. Pair-designing and code-prototyping is a wonderfully fast and efficient way to get work done.

Adding the design system and patterns

QuickBooks has a mature design system, and as we narrowed, these patterns were added to higher fidelity mockups, as well as to the prototype (as seen in the next section).

Designs were rapidly tested with users to validate their effectiveness, both over video calls as well as asynchronously with Usertesting.com. Concepts that had obvious shortcomings were dismissed in design review, and high-potential concepts validated rapidly with users.

Exploring alternative approaches

One set of explorations which was discarded was a story-based approach where instead of focusing on the breadth of apps, we would focus on the industry and story of the small businesses.

Ultimately this did not align with the principles of finding the right app quickly, but remains as a solid exploration of an alternative way to introduce apps to the QuickBooks user.

‍

The individual "app details" page

One of the most critical pages was the individual "app details" page, where each developer entered the information, video, and screenshots of their app. As this was a template page that would be different for each app, many revisions were tested to ensure edge-cases were not left out.

The same process of wireframe, code, validate, and progress fidelity was followed.

Validate, then validate again

With working code, UserTesting.com could also be used to validate the resonance of if what we were doing was working.

The design-thinking produce of UX continued as we neared the launch of our MVP, while at the same time the mobile-first responsive prototype progressed alongside, serving both designer and developer.

Iteratively building a working html/SCSS copy of our designs from the start

As a special mission for this project, I took on the role of parallel Principal Design Technologist and developed the mobile-first responsive CSS and HTML for the project (in SCSS using a modified Bootstrap grid as a base).

I built a working prototype on the code that translated design-to-browser, ensured proper front-end development, and educated the engineering partners on the "how" and "why" of building mobile-first. This allowed the developers to start their React.js components right away without needing final visuals.

I was able to test the rough ideas for layout decisions and mobile responsiveness right in the browser and hand it over to engineering. The iterative prototype looked like this:

This process involved me performing the following steps:

1. Creating the base SCSS package and responsive grid
2. Blocking out the basic site components and applying the mobile-first SCSS
3. Delivering the scaffolding to engineering directly in the code repository
4. Progress the prototype to match the designs and make pull-requests to engineers
5. Iterate as designs, prototype, and live site reached final parity

Throughout the process, I was also teaching the engineers unfamiliar with mobile-first development, responsive grids, and SCSS how to embrace these practices and apply them in their work.

BONUS: Turning the mobile-first responsive grid into a company-wide package

This approach and code packageevolved to become and Intuit standard and was turned into the central code package for use across the company, which I talk about in this portfolio case-study.

A net-new platform and one of QuickBooks' first mobile-first responsive properties

Apps.com was re-launched using our deeply researched designs, mobile-first & responsive designs and code, and a whole new approach to the marketplace experience on a 20-year old property.

Apps.com is live and has met all of its performance expectations, and continues to be a showcase example of QuickBooks design, mobile-first awareness, and design+code collaboration.

Apps.com lives on as a key Intuit property, and while I am no longer the designer for it, I enjoy watching it succeed and grow as a highlight of everyone who worked on it.