I work as a solo designer with a startup called HyperTrack. Everyone in the team contributes to the end product, which makes the product experience as a function of everyone in your team, and not just designers.

A good user experience is a reflection of good internal team processes

We made small changes to the way we worked and introduced new processes that would help us to design better and ship faster. These systems differ from team to team, but here is a breakdown of how we approached different aspects.

1. Interface

Our UI was not all over the place. Different buttons, different form fields, unlimited number of greys and blacks, different ways of showing loading and so on …

What we did

  • To solve this, we created a shared Sketch Library of our symbols
  • Created similar components in React, Android and iOS
  • Created spacing symbols in Sketch, and spacing variables in code. This helps eliminate the spaghetti of hard coded spacing values that spring up in the code
  • Created a set of common micro interactions that can be used in different places. Hover states for buttons, transition states between pages, animations for popups, loaders etc were all kept in one place in the code

2. Internal team vocabulary

Different parts of products used different words for the same feature or concept. That makes it harder for the user to understand the product. While figuring out the solution, we learnt that the core of the problem lied with us using different vocabulary in our internal team communication. What we speak is what we end up using in copy, code, docs, email etc. So we decided to standardise the vocabulary we use internally

What we did

  • Made a glossary of commonly used terms, their definitions and when to use them
  • Made a list of wrong words being used by the team and the right versions for them.
  • On our internal docs and tools, like issues, PRD documents, documentation, meeting minutes etc we would also use the same vocabulary. This requires you constantly pointing out whenever people use a different language or word.

3. Copy

For the user the entire product is like a single interface, and our copy is a way in which our product speaks to the user. The voice, tone and the grammar used hence should be similar across the product. As the product grows - copy starts showing up in multiple places - signup, onboarding, empty states, error messages, loading and success messages etc. It also tends to be overlooked specially when it’s a microcopy. Some developer would just add this microcopy without thinking of the tone or if it’s consistent with the other messages. Here is what we did to make it more consistent …

What we did

  • Took all copy and added it to a single place - GitHub repo in our case, we being a developer heavy team.
  • Reviewed all copy to make it use the same vocabulary, consistent in it’s tone and making sure that all of them help the user.
  • Made this repo accessible to the entire team - everyone can now borrow from this repository or suggest a change
  • In code, moved all copy messages to a single JSON file. This makes the developer easily sync his file with the repository we made above, keeps the code cleaner and makes everyone conscious whenever we add a new copy.

If you are looking for something simpler - check out how Dropbox organizes their copy docs

4. User context

We speak to our customers on our Slack, Email, Intercom, WhatsApp, Telegram, Zoom, Skype, Phone calls etc. This made different feedback from customers getting lost in different mediums. It also makes it difficult for a team member to get the user’s context over a specific problem. We wanted to keep the user context easy to access and available to the entire team.

What we did

  • Put all feedback from various places in a single channel. Some were automated through integrations and Zapier. Others were just enforcing our team to be manually add them in the channel.
  • Since the channel was public and open to the entire team - others would add more context to a conversation if any was missed.
  • We sent all these conversations to a sheet in Airtable via Zapier. Here we add relevant tags to them and list out nuggets from them
  • Nuggets are observations gathered through this research. Everyone can have their own nuggets and there could be multiple nuggets for a single conversation.

5. User empathy

Bridging the gap between the user and the team is important in order to deliver a good product experience. So how do you make each person in the team think about the user and be aware of what the user wants :

What we did

  • From the previous point, we already had all customer conversations in one place - indexed and searchable. We shared this across the team
  • Made a tiny Slack plugin to query for user’s conversation from Airtable
  • Started referring to these tagged conversation in our internal docs - like design docs, product requirements, GitHub issues etc

6. Same definition of a feature

In different meetings, countless google docs and multiple slack messages - different team members develop different perception of what a feature is supposed to do. I am sure you would have used the term “on the same page”, “single point of truth” multiple times in different contexts. One of the key pillars of a good system is making information transparent. We thought that if everyone was looking at the same thing, half our problems would either way be solved.

What we did

  • We started creating a single document for each feature or product.
  • This document would include the product definitions, user research analysis, jobs to be done, designs, interactions and concepts. All discussions/updates would happen on this document. Hence it becomes a single place for anyone in the team to get visibility over what’s happening
  • Tools are unavoidable, and no single tool can solve all of our needs. The document would also act as a table of contents of links to other tools like Zeplin, Framer, Principle, Dropbox files, Overflow etc

7. Collaboration

Very often you would find that the end product turns out very different from what the designer had imagined. Some where in the development process, the context of designs get lost between product managers, designers and devs.

When it comes to people working together, what worked for others might not work for you, and what worked for us, might not work for your team. The trick is to sit down together as a team and figure out a solution.

Learnings

  • UI Library in Pt 1 helps
  • Copy organisation in pt 3
  • Design doc in Pt 6
  • We sat down together to figure out the issues faced by everyone in the team and what we can do to mitigate them. Was much easier than it seems, and most of the processes that I have written about above - came from such discussions.
  • Weekly UI review sessions. Some UI fixes are so small, that they never make it to the task list. We decided to dedicate a few hours every week for such fixes. Designers and developers would sit down together and make these rapid fixes

I like to look at all of this together as a Design System. For me, a DS is not just a collection of components but rather a way in which your team works. Like any other system, it’s always a work in progress and it’s never right. The important part which I learnt is to not be lazy and to solve these issues by just going and talking to the team member