Growing my skills with side projects

I recently started working on a new side project and noticed it’s starting to paying off both personally and professionally. It got me thinking about all the projects I have done before it and one of the common threads that stuck out was that they each helped me feel happier and healthier. They created a space for me to break away from work, practice my craft, and experience new things.

Now, as a father of three kids with a very demanding job, I will be the first to admit that it’s hard to make time for this kind of thing but just like just like exercising, I believe that taking on projects outside of work is something I need to prioritize to be on the top of my professional and personal game. As I reflected back, I thought I’d share some of the projects I have worked on and how they’ve paid off:

Hundred days of sketching

A little over a month ago I committed to a hundred days of sketching as part of the hundred day creative challenge. At the end of most days, I open my sketch book and spend some time running through a number of exercises until I’m happy with the end result or my page is full. I almost always start with the date and then reflect back on my day while sketching all kinds of things. After I’m done, I post the sketch up on a blog I created just for this very purpose so I can look back over time and also hold myself accountable.

The mental pause from work, and everyday life, is very relaxing. In some ways it’s like therapy as I process my thoughts and express them visually. I have also found myself rediscovering old personal interests like nature, patterns, numbers, and letters. The every day practice of exploring and being creative feels like it’s rubbing off on my work because it feels easier for me to come up with more comps when I’m evaluating solutions to a problem.

I have begun looking forward to this time everyday and look forward to continuing with this practice hopefully beyond the hundred day challenge.

Design herald

A couple years ago, I wanted to have a go at creating my own app and looked at my personal interests for inspiration. Since I like staying up to date with the news, and also get lots of enjoyment from apps like Yahoo and Google News, I thought why not create a news app for designers. I came up with an idea for an app called Design Herald that would aggregate and curate the top UX design news from across the web.

It was a lot of fun coming up with the name, doing some branding work, and designing the interface. From a development perspective, I decided to go with React Native because it’s a JavaScript language, which I know how to write, and it compiles to multiple platforms like iOS and Android — plus it was what everyone was talking about at the time. I dove right in to the code and learned as I went. I built a backend tool with Drupal that collected all the news and aggregated it into a single source that could be consumed by the app.

After a couple weeks, I had a fully functioning app working on my local machine. That’s when I ran into problems because I couldn’t find any documentation for actually publishing the app to the various App Stores. I was a little disappointed but not overly worried because I learned a new programming language and had lots of fun in the process. A month or two later, I started a new job at Automattic and was happy to find out that they used React as their code base for WordPress.com. Thanks to my side project I was able to jump right into the code and add extra value by executing my own a/b tests and project work.

Design herald — take two

Although my initial attempt at launching Design Herald didn’t work, the idea didn’t die there. Almost two years later, an opportunity to revive my idea presented itself when I was promoted to Design Director of the UX practice at Automattic. I was assigned seven direct reports and one of my responsibilities, as their director, was to level up their skills in the UX discipline. Sharing the latest design news and articles seemed like an obvious first step in doing that but regularly posting links into our Slack group got annoying very quickly — that’s when I remembered Design Herald.

I dug up my old app and spent a bunch of time trying to get it running again but that wasn’t going anywhere so I thought I would approach it from a different angle — this time I had the idea of combining WordPress and IFTTT. With IFTTT, I was able to “watch” any site’s RSS feed and then, if the feed updated, I could post the article to my new WordPress site. Compared to the app that took me a couple weeks to develop, this new approach only took me a couple days to get up and running. All I needed to do was create a WordPress.com site, gather up my sources, and setup all my “Applets” in IFTTT.

One of the first things I noticed after setting it up was there was a lot of sponsored content coming through. An update to my IFTTT settings allowed me to set the posts as drafts rather than publishing then publicly right away and that was all fixed up. This new work flow also meant that I needed to spend a little extra time to review the posts but that actually turned out to be a good thing for me because now I’m staying up to date with all the latest UX news.

Personal site

When I first read about progressive web apps my imagination went wild thinking of all the different things you could do with them. Unfortunately the role I was working in at the time was unrelated and didn’t afford me the opportunity to explore those possibilities. I therefore decided to pursue this interest on my own time and created a side project to dig in and learn more.

My idea was to rethink my personal website as a progressive web app. At the time, I had been blogging with WordPress.com for a couple months and the site I had was more than enough but when I looked at what some of the competitors we’re doing, there were parts of it that were outdated. The new format of a progressive web app gave me the opportunity to incorporate some more modern blogging features along with some of the benefits that progressive web apps bring.

Once I completed my new design, I took the opportunity to practice my React skills and started coding. Looking back, I can easily say this was the most ambitious coding project I ever worked on and in the end it payed off because not only did I get a new site but I also learned a lot about developing with React. Thanks to all those extra hours of practice, I feel more confident taking on development projects in my day to day work and have also become a regular contributor to our development efforts.

Hundred days of patterns

The first time I heard about the hundred day creative project was back in 2014. Cassie Slack, a designer colleague at Shopify, introduced me to the idea while presenting her work to the rest of the design team. Her work inspired a number of us to try the project or for ourselves. Some people created visual art like portraits and illustrations, some wrote stories and limericks, and others played music — I chose to design patterns.

My first patterns were replicas and then I moved on to making my own. Early on in the project, I noticed that I liked working with colour too so that introduced a whole other dimension for me to experiment with. I tried all kinds of combinations and even went monochromatic for a while. The constrains I placed on myself lead to some interesting outcomes.

I noticed the creative practice rubbing off on my day to day work as a marketing designer. It started getting easier for me to come up with lots of different ideas for our campaigns and I also experimented with colours I would never dream of using before. The overall experience left quite an impression on me because I often tell people about it and I also just decided to pickup another hundred day challenge again.

Wrapping up

If you made it all the way down here, thank you for reading. I hope you can see how beneficial these projects have been for me. If you’re working on a project yourself or have any ideas for a new one, I’d love to hear about them — just reach out to me over LinkedIn.

Are more features the answer?

The other day I went for my routine hair cut and as I sat to get started I noticed a sign that read “tag us in your haircut selfie”. It wasn’t a surprise to me that the hair salon would use Instagram as a way to attract new customers but I was interested to learn how effective it’s been for them — so I asked my hairdresser that also owns the salon.

She replied that these days it’s vital to have an online presence if you want to attract new customers. Instagram is one of the first places her customers go to see her work. Then she told me they go to her website which was a nice segue because, since she’s a WordPress.com customer, I wanted to learn more about what value she gets from her site. The top reasons were for people go to see what services they offer, find the salon’s address and phone number, and book appointments.

One of her main concerns with the site was that it didn’t work well on mobile but she was very happy with the contact form because it allows her to take bookings which is really critical for her business. She said these days people don’t like calling in because she thinks they like to be able to discretely go about their personal business while at work.

I was very intrigued to hear this and also surprised because I thought a basic contact form would be cumbersome for booking appointments. I imagine it would be annoying to write in and then try communicate your availability over email but I was wrong. When I asked why she doesn’t use an online booking service, she told me that those usually cause more problems than they’re worth. The biggest issue she found was that people don’t know how long they need to book for a particular service, something I am sure could be easily solved, so they prefer to talk with their customers to learn what they need and then book the appropriate time.

Later that day, I embarrassingly locked myself outside the house and had to call a locksmith to get back in. While I was paying the guy, I noticed he used a Square card reader and asked him how it works. He showed me how he tracks transactions and told me he could make reports but doesn’t because the software was too complicated and so he therefor prefers to export the data and make his own in a spread sheet.

Both these encounters reminded me of a research study we did about small customers early last year. A number of the participants we spoke to echoed how complicated software could be and how they cooked up simpler solutions with spreadsheets and notebooks. This was a good reminder for me because at work we’re often worrying that we need more features to make our product more attractive when in reality, I think we offer everything we probably need to but don’t promote the features in such a way that people know how to use them better.

Synthesizing usability test results

This week we got another usability study in the books by testing the most recent iteration of our signup and onboarding flow. Thanks to some help from our design operations team I was able to pull it off without a hitch. All I had to do was fill in a request, slightly massage a template script, and then show up for the sessions. Our recruitment coordinator, the amazing Lilibet Greig, did the rest by finding participants, screening them, and then following up with them to make sure they showed up for the study.

Running the test

Over the course of a week, I worked with two other designers to interview six participants and watched them build a website with WordPress.com. Each key segment of our customer base was represented and their experience using site builders ranged from novice to professional.

Starting from our marketing home page, they were asked to verbalize their thoughts as they made their way through the process. While one of us spoke with and guided the participants, the others documented their observations and quotes as individual cards on our virtual Mural board. The board was divided into sections representing each screen in our flow and we used different colour “stickies” for each participant.

Synthesizing the results

Once we completed the sessions, I made sure to go through all the recordings, including the ones I moderated, and added my notes to the board. It might seem redundant for multiple people to take notes but I think it’s important to bring multiple perspectives from different view points because we all perceive things differently.

We gathered a great deal of raw data from this study and I won’t lie when I say it was kind of intimidating to think how long it would take to comb through it all but I eventually got through it thanks to the colour coding and organization of the board. I read every single note and grouped similar items to identify patterns which lead to insights that I used to put a report together along with my recommendations.

Creating a report

The final report turned out to be fairly long due to the amount of ground we covered in the study. I therefore summarized the top findings and recommendations on the front page to make it easy to digest. I made sure to include direct quotes and video snippets though out the rest of the report to back up the insights because nothing beats seeing things with your own eyes.

Now that we have our list of recommendations, I’m going to work with my product and engineering partners to prioritize them using the ICE method.

The outcome

Doing usability studies, and customer interviews, are always exciting for me because not only can you uncover problems with your design but you can also be inspired with new ideas. This study was no different — we uncovered some issues in our flow and by means of observing people use our product, I come up with some new directions to explore.

Managing a project with a remote team

One of the things I like most about working at a distributed company is that I get to work with people from all over the world. Being exposed to other cultures and ways of life has helped me grow as a person. This perk can however come with its challenges as I learned after leading a number of projects with colleagues spread across multiple time zones.

Coordinating meetings, staying in sync, and maintaining momentum can be tricky at times but it’s not impossible thanks to a number of tools and processes which I’ll cover in this post. I’ll start with the brief because it’s a great starting point for every project.

The brief

A brief is a high level document that tells you everything you need to know about a project. The idea is to keep it short so that anyone can easily consume it and get up to speed with what you’re building, why you’re building it, and the current status of the project. It’s the kind of thing you want to share early in a project to collect feedback and align stakeholders on what you’re trying to do.

Everyone approaches their briefs a little differently because of the nature of their project, company, or stakeholders. I like to treat them as living documents and start with a set of questions that evolve over time as we get closer to delivery. These are the questions I used for my last project:

  • What problem are you trying to solve?
  • What’s your bet?
  • What’s the desired outcome?
  • How will you measure success?
  • Who are the stakeholders?
  • Frequently asked questions

Thanks to its collaborative features, Google Docs is the perfect tool for working on a brief. It makes it really easy for anyone to jump in, leave comments, or contribute at any time.

Kick off meeting

Once you have your brief in a good place, and you know what problem your trying to solve, then it’s a good time to meet with your team and kick things off. The goal of this meeting should be to determine clear roles for everyone on the team but it’s also a great time to review the brief, discuss timelines, and agree on how you will work as a team.

At Automattic, we do the majority of our calls over Zoom video chat and use a tool called Doodle to help schedule a time that works for everyone. There are times we use Slack Video Conferencing or Google Hangouts but prefer Zoom for groups of people because it has the best quality. For these types of calls, we record the meeting, take notes, and post them in a place where people, that couldn’t make the call, can comment on them at a later date.

Slack

It’s important for distributed teams to have an open line of communication so they can share their progress, stay up to date with what others are doing, and ask questions. I like to use a dedicated project channel on Slack to create a virtual home for the team to collaborate and have discussions.

We value transparency at Automattic so these are usually public channels that anyone at the company can join to keep track of progress, provide feedback, and ask questions. As good as Slack can be for teams to communicate in real time, it can also be tough for folks in different timezones to participate in conversations because things can easily get lost in the back scroll. For that reason, it’s good to consider additional commutation channels that are better at preserving decisions and facilitating asynchronous discussions.

P2

At Automattic, we use an internal network of blogs, called P2, to document decisions and communicate asynchronously. There’s a social element to the blogs so that you can @mention other folks to grab their attention or cross post your message to another blog if you’d like to share something with an entire group of people following that blog. Being able to comment on each other’s posts is where the real magic happens. At first, it can be tricky to know where you post something, or what you post on P2 compared to sharing it in Slack, but over time it starts to feel very natural.

In the context of our projects, we have a dedicated P2 to memorialize decisions made in Slack, share updates across the company, and getting feedback from people outside the project team.

Project board

Having a board where you can see every piece of work that needs to happen is a beautiful thing. When it’s done right, people know exactly what to do and do it. Momentum builds and projects get delivered. This is a habit traditionally practiced by developers but I have found lots of success incorporating the work of other team members, like designers, marketers, and writers, into the board as well.

Our project boards generally follow a common pattern with a Backlog column for new tasks, an Up Next column for prioritized tasks that should be worked on next, a Doing column for tasks being worked on, a Requires Review column for tasks that require feedback, and lastly a Done column for completed tasks. Up until very recently, our team was using Trello to manage our work but we just made the switch over to Github Projects. Both tools have their ups and downs but the move was ultimately made so we can reduce duplicated efforts with a tool that’s already part of the developers’ workflow.

Now, it would be nice if these boards managed themselves but unfortunately they don’t. In order to keep up our up to date, a group of folks from the team meet weekly to review our progress, groom our backlog, prioritize our work for the next week, and then publish a report to keep our stakeholders up to date. As the week goes on, team members pick up cards on the board, assign themselves to them, do the work, and share their progress when necessary.

Status updates

For status updates we use Geekbot for sending an automated Slack prompt that asks people a series of questions. We started out with infrequent weekly prompts early in the project and then switched to daily prompts as we drew closer to our deadline. We crafted the questions in the prompt so we could learn how people were feeling about the general status of the project, what they had completed since the last update, what they would work on next, and if they had any roadblocks. The updates were helpful for everyone to see what they were all working on and to help each other out when roadblocks popped up.

Feedback

Feedback comes in many forms and is invaluable for baking quality into your product. On the design side, we have regular design critiques where we bring designers and developers, from across the company, together to review work and offer feedback. Work is also posted in multiple formats for people to review and share their thoughts on their own time.

On the development side, we do code reviews to not only make sure we’re writing good code but also to test the work that’s being implement. Both designers and developers participate in the review process so we can work collaboratively to highlight any issues and also overcome any unexpected issues.

Collecting internal feedback is great but can still leave you open to making mistakes. This is why it’s so important to include your customers in your product development cycle. We do this by running usability studies at various stages of our projects. At the beginning, they’re helpful for understanding your customers expectations, problems, and view points. Then as the product evolves, it’s helpful seeing customers using what you created first hand to uncover any problems they’re running into. Usually five to eight sessions are enough to give you what you need.

Retrospectives

Even though there is lots of communication throughout a project, I believe that it’s important to take deliberate time to look back and see how things are going. I say deliberate because there have been so many times where things felt like they were going well until we took the time to dig in and all of a sudden we found all kinds of issues. Those were hard discussions for a number of reasons but we all felt better for having them and improved as a team.

There are a number of retrospective activities out there but we keep going back to the tried and true “Start, Stop, Continue” because it just works. We use Funretro.io as a digital board for people to add their “stickies” on their own time and then we meet as a group to discuss what everyone added. As people read through their stickies, we ask them to group them with similar topics on the board. Lastly, we vote on the topics we would like to cover and then pick the top 3 we want to action on before our next retro.

So how different is it working with a remote team

The majority of things I shared in this post aren’t unique to remote teams. As a matter of fact, I have been working with most of these methods, and tools, longer than I have been working at a remote company. There might be some minor differences in how you do things but at the end of the day, whether you work in an office or with a remote team, the key to any successful project is good communication.

Building my first progressive web app

Over the Christmas holidays I came across some articles about Progressive Web Apps (PWAs) and then a couple months later, l had a brand new site. I wasn’t planning on building one at the time but the articles had such an effect on me that I felt compelled to get to work. I learned that a PWA is a websites that has the same capabilities like a mobile native app with things like push notifications and device hardware access. It reminded me of an idea I had heard about making sites that weren’t sites but apps and made me wonder what that might like look on my own site. Then, one thing lead to another and I was sketching ideas for a new personal site.

From a programming perspective, I decided to go with React so I could practice my coding skills and also because I really enjoyed working with it in the past. This was one of the most ambitious coding projects that I had ever conceived for myself so I thought I’d also leverage a framework to do some of the heavy lifting for me. After doing my research, a couple promising options presented themselves and decided to move forward with React PWA — a boilerplate for creating PWAs with React. It offered a number of prepackaged features like offline support, code splitting, server side rendering, and React Router which would all let me get right to work.

First signs of trouble

At first, things were going really well and I felt like I was making great progress building out my local version but then things get really hairy when I was done and went to deploy it to my hosting provider. Since this was the first React App I had ever built from scratch, I wasn’t aware of any of the hosting requirements for it to work. At that time, I thought React was a JavaScript language and that it would work on any old web host but I very quickly found out I was wrong. Even though I had it setup to run locally, I wasn’t aware you needed Node.js server to run your application and so I had to find a host that could support that. Thankfully I found Netlify which offers some really amazing services like free hosting for personal sites, free HTTPs certificates, and my favourite, continuous deployments with GitHub.

With the host figured out, I was ready to deploy the first version of my site and start the celebrations but then I ran into another issue. Something was configured different on my local machine compared to my host — React PWA boilerplate didn’t like and so all I got were errors. I banged my head against the wall trying to figure it out until I finally gave in and hired someone on Fiverr to figure it out. The process was super simple and within a day of posting my job request, I had my issue resolved and my site running only to find out that I had another problem with how something was rendering thanks to the framework I was using. At this point, I had put in a significant amount of my free time into trying to figure out the hosting issue and so running into this took the wind right out of my sails. I decided to put things on pause for a bit and hoped that maybe something would come to me in the future.

Try and try again

A couple days passed and I was still feeling a little deflated from things not working out but was determined to move forward so I picked a new framework and tried again. I had been reading about Gatsby and thought that, that would serve my needs just fine. Having learned my lesson from before, the first thing I did was deploy a copy of Gatsby up to my hosting environment to see if it worked. With things looking good, I proceeded to take pieces of code, from my old code base, and transfer them over to my new site while continually deploying to my server. I started with the easy stuff and was excited to be making progress again but then ran into another problem when I tried to connect my WordPress blog to it. I kept getting one of those weird developer errors that didn’t make any sense and was dead in the water for a second time. I remember being disappointed and once again thought that some time away would hopefully reveal a path forward.

Third time’s a charm

After about a week, I had pretty much given up on making Gatsby work but felt compelled to get this project out the door because I was really proud of what I had created and wanted people to see it. This time I said forget the frameworks and started with a blank slate. Even though I was starting from scratch I had a working version that I had built locally with React PWA so I copied it over piece by piece and deployed it continuously to make sure everything was ok. Slow and steady, I finally got it all up and running on Netlify and connected my domain to it. I must have visited it a million times in the first week marvelling at what I had accomplished, noticing every little detail that I needed to fix, and shipped updates immediately.

Onwards and upwards

While I was busy building, and then fixing, my site I spent very little time writing. All that work really made me appreciate the WordPress theme I used before because it meant I spent zero time working on making it work and all my time writing. That being said, I have thoroughly enjoyed working on this site and continue to dabble on it as a test bed for trying new things like working with CSS Grid, animations, and service workers. I have made a bunch of updates since I launching the site but still have so much I want to do with it because my full vision has not been realized yet — little by little, I’ll get there!

Breaking the silver bullet fallacy

Wikipedia defines a silver bullet as “a metaphor for a simple, seemingly magical, solution to a difficult problem”. Working in product development, I have come across my share of silver bullets and every time they end in the same way. First with disappointment and then the additional hard work you need to do to get the results you need. I recently had a silver bullet moment at work, which I think I finally learned my lesson from, and thought I’d document it for posterity sake and maybe also so that I might not fall for the same trap again.

Earlier this year we implement a new onboarding flow for WordPress.com that was supposed to be a game changer for us. We had several pieces in there, that as a combination, we believed would unlock the key to our customers hearts. Leading up to the launch, we conducted a number of tests which had positive outcomes and showed us we were heading in the right direction. In the end, we ran a big A/B test to compare our new design against the old one so we could measured the impact of our design based on some key metrics.

Once the data started coming in, we knew right away that our silver bullet didn’t quite hit the mark. The numbers came in flat and only showed marginal improvements over our old design. Despite the news, we still had hope because we learned a lot and we knew there was still so much more we could do. We pushed forward by running more tests, speaking to more customers, and iterating on our designs. Over time, our results began to improve and so did our morale. Looking back at it all, it reminds me of something John Maeda, our Head of Design, keeps telling us around the office — “when you cook pancakes, the first ones always get burnt!”. It’s only after a couple that you figure things out and start making good ones.

The big take away for me from this experience is that there are no silver bullets. There might be flukes but most times results are achieved with a good plan, hard work, and commitment. Next time I’ll think twice when we think “we have it” so I can better set expectations not only for others but also for myself. Do you have any silver bullet stories to share? I’d love to hear them.

Ethnography is inspiration

A couple of years ago I attended a really fun conference in Whistler, BC about the impact of technology on business and culture. One of the talks really resonated with me and is still pretty fresh in my mind even though I forget who delivered it. The speaker shared how people use ethnographic research to learn, validate, and test but what he figured out was that it could also be used to find inspiration too.

He kept repeating the phrase “ethnography is inspiration” throughout his talk, and that’s probably why I still remember it today, but then he went on to describe some examples of how he came up with new ideas while talking to customers and conducting user studies. I have since experienced this for myself a couple times, which is maybe another reason why I remember the talk, and wanted to share one of my most recent moments of inspiration.

People use ethnographic research to learn, validate, and test but it could also be used to find inspiration too.

I was in the process of doing what’s called a ”support rotation” for my job at Automattic. It’s something we do every year where we take a week to join our support organization to connect with our customers by email, live chat, video, and even in person. A couple days into my rotation, I joined a video call and had one of those very special moments. We were talking with one of our customers as she walked us through some of the challenges she was running into with our newly launched editor called Gutenberg.

Seeing her walk through our support documentation, and then working in the product, sparked something that got me thinking about different ways of approaching a problem our team has been wrestling with. I immediately jotted down some notes, sketched up some diagrams, and shared my thoughts. It also brought up some interesting questions that I don’t think anyone is thinking about on our end.

The inspiration didn’t end there though, through my rotation I also got to observe the way my Happiness colleagues work. Some of it was first hand by using the tools and resources they use. Some of it was through conversations I had with them before and after some of our calls. These encounters lead me to identify a handful of process and documentation improvements that would have never otherwise been brought up.

Looking back, I feel really lucky that I had the opportunity to participate in this support rotation. For one, it was a nice break from the everyday hustle and bustle but more importantly it felt really good connecting with our customers, learning more about our product, and being inspired though the practice of observing other people work.

From zero to one

After its first year in business, the Shopify Plus team learned a lot about their customers and who they were. It was clear their website didn’t accurately represent them anymore and so they decided it was time for a redesign. I was picked to lead the project and saw it from concept through to delivery — even coding parts of it.

We collected both qualitative and quantitative data to measure the effectiveness of the new design after it launched. It was successful not only based on how our customers perceived us but also by the number, and quality, of leads we were collecting. When it was all said and done, I wrote an article for Invision’s blog and shared the following design tools and process I used for the redesign:

Project brief

The very first thing I did when I started this project was to write up a project brief so I could keep everyone on the same page. I made sure to update it as we went along so that it always reflected the latest state of the project. It served as a great tool to communicate the goals of the project and onboard new team members onto the project.

These were some questions I included:

  • What are we trying to achieve?
  • How will we know the project is a success?
  • What do we need to do?
  • Why do we need to do it?
  • What are the must-haves?
  • Who are we doing this for?
  • How will they know about it?
  • Who’s on the project team?
  • What’s our deadline?

Stakeholder interviews

At the very beginning of the project, I kicked things off by running 1-on-1 interviews with members of our executive team and some of our top customers to learn from them what Shopify Plus is all about. I recorded each interview so I could pay full attention and took notes later when I listened the recordings over again. The notes allowed me to capture the key points which highlighted patterns and themes which we used to guide the direction of the new design.

I remember how inspired I felt after my first round of executive interviews — it was like I knew everything there was to know about the product. After that, writing vision and mission statements, brand guidelines, project briefs, and the websites copy came easy. As we progressed through the project, we would continue to check in with different customers and test the design to make improvements.

Competitive analysis

Early in the project, I reviewed the the competitive landscape to see how other people were speaking to our customers. I started with a list of direct competitors, then moved on to businesses that serve our target audience outside the ecommerce field.

The analysis highlighted common patterns appearing on multiple sites which echoed what our customers were looking for in our interviews with them. One of the common patterns we noticed was how busy, and confusing, a lot of these enterprise sites were. We honed in on that fact and used clarity and simplicity as a key principle to set ourselves apart.

Information architecture

Early in my web design career, I learned to draw information architecture (IA) diagrams as a way to document an existing system or express a new one. Early in the process, I drew a diagram of our old site that showed the hierarchy and relationships of screens.

Through that process, I evaluated the content and the traffic to the screens to find lots of orphans or deeply linked pages. I used the information I gathered to create a new IA and suggested changes. The diagram was a great tool that helped us have important discussions around defining the scope of our project releases and acted like a checklist as we wrote, designed, and coded all the pages.

information-architecture
Our information architecture diagram

Wireframes

I used wireframes throughout the redesign to help think through problems, and get approval for ideas. Some were sketched on napkins and shared face-to-face, and others were drafted and shared online.

An unexpected bonus for me was discovering how much easier it was to write copy directly in the wireframe rather than in a document. Seeing the copy visually was helpful for me to create a through line for each screen and across the pages for a nice coherent narrative.

wireframes (1)
High-fidelity wireframe used for the redesign

Inspiration boards

My inspiration boards allowed me to share my vision of what our new brand might look like and helped me get early buy in from the team.

I developed my concepts in Adobe Illustrator by combining words, images, and colour swatches into something that looked like an ad. The same elements appeared in all the boards I created, but their placement and appearance changed from board to board.

mood-board
The final inspiration board we picked for the site
other-mood-boards
Some of the other inspiration boards we created to explore alternative directions.

Prototypes

Back in my consulting days, I found people didn’t quite pay attention to wireframes or web designs if they were printed on paper. Showing them a design on a screen was better but the thing I have found that worked the best, to captured people’s attention, was sharing something interactive.

I started developing interactive mockups early in the wireframing process. We shared them with our customers and the team throughout the project until most of the site was coded. We had people speak out their thoughts as they browsed through the prototype. Their feedback highlighted problem areas and validated design choices which helped us shape the end result into something successful for both us and our customers.

invision-mock
InVision project page for Shopify Plus

End result

Remember email?

Earlier this year, I was one of the many designers at our company that participated in a an in-depth study about small business owners to determine how we might build our products to serve them better. We kicked things off with a segmentation study that helped us break down and prioritize the vast landscape of small businesses into more discernible groups. This was followed by an intense qualitative study where we spoke with a number of small business owners from across the United States. Our team wrapped things up by meeting in San Diego to comb through the data we collected and synthesized it into actionable insights for the company.

Looking back at the findings, I am grateful for the opportunity of taking part in a study like this because it reminded me, among other things, that we are not the people we design for. A lot of tech folks I know, myself included, have an aversion to email and as a result feel really annoyed when they get emails from companies. The business owners we spoke to on the other hand felt very differently — they love email!

On the go, or in the office, they check their mail a million times a day and use it stay connected with their clients. They also use it to learn new skills, stay up to date with industry news, and keep in the know about networking events and conferences. Hearing business owners talk about email that way really stuck with me really left an impression on me and changed the way I think about it. It is a tried and tested communication tool that still holds value for lots of people out there and should therefore be considered as an integral part of any complete experience.

Starting with curiosity

Before getting into my design career almost 15 years ago, I was an art student for an even longer time. At school, I learned how to use my curiosity to produce creative work. We were taught how to explore the unknown, try things that hadn’t been done before, and seek out different approaches. Those skills carried over well for me when I entered the design world and worked for various agencies producing websites, digital products, and print pieces for their clients. Our first step was always to gather information about our clients and their needs. Then it was up to me, and my colleagues, to explore different ways of delivering quality work that represented them well.

A couple years passed before I started working at product companies, then a couple more years passed, until today, where things are very different thanks to Steve Jobs. He showed us how thinking different could change the world and having a deep understanding of your customers can lead to innovative products. I’m seeing that impact right at the company I work Automattic as we undergo a transformative process into becoming a design led company.

A couple of months ago, I participated in a foundational research study in which our goal was to better understand one of our target customers: the small business owner. We conducted a ton of interviews with people from all walks of life and visited them in their homes and offices via video chat. Throughout the interviews we recorded our sessions, took notes, and added our takeaways as stickies onto a digital Mural board.

The amount of data we collected was intimidating at first but then we found different ways of synthesizing it into actionable insights. We’re just getting back into a regular groove of producing new work and thanks to being inquisitive and doing our research, I can already tell the difference in the type of work we’re coming up with. The future for WordPress.com looks very bright.