There’s plenty of discussions on the internet about whether or not designers should code, but what about API’s? Hear me out. I’m going to tell you about a project I’m working on and how I went from knowing almost nothing about API’s to knowing a little more than nothing and along the way, discovered how we could use the data in our design sketches.

This post was originally a talk given at AIGA West Michigan’s Design Week.

First, some background

I lead a small design team at Automattic. Our company is most known for this thing called WordPress.com, which essentially the hosted version of what many of you know as WordPress. A little over a year ago, we acquired the company who makes WooCommerce, which is an eCommerce platform for WordPress that allows you to sell anything online.

WooCommerce was built by developers, and coincidentally enough, it is used primarily by developers. It’s extremely flexible, but the user experience is not very intuitive and we aren’t finding many non technical store owners using it.

So what do we do?

One thing we found is that many WordPress.com users want a store, which is something we currently don’t have. WooCommerce is only available to those who have a self hosted WordPress site. So naturally, we want to bring the power and flexibility of WooCommerce to those on WordPress.com. This is a super exciting project because we have a blank slate to completely reimagine the user experience.

So, while a completely blank slate is a designer’s dream, in our case, it doesn’t make sense to also completely rewrite the code. WooCommerce has been around for six years and has gone through countless releases. If only we can use the underlying data to power this new experience…

Enter the API

So, we have WooCommerce as it exists as a plugin in one corner. As a designer, I like to think of it as made up of three parts: the UI that the store owner interacts with when they login in to create their store, how it manifests itself on the front end, and all the data and code underneath that makes this all happen.

An API will help us talk to the WooCommerce data over here in this plugin so we can plug it into our amazing new user experience on WP.com.

My designer brain likes to think of the data as being made of circles, squares, and triangles. The list of products is represented as a square. In WP.com, we create a square so that the we can grab the list of products and they can appear over here, but in a completely different design.

My interpretation is rather simplistic, but what a powerful concept! It means we don’t have to recreate all the wheels. This approach also gives us the added bonus of allowing our existing WooCommerce users continue to use the plugin and their store remains unaffected. And our brand new customers on WordPress.com are now able sell things on line. Everyone is happy.

API 101

Okay, so APIs. What exactly are they? Here’s a little 101: for designers, by a designer.

APIs are essentially a way for apps to talk to each other. They also provide documentation of functionality. What is available, how it must be used, and which formats are accepted.

Let me give you an example of this with the WooCommerce REST API. The REST API allows data to be Created, Read, Updated, and Deleted in a specific format called JSON.

I’m going to go over some API terms, using WooCommere REST API as the example.

Resource

A resource is anything you can Create, Read, Update, and Delete. Some examples in WooCommerce are products, orders, and coupons. So if I had an idea for a new app that made my smart lightbulbs turn blue every time a new order came in, I know that the WooCommerce REST API allows me access to orders.

Endpoint

An endpoint are things you can do to Resources. Let’s take orders for example: I can DELETE an order, which I probably don’t want to do very often, POST or create a new order, or GET an order. For my lightbulb idea, GET is the endpoint that interests me.

Routes

Routes are the path to get there. So for example if you wanted to view all the products in your store, you’d GET/products.

Seeing the data

Justin, a developer at Automattic built a console, which allows you to interact with the WooCommerce API in a user friendly way.

If you wanted to see a list of all the products, you would select ​​Get and type products. The sig- in to the right of the path is an important note. WooCommerce requires authentication to access a site. You can only access your own site because Order information for example, contains private customer information.

So, what can we do with this?

For this project we are designing in Sketch, starting with black and white low fidelity mockups. Just because the designs aren’t polished, doesn’t mean the content doesn’t have to be. Lorem ipsum isn’t going to cut it and neither will writing ‘Test Product with a long name’.

What if we used real data? The Craft plugin for Sketch is sort of like a bundle of cool plugins. One of them lets you insert real data. We can take any chunk of data we got using the dev console, add it into Sketch and it will update the UI.

Craft also lets you sync that to Invision. Now we have this working prototype we can show someone rather quickly without having to write any code, we only have to access it.

Using real data doesn’t only have to mean mucking about with the API. For example, our team started by conducting user research by directly taking to our current users and understanding their needs. When we created user stories and scenarios, they were directly based off of actual customers we talked to and stores that are currently running on WooCommerce like one shop that sells Granola. 

Utilizing real data in our designs has yielded better results, faster. Understanding the role API’s play in your project has made it easier to discuss product direction with the developers on the team and also gave me a broader understanding of what is possible.

This was originally posted on automattic.design.