Fairly recently, I went through a rough time at work. I was working on a project that seemed to go on forever with no end in sight. The scope kept growing, we designed for all the edge cases, and we focused on features instead of who was going to use the product and how. I knew it wasn’t the right way to go about it, but was also so deeply involved, I lost sense of the bigger picture. In the end, we launched it and eventually handed over the project to another designer to make room for a new project.
We were going to add eCommerce capability to WordPress.com. If I thought the last project was big, this was a whole ‘nother story. It turns out that WordPress.com is great if you want a blog or a website, but if you want to sell things on that blog or website, we don’t offer a great solution. I was super excited about the project, but also determined not to repeat my past mistakes. This was going to be a user centric, design lead product. We were going to talk to our users, understand their needs, and focus on flows instead of features.
We were a tiny team at first with only two designs and two developers. The design team got together and put a process in place that would put the entire focus on our users.
User research
It is difficult to build something great for people if we don’t know who those people are. One way to get to know someone is to talk to them. We had our user research initiative underway and had already been learning so much from our users about who they are, what their daily tasks are, and the pain points they face. Everyone on the team contributed in leading and attending these interviews. These conversations started to inform the product decisions and priorities around getting a store up and running using WordPress.com.
We also talk to our very own happiness engineers, who are on the ground supporting our users on a daily basis. They give us invaluable feedback on our products and help inform decisions around priorities in our road-mapping discussions.
Competitive and self analysis
The two designers on this project are myself and Jay and we are seven timezones apart. We happened to be together at a meetup when we started product discussions. We used this in-person time to put ourself in our users shoes. With the rest of the team, we walked through setting up a shop first with our very own WooCommerce and then with our competitors. We noted pain points along the way, which helped to inform the biggest areas of opportunities. This, on top of interviewing actual users was starting to give us a big picture of the things we are currently doing well and where we most need to improve.
Scenarios
Identifying the top scenarios we want to serve for the initial launch was another item we worked through at our meetup. This would help us inform the top flows for each. We settled on two very broad scenarios around setup and management.
- I want a store (setup)
- I am managing my store (management)
Flows & success metrics
Given these two large scenarios of setting up a new store and management, we started defining the essential flows for each. We began by brainstorming what the bare minimum was needed to set up a store, using what we learned from our customers, talking with support, and competitive analysis. Focusing only on the must-do’s for store setup and management helped to keep our scope small. Success metrics were defined for each flow to give us a guide to refer to during this whole design process: If a user starts with X in mind, we’ll know we have a successful design if Y is the outcome.
Steps within each flow
Once we were satisfied with our flows, the next thing we did was to actually list out the steps one would need to take in order to reach the successful outcome. We found that listing is much faster than jumping straight to drawing and you don’t have the ‘blank canvas’ anxiety.
Prototypes
With our scenarios, flows, and steps in hand, the mockups began! Our goal was to never deliver a flat design to anyone. Setting up a store is comprised of jobs to be done: You have to add the products you want to sell, set up shipping, customize the look and feel of your store, etc. None of these tasks are single features on a page; they are all complete flows. This means we would only deliver clickable prototypes along with a scenario to set the scene and a task for our testers to complete.
Show & tell
Twice a week, the design team Jay and I are apart of meet via video chat to show and talk about our work. Every Tuesday and Thursday, we would come to the meeting ready to show our latest prototype. Someone from the team would volunteer to click on the link, share their screen, read the scenario, and the task we’d like them to perform. An example would be: “My store is in the United States. I’ve already added all my products and I’m ready to set up shipping. I want to ship world wide, but also have my potential customers who live in my town have the option to pick their items up.” Then the volunteer would click on the link to open the prototype, and we’d watch them walk through it, taking notes, and discuss afterward.
Iterate
We’d take this feedback and iterate on the prototypes, clean them up a bit, before showing them to test on others for further feedback. We’d refine our prototypes until they were intuitive to the people testing them.
Implement
Once we had tested out our prototypes with several people, we’d add each story up on Github. When the developers were ready to implement a story, we’d go over it and discuss any questions or concerns they had. Sometimes this would mean cleaning up a design file for clarification or adding a scenario we’d miss. The developers would then take our flows and break them up into tasks and start coding. When they had a pull request ready for review, we would test it out, request changes, make changes to copy, and refine the styling.
Repeat
As full flows were implemented, we were able to continue testing using the actual product instead of clickable prototypes. This allowed us to refine even further and get us closer to a smoother experience before launch. We iterated. We tested. We went back to do some quick prototypes when larger issues were discovered. Iterate. Test. Repeat.
The fun part
We launched this to small set of users last week! It was one of the most exciting things I’ve launched while at Automattic. More to come on that next time…
Automattic Design 