Raising Our User Experience Design Bar
Since shipping the MVP over four years ago, the Creative Market team has been building new features and iterating on existing ones. We started off as a small, scrappy team that built product with tremendous speed. As we grew, we introduced cross-functional product teams and agile thinking to stay as nimble as possible.
Yet, it became clear that we weren’t hitting the mark with our user experience design efforts. Our product teams would discover additional user dynamics and nuances that weren’t considered too late in the project cycle. These issues would stop a project in its tracks during the late stage and create some serious problems for the team.
Unfortunately, this pattern became our norm. It was a costly pattern for the company and a painful experience for our product teams. It looked a lot like a game of UX design whack-a-mole. So, instead of waiting for these issues to arise, we needed to front-load projects with more user experience thinking and documentation to protect the integrity of the work and the team’s time.
Our UX Challenges
I set out to understand how our user experience design pain points were occurring and how we might address these challenges with adjustments to our project process and deliverables. If we wanted to have the best chance of scaling good user experience design culture into our future, then this needed to become priority numero uno.
Here are some of the key challenges that we faced:
Product Complexity: Since launching the MVP, we built dozens of features onto our core product. How the entire product ecosystem works and how features are interconnected became more complex with every project we shipped. It became increasingly difficult to keep track of and understand the whole landscape. During any project, it became very easy to miss multiple user dynamics due to a lack of system transparency.
Historical Context: The core team who built and expanded the MVP held critical knowledge about user experience nuances and product decisions that shaped our current system. As the design lead, there was a lot in my head that others needed access to, so it was time to decentralize these insights and make them available to the team. There was a lot of valuable insights in the head of our development lead, too. It was time to spread the knowledge to the rest of the team who are actively working on the product.
Process Improvements: We didn’t define how the team should consider user experience dynamics as part of the early phase of the design process. We were jumping into wireframes and comps without thinking through all of the hidden parts of our product’s user experience first. We needed to define which UX deliverables to create, what they needed to express, and when to deliver them.
Here are some of the areas that we needed to address in order to make an impact on the challenges we were facing:
User Feedback: Our team historically didn’t talk to our users about the product we were building for them. We needed a method to listen to the wants and needs of our users as part of the product design. We positioned Kelley Johnson, our community manager, to run point on gathering user feedback before, during, and after product projects. These efforts ranged from 1-on-1 interviews, group sessions, surveys, prototype testing, and more.
UX Documentation: We needed to define the deliverables that would strengthen our UX in the design process. It had to be a set of lean deliverables that covered the needs of our platform and users simultaneously. It had to work for different product teams and scale up or down against the needs and scope of each project. We also needed a way to document our product’s complexities so that the team could make better, more informed decisions. Whether we were building big things or optimizing small ones, the team needed clarity in order to make the best decisions for our users.
UX Education: We needed to see a greater frequency of team member’s having meaningful user experience focused conversations before, during, and after both product and brand initiatives. We needed ongoing education about what good user experience design means for our two-sided eCommerce platform and best practices too.
Collectively, our team has made some meaningful progress during 2016 with these challenges. Here’s a look at what we’ve introduced.
It goes without saying that the best place to start with improving the user experience design of a product is to look to your users for feedback. In the past, we captured minimal feedback from our users, but it was time to really double-down and make user feedback critical to our product design process.
Our community manager, Kelley Johnson, helped us define the goal of our user feedback initiative. She worked with our product manager lead, Josh Johnson, to figure out how it fit into our product process.
Here are some of the ways we’ve improved gathering user feedback to strengthen our UX design efforts:
- Feedback Group: Our feedback group is a collection of over 150 of our users who volunteer their time and feedback when we need it during our design process. The community team actively identifies shop owners and customers who might be a good fit for our group, and they invite ~5 new members each week. At any given time, we can run feedback with portions of this user group for multiple projects. If we don’t have the right users in this group to test a product idea with, we can rely on the community team to help us find and connect with the right folks. This initiative frees up product managers and designers from spending time finding the right users to talk to, and gives them a collaborative partner who can run objective feedback sessions, surveys, and interviews.
- Feedback Satisfaction Rating: After we ship a product feature, Kelley sends out a survey to the users who gave feedback on it. It helps us rate how we’re doing at listening to our users and incorporating their feedback in our design process. This ensures that we’re aligning our user experience design decisions with the actual needs of the users who will use what we build. We ask simple questions such as if users feel like their feedback was adequately considered. Our target survey rating is 8.5 and we’ve largely been successful in maintaining this rating across a few product projects so far.
- Process: We choose when to ask our users for feedback at different times of the product process. We don’t request feedback at every point of every project, but choose strategically which project and at what point we need feedback. We’ll ask users for feedback about product ideas before we’ve shaped or committed to them. We’ll ask users for insights while we’re scoping features to make sure the right elements are included. We’ll send along early interactive prototypes to users to gather insights about their experience of what we’re building. We’ll ask users what they think of a live feature while we’re putting the finishing touches on the code or after we’ve launched the final version. We’ve found that feedback at all of these phases of a project has helped us make better user experience design decisions. We’ve also seen it reveal unforeseen issues that would have otherwise been missed, too.
- Tools: We use Google Forms to build surveys. We build interactive comp prototypes in InVision and interactive wireframe prototypes in Adobe XD. We use Google Hangouts to record 1-on-1 interviews of users engaging with these prototypes. These simple tools have proven sufficient for us to capture user feedback that empowers us to make the best UX design decisions for our users.
Talking to our users during product work has now become our new norm. Our recent user feedback efforts have raised the UX design bar of our team tremendously. We’ve come a long way.
In my experience, good documentation is the written work that shapes and supports the product design and development work. Documents such as product specs, feature scopes, and technical specs help define and guide the work like an airport control tower.
That being said, I realized that product designers aren’t required to write about their product design work before they start wireframing or comping it. They don’t write out a detailed intention of the user’s experience in the product that they’re about to design and tend to jump into the comp work without doing much user experience design due diligence through writing. In essence, they don’t create a plan for their work before beginning and that’s a dangerous thing.
We spent a good bit of time discussing what sort of UX deliverables could help us identify and define the user’s experience before wires or pixels are pushed. We arrived at a new primary deliverable the has ensured that our user experience design work maintains a high bar of quality. Then, we identified a few other supportive, secondary documents that help us maintain the integrity of our existing product design system and protect our users and their flows through it — regardless of what new features we might build.
The “UX Plan” was our most decisive blow against our poor user experience design issues. The user experience plan is a written document in which the product designer expands the project scope into a prescriptive, detailed outline of all page, user, and content states that they expect to design for users to experience in the feature across the product eco-system. In essence, it’s a plan for what states require wireframes and/or comps, and the content and interactions that should be designed for from top-left to bottom-right of every page state.
Requiring a product designer to spend time writing their own comp specs before they open Photoshop or Sketch sounds a little crazy, right? Well, we’ve found that it’s been golden for our team, and we stand by it proudly.
Here’s how the UX plan has benefited our product teams and their work:
- Ensures the team front-loads all user experience considerations in the early phase
- Defines the user’s experience of a product feature before visual design work begins
- Provides product managers and designers a written deliverable that they can build and maintain together during the project
- Prescribes all states, content, and interactions for the wires and comps
- Locks-in copy and brand visual needs as wires and comps begin
- Creates a uniform, structured design deliverable for cross-functional product teams
- Promotes greater collaboration and transparency
- Decreases UX pitfalls and issues later in the build cycle
- Builds up an archive directory of each product feature we work on
Now, I don’t want to get too much into what a UX plan looks like and how to write one. You can find out more about that from an upcoming post that our lead senior product designer, Noah Stokes, is writing. However, here’s a quick example of the beginning of a UX plan.
As you can see, it’s essentially a structured outline written up in Dropbox Paper. The top level of the outline begins with the page state (e.g. 1. Following Feed Page), followed by the user state (e.g. a. Shop Owner (Signed-In)). Next, we display a summary table for this particular page state, and we capture details such as the page type, user type, user states, user flows (previous and next), devices, and reference documents in it.
Below all that is where the real meat starts. We list the content and interactive states of it in a linear order, from top-left to bottom-right as it will show up on the page. We define interactive states such as hovers and clicks, and try to be as prescriptive as possible. We also use emojis to identify project needs inline in the UX Plan, such as the following: design wires/comps (heart), copy (paper & pencil), tracking (graph), brand visuals (stars), and testing (tools).
So far, this level of documentation has helped us define everything the user will experience for each project, and we’ve had a lot of success with it. This deliverable, paired with user flows, single-handedly eliminate 90% of our user experience design issues because it prescribes all details in a thorough, cohesive plan.
User Flows aren’t a new UX deliverable, but they’ve become critical for us. In order to visualize the high-level view of what’s in a long, detailed UX Plan, we create User Flows and pair to our UX Plans.
In the past, we created Information Architecture sheets that list all of the page states that we intend to create from scratch or require adjustments in relation to the feature work. Here’s an example of that:
These days, because the UX Plan lists out all of the pages we intend to design or edit, we create more true-to-form User Flows. We pair these with the UX Plan by labeling the page states on the User Flow to match to their corresponding position in the UX Plan (e.g. 1., 2., 3., etc.). Here’s an example:
Beyond documents that help us work on each individual project, we’ve also started two other UX deliverables the define and cover our current system. The first one is our Pattern Journal. Essentially, this is our effort to define and maintain the design system of some of our complex features on the site such as the Purchase Flow and Product Page/Editor. The second one is our UX Checklists, which are documents that list out key user dynamics and considerations that are unique to our product eco-system. Both of these deliverables help us explain the history of design decisions that have been made and help us keep track of new tests and improvements to the system so that the team is clear about the current product landscape.
Last but not least comes the most important part of user experience design — sharing insights, best practices, and lessons with the team. As our design team has developed new deliverables and processes that improve our user experience design efforts, we’ve started sharing these with the rest of the team on our company Blogin.
Our next steps are to continue gathering insights from our own community and their experience with our product and to seek out informative UX best practices too. As we gather these insights, we’ll continue to share them with our team in the form of articles, workshops, and presentations.
We also hope to share more of our lessons and insights with you on Medium, as well. Thanks for reading!