Note: due to the nature of the product, I am withholding much of the copy from these screens.
Overview
Our products, called the Insights APIs, provide anonymized, aggregated transaction data from millions of credit & debit cards. Because there is a knowledge barrier between the many who need the API data and the few who know how to access it, this GUI seeks to promote plug-and-play access to the widely demanded data.
Design Team
I led all forms of UX research and UX design.
Scope
Build out multiple versions of a GUI that scales exactly with our API capabilities, starting with an MVP and moving onto future versions with more features.
Methods & Practices
Research
Stakeholder Interviews • Persona Creation • User Interviews (anticipated) • Usability Testing (anticipated)
Design
Wireframing • Rapid Prototyping • Specifications Documentation • Feature Prioritization
Tools
Figma • JIRA• Miro • InVision Freehand
Timeline
Ongoing. Portfolio page will be updated as needed.
Our insights, and who can access them
Our products, called the Insights APIs, provide anonymized, aggregated transaction data from millions of credit & debit cards.
This data can be incredibly useful to those looking to analyze the market, and how consumer spend has changed over time.
However, the biggest barrier to entry is the technical know-how you need in order to query the data. You have to know which endpoints you need, and how to call them, in order to benefit from the API.
If you want to slice & dice the data in a certain way, you’ll need intimate familiarity with exactly how to get to that point, especially since some valuable query combinations can be tricky to execute.
This leads to bad bottlenecks, as every business or account manager flocks to their data teams to complete pulls and requests.
As explained by someone we talked to about this very issue…
"The data team is the bottleneck in terms of responding to requests. If we reduce the amount of requests going into the funnel, that frees up everybody’s time.”
So how can we reduce the bottleneck?
Our product and sales teams combined forces to decide on a GUI. A GUI would enable widespread access to the API without needing to know exactly which endpoint to call, and how to query an API.
Due to the urgency of the product, our assumptions for the market need were to be validated as soon as a working prototype, and a willing group of target users, could be established.
The nicheness of the target users were a challenge in this build.
Constraints with finding our target users
There were two key anticipated users we kept in mind as we worked:
1. Consultants/marketers who rely on nation-wide consumer data in their day-to-day (our clients)
2. Internal sales team members
The first group would want access without knowing how to code. They would want answers to questions such as:
"Who's winning in the market right now?"
"Which shoppers are migrating from Brand A to Brand B?"
"How many shoppers are returning this year versus the last year at these brands?"
The second group would benefit from using the GUI to depict the power of our data, reducing friction in client onboarding.
While we would be able to conduct user interviews and usability tests with internal sales team members, we had to rely on sales team outreach in order to find suitable users among our clients.
Additionally, we needed to utilize the sales team members' brains when it came to our clients' goals, needs, and pain points.
Constraints with building our API-first design
Our product and engineering teams had a foregone requirement that the (GUI) needed to be in lock-step with the API structure.
In other words, there should be minimal extra customization to the front-end of the GUI. Every feature currently available in the API should be in the GUI; no more, and no less.
And should anything change within the API, the GUI should automatically change along with it.
Why?
It’s meant to be a scalable and futureproof way to utilize the API’s powers.
With this in mind, I worked on a way to build a design that would delight our sales team members, our clients, and our engineers.
Where I started
Working with the product manager who owned the API, I began with a minimalist design which would function as a form field for all the various filters and endpoints our API had available.
In these images and conversations, the word "breakout" can be defined as a specific filter of group of filters.
A modified snippet of the first draft of our "Reports" page
This first version was API-first, had no data visualizations, and involved a form field-heavy interface.
Because it was API-first, there was no allowance on the timeline for front-end customization. Whatever structure the API had would be what the GUI looked like — so no bar charts, line graphs, or scattergrams of data just yet.
Some comparators I used to examine best practices for such filter-heavy interfaces were the Google Analytics dashboard, and the Wix site dashboard, both of which involved a lot of time control as well as site audience filters.
I had assumptions at this point for where users might stumble: for example, what is a panel? What are the differences between all the Insights reports? And how could I ensure that users weren’t disappointed with the eventual output they'd receive when they submitted the form – an Excel spreadsheet link?
First round of feedback from internal users
I got a wide range of feedback, varying from visual to tactile. My sales team's biggest concern, however, was being able to know what they were going to get when they clicked that form submission button.
“I think it could be more compact…”
“I’d like some kind of warning if you try to run something, and it's gonna take like an hour and a half to process.”
“I want a summary of CSV output: total number of rows, grand total of spend, etcetera. I want to see the Excel sheet on the screen as a preview, and scroll up and down within the window. Seeing some kind of preview is a requirement to me.”
As a result, I reworked some of the look & feel for the GUI, and took into account their desired pre-submission error warnings.
Once I came up with our next wireframe, which the sales team approved of, I needed engineering eyes on our current design.
Second round of feedback from our engineers
The biggest changes to the next version were downsized whitespace, pre-submission error messaging, and a summary of the expected output before it was received.
However, touching base with the engineering team showed me that I had a lot of discrepancies between how the API currently worked, and how my arrangement of form fields currently functioned!
There were some front-end customizations I was making without even realizing I was making.
“Channel [options are] good, but it’s a true false. Here it's a filter.”
“Card type is also a true false; not a filter.”
Here, I had certain "breakout" options presented as dropdown selections, or "filters,’" as our lead engineer put it. He emphasized that they were booleans (true or falses), and he suggested they should be radio buttons instead of selections.
Otherwise, it wouldn’t be 1:1 with the API.
There were some more complicated examples, too.
“[These two buttons are] two interactions: what breakouts exist, and which ones are actually being filtered? By default, all [of breakout 1] is not selected. Like, it's not gonna breakout by [those].
It’s the same thing with [breakout 2 dropdowns] – there should be a way to not breakout, at all.”
To summarize: I was putting breakouts into certain groups where, in the API structure, they did not exist in those particular groupings. Because of these discrepancies, there wouldn't be a 1:1 match between the API and the GUI.
Beyond that, there were smaller rules in the API I learned I was breaking. I sat down with engineering several times, getting their comments on every UI aspect of our design to ensure we would be on a 1:1 match.
Current iteration of MVP
After engineering buy-in, running roleplay usability tests with our sales team members (who would use their knowledge of our clients to act as our target user), and going through sentence revisions and wordsmithing with our copywriter, I reached my current iteration.
This version is presently being developed, QA'd, and then design reviewed by me.
A short video showing our new and improved Reports page, with 1:1 API match ensured
As this product is continuing to be developed, more user research, copywriter collaboration, and engineering collaboration is certainly on the way!
If I could go back and redo some things, I would have...
Included our copywriter much earlier in the process.
It would’ve been helpful for my copywriter and I to both have sat down with my product manager whenever he was explaining terms, or how exactly clients used particular features within the API.
Not only would it have saved us some questioning back and forth, I think it would’ve helped us present an even stronger prototype to our sales team when we got them into the client "roleplay,” and let them focus on something else other than confusing text.
Put our sales team members into our target user mindset as much as possible.
Until we roleplayed as user researcher and target client, our sales team wasn't fully engaging with the mockups and prototypes before them. Feedback was much more robust when they were getting into the mindset of the user they knew very well.
Knowing what I know about facilitating now, I'd have more specific questions about how the user might navigate the interface earlier on in the design process, and unlocked more feedback and engagement earlier on.
Considered the layout of pages more carefully when it came to scalability and adding features in the future.
How easy would it it be to add more breakouts, more paragraphs, or even more customization options with my current hierarchy?
There were times I had to readjust the alignments and placements of objects many times over, and it could become a tedious task. I think that could’ve been prevented if I had a clearer template and foundation to work off of from the start.
Wrapping up
As I've mentioned before, this is an ongoing project! Content on this page may be updated or changed as time goes on.
If you've made it this far, thank you for reading! And why not get in touch if something sparks your interest?
