Design systems are no longer optional, your organization needs one
Design systems have been a huge part of the conversation around design for the past few years. There have been many attempts to create a design systems that are open source. Some examples include Material Design by Google, the Atlassian design system, and Ionic from the Ionic team.
What is a design system?
To simplify, a design system is a collection of rules, guides, and principles implemented in design and code through components with the goal of building a multitude of applications with a consistent user experience. There are many parts of a Design system such as documentation, design toolkits, component libraries, best practices, UX patterns, and branding guidelines.
Some high profile companies have chosen to make their design systems public, others have gone a step further and made their component libraries open source and available for anyone to use. This is the case with Angular Material built on the Angular framework for the Material design system.
Reasons why you need a design system
Some of the most common challenges with teams when it comes to the frontend have to do with undocumented styles, too much custom CSS, and lack of consistency in the UI. From a developers perspective, many do not want to spend time writing CSS. They would prefer to work on implementing features and move on.
Like in most teams, without documentation most developers are unaware of what they already have at their disposal. Many will end up implementing custom CSS that might have already been written by someone else. A design system would help centralized documentation for CSS, reducing the amount of work developers need to do. Like with JavaScript, CSS also comes with cross-browser challenges. Centralizing documentation helps team solve the problem once and allow others to reuse their work and reduce the amount of custom CSS necessary. This will also help reduce the size of files users need to download on their devices to render the UI.
Inconsistency is a huge problem specially in more mature products. Without a set of centralize rules and guides implemented in the code base, many applications end up with inconsistent way to perform the same actions, such as filtering a list. Designers frequently will also create different designs for the same problem because they are unaware of pervious solutions. A documented set of UX patterns and best practices can help designers implement consistent UI solutions.
The primary benefit of a design system is scaleability. Design systems reduce inconsistency across one ore more products. They also reduce the amount of code written, freeing up developers to work on more exciting features that will add value to their users. From the end user’s perspective, they receive a consistent user experience across the different solutions the origination offers.
Reuse an existing or create your own
Resource are always limited regardless of the size of the organization you work in. Putting together a design system for your organization is no easy task. Many organizations choose to use an open source option. This mostly takes the form of a UI component library, one of the many pieces of a design system. In most cases this will work in the beginning. As the organization grows and more digital product offerings are introduced there will be draw backs. This is specially true for the UI in companies with multiple applications where different teams maintain them.
Implementing your own can also be resource consuming. Like any other product, a design system needs time to mature. If an organization does not have the resources, or is not willing to invest in it, an existing public design system may be a better option.
The advantage in creating your own is that it becomes exactly what your company needs. Keep in mind that systems like Atlassian’s design system were created to solve the problems of their organization and their users, not yours. While there may be overlap, you will quickly see where you may find yourself retrofitting their solutions to match your product needs. This is more evident with component libraries.
If you are starting your own design system consider where you see the biggest pain points and start there. In my experience, most organizations are spending too much time writing the same CSS, HTML and JavaScript over and over. For this reason it may make sense to start documenting existing CSS and introduce a component library since that’s where engineers will save effort when implementing features. It also helps centralized the UI because it makes it easier for redesigns in the future. Remember, a component library is simply the coded implementation of the rules and guidelines identify in the design system.
You also don’t have to be original with the documentation. Many of the existing design systems already have great documentation such as patterns that you can adopt in your system. Take what best fits for your product, team, and users.
On component libraries
When most organizations think of a design system, they think of a UI component library. UI components are a small part of the entire design system, but for many it makes sense to start here to reduce redundancies during development and testing.
Open source software is amazing because it makes developing applications much faster. It is also one of the leading problems regarding product inconsistencies in my opinion. Over the years I have seen organizations use a plethora of UI component libraries within the same product. Mostly introduced by developers when they needed to solve a problem quickly but their current library did not have a solution. Instead they found something on Stack Overflow and introduced it into the code base without thinking of the larger ecosystem of the product. Many times this is fine in the beginning, but this approach does not scale for large organizations.
The lack of a centralized design system has lead to the use of different open source solutions all within the same product. I have seen the same application using Telerik, multiple versions of jQuery UI, and good old Bootstrap. As you can image this becomes difficult to maintain and the differences in UI implementations between these libraries make the user experience inconsistent.
If you are thinking of building your own, consider the resources your team is willing to invest in it. The project may not take off if there is no buy in from the management team. Bellow are a few other items to consider around UI component libraries.
Writing your own
If you are considering building your own, you really have to have buying from key team members. It will take time for the components to mature and workout all the bugs. It’s wroth taking the time to do a cost-benefit analysis if you decide to go on this journey.
Future proof your UI components
Most mature products are likely to have different applications built with different stacks. If your organization’s UI across applications includes multiple frontend frameworks and UI component libraries, it may not make sense to write your library in Angular because they would not be compatible with older version such as AngularJS or other frameworks such as Vue. I would recommend that you look into StencilJS if that is the case in your organization. If you are lucky enough to have your applications in only one technology, ensure your team does not plan on changing or introducing new incompatible technologies before choosing how to build your toolkit.
Replacing an existing one
One of the most difficult aspects with existing applications is redesigning and replacing old UI components built on a different technology. Most resources tend to go to building new features. One approach is to update the components as each page is being redesign, but it will most like take years for a large complex application. Future proofing your components will help make them available for use in applications with an older stack. It does not solve the problem of replacing existing ones, but having them as on option is the first step I would recommend.
Multiple products
If your organization has multiple products consider building your UI components in a way that are agnostic to technology or frameworks. In other words, make sure you can write them once and use them everywhere. Building in such a way will increase the likelihood of other teams adopting the design system and still give engineers opportunity to use different technologies when necessary. It also makes designers happy because the UI will look pretty and consistent everywhere.
Refreshing the brand and redesigns
Regardless of whether you are building your own or reusing an existing UI component library, you should consider how easy it will be for your organization to keep your applications looking edgy and modern. Technology changes, and trends come and go. Keeping your products up to date with today’s visual trends is a good way to reintroduce life into products. As you explore what best fits for your organization, I would encourage you to consider this into your decision. It will also help with introducing features such as white labeling, themes, and dark mode for accessibility.
Happy employees are great but fulfilled ones are better
Happiness is a temporary emotional state that comes and goes. Perks make employees happy. Free catered lunches make employees happy, so does higher pay and unlimited vacation, until it does not.
Fulfillment comes from being part of something greater than ourselves. It comes from being part of a worthwhile cause, from being part of changing the world for the better. Fulfilled employees will stick around when things get tough because they believe in the cause. Everyone deep down inside seeks to be part of something bigger than themselves.
Happy employees are great but fulfilled ones are better. Happy and fulfilled teams change the world.
Design thinking in the product development process
Design thinking is a non-linear process that gives teams the tools to understand users’ needs, wants, and team assumptions to create solutions that can be prototyped, tested, and eventually materialized into a product.
The design thinking process has become popular with teams over the past few decades and has been highly adopted by companies like Google and Apple. In simple terms, it is a process to solve problems in a human-centric way by allowing teams to focus on what is most important for users.
Despite its popularity and effectiveness, it is hard for teams to shift traditional waterfall thinking about design and problem-solving. Particularly, teams have a hard time understanding how to use the process and where to include other members of the team.
In a waterfall approach, product managers spend time to understand the problem, the business case, use cases, and the solution. It is after those steps that designers are included in the process to materialize the idea into deliverables such as visual designs. While this process solves the problem, it is my experience that many times it leads to incomplete, difficult use solutions. It also misses the value the design process brings when used with a cross-functional team to create better solutions for users.
Working with product managers over the years I have come to understand that it is not that they don’t understand the process or that they don’t see the value, rather, it is the understanding of when to include team members in the six steps.
The rest of the article is my attempt to take the six steps and align them with the different skill sets of team members. While you can include the entire team in these steps, I understand that it is not feasible for many teams. Jake Knapp in his book Sprint, takes these steps and cramps them into a one week block. He makes a good case for why you should include a cross-functional team in all the steps, but the process is flexible enough to allow teams to benefit from it and adopt a version that best fits their team.
While reading through the different steps imagine your goal is to improve new users’ profile set up. Keep in mind that my examples are based on a team that works on a software product, but the principles still apply. The process is also not limited to products. It can be used to improve product support or services offered by a company.
Empathize
This phase is about developing knowledge of what users do, say, think and feel. This phase can be done primarily by the product team with consultation from designers, sales, support, marketing, and engineers. This is where teams would directly observe what users do and ask questions like what motivates or discourages them. Teams at this point are trying to identify the pain points in the current process users follow. It is important to document the findings to carry them over to later steps. Teams can document facts, assumptions, and opinions on sticky notes, a whiteboard, or anywhere else that these ideas can easily be seen by the team.
Define
With all the research data from the empathize step, teams can begin to identify opportunities in the process where they can innovate. At this point, the focus is not to come up with solutions. In our user profile setup example, think of what are the common pain points the team saw across different users. This step can be conducted with a broader team in the room and at the same time as the next step. Consider including designers, engineers, support, marketing, and sales if possible. Depending on the difficulty of the problem, designers and engineers may be enough. Teams can choose a set of skill sets that best fit their process. In my experience in this step and the next, the more representatives from other parts of the business are involved, the more wholistic the solution will be.
Ideate
Once teams understand the users’ needs and have identified areas to improve, teams can begin to explore solutions to solve the problem informed by the research. Ideas can come from anyone, not just designers or product managers. Anyone can wireframe an idea and share it with the team. The goal in this phase is not to scrutinize ideas on why they would or wouldn’t work quite yet. The goal is to come up with several feasible solutions that solve the problem. Once multiple ideas are in front, then the team can go through the process of identifying the pros and cons of each solution. A good result would be that in the end, one idea wins as a favorite of the team. This usually tends to be a mix of all the best parts of the ideas presented. In this step, you want to have everyone in a room. Include different members with different functions in the product development process as well as members of outside groups if it makes sense. Support can usually provide good feedback and whether an idea will help based on what they hear from customers during support calls.
If there is more then one good idea considered as a possible solution that is also fine. The next step is to build a testable prototype.
Prototype
Depending on what kind of product your team is working on, it will require different skill sets to build a testable prototype. In this article, we are focusing specifically on software products. The designer would be the primary member responsible for putting the testable prototype. The goal of this step is not to build a high fidelity prototype. It needs to be finished enough to communicate the intent to the user. It can be in the form of a Powerpoint presentation, an InVision wireframe. It needs to feel as real as possible without spending so much time on it that it cost too much to build. It has to be built with the idea in mind that it might be discarded because it was the wrong solution. This is a hard concept for teams because they may have invested so much time into it. That’s why it’s best to not build high fidelity code prototypes unless they are proof of concepts that eventually will become part of the implementation.
Test
The testing step is about putting your prototypes in front of users. In this step we are looking for the answer to the question ‘Does the solution meet the needs of users?’ Anyone can observe a usability test, but only one person should speak and moderate the interview. Everyone else should be in a separate room observing and taking notes. The goal is to test the solution, not make users feel like they are being tested or interrogated.
Implement
The final and the most satisfying part of the design process is the implementation. After all, this is the reason teams go through the process. To deliver solutions. In software development, this step is usually performed by engineers. It is an important step because teams want to make sure that all the research and effort that went into finding a solution is not missed or discarded. Introducing new concepts without going through the process again leads to hard to use products and more pain points.
Conclusion
In his book Sprint, author Jake Knapp provides a step-by-step process to cramp these steps into a one week block. Whether your team can do that or not, the goal is the same, to build products that are centered on the users’ needs and build them in a way that reduces the cost of doing so. The process is non-linear. Meaning that if at any point discoveries happen, the team can return to any of the previous steps and rethink the problem, assumptions, and the solution.
The thing about controlling the outcome is that it is not possible
It doesn’t matter how much we try, the outcome is the outcome despite of our intentions. We can’t convince the prospect to buy our product or service.
The only thing we can control is whether we did our best work at the time. Even if we followed everything by the book, the desired outcome is not guaranteed. Sometimes the book works, sometimes it does not.
All we can do today is do our work with excellence, and when it doesn’t turn out like we thought, try again.
All we can control is the input.
Nothing is for everyone, quit building your product that way
Not everyone buys iPhones, Teslas, or uses Gmail. It gets even more complicated when we build enterprise products that are used by different people for different purposes. While Gmail allows you to read, send, and respond to emails, it does not try to help you edit a spreadsheet. It has a separate product more appropriate for that use.
In product development, we invest a lot of time creating personas. Ignoring the needs of these personas and what they are looking to accomplish with your product can lead to building something that tries to be everything for everyone. It will probably lead to a very complicated feature or product.
If something is for everyone, then it is for no one.
The challenge is to identify when to break up the product or feature into multiple pieces. Anyone who has worked with personas before knows they have different needs. Knowing who is it for is a good place to start. Once we know the needs, we can ask ourselves if it is for them?
When the answer is no, we have found a way to simplify. When we find ourselves answering no more often than not, it might be time to break things up.
It starts with knowing who is it for and what they need.
Disney will not wipeout Netflix and Slack will be OK
Despite the popular belief by short-term investors, Disney will not drive Netflix out of business. Netflix is in the long tail business. Meaning they stream as much content as they can that is no longer popular in today’s week of entertainment, but it still loved. The long tail does not depend on Friends or The Office because most shows that make up the long tail are not producing the same revenue for studios as they were when they were new and fresh.
It cost Netflix an approximate $48 million to make Stranger Things. Disney spent over $300 million to make Avengers End Game. That means that Netflix can retry to find the next Stranger Things about 6 times. Even if they are successful only 50% of the time, that is 3 hit shows or movies. It’s way cheaper to play in the long tail than it is to dominate the blockbuster market.
Neither will Microsoft drive Slack out of business. 20 million users signed up, but it doesn’t mean their teams switched. The evaluation of a new team collaboration tool is not one week for the majority of teams. In the short term Slack’s stock may drop, and so will Netflix. It would be an underestimation of the impact by short-term investors to think it is the end for these companies. Netflix is the company that has innovated and ate its revenue several times by pivoting, not once, not twice, but thrice. From delivering DVDs in the mail to streaming online, to creating it’s on original content. Disney is playing catch up, not innovating.
That means they missed the next wave of innovation by a few years or what Clay Christensen calls, the innovator’s dilemma. They failed to eat their own lunch and missed the next innovation in television content. Although, they are big enough and have enough resources to catch up some.
Netflix is doing fine, they are playing the long-tail game.
Nick Fury knows how to assemble a team
“The idea was to bring together a group of remarkable people, see if they could become something more. See if they could work together when we needed them to fight the battles we never could” -Nick Fury
It starts with people who care, who want to make a difference, people who take the initiative to do the work. No one has to tell them to start the project, they start it and ask others to join.
Then, of those that care, they must possess remarkable potential. Here is a hint, if you care, you are full of potential.
The last ingredient is purpose. Once you care, once the potential is there, then you need purpose. Fury assembled the Avengers to save the world. He gave them an opportunity to channel their extra ordinary potential to do something much bigger than themselves.
They stepped up because they cared, and had potential. They stepped up when someone gave them a purpose beyond themselves.
Nick Fury knows how to assemble a team.
The constraint of quantity over quality in product development
Delivering a feature is not the same as delivering a quality feature. It may do what it is meant to, but most likely it is full of small details that make it hard to use, scale or understand.
The constraint between delivering features constantly because it adds business value “now” is one that teams constantly face. The challenge with delivering earlier by sacrificing quality is that it compounds. This is especially true if multiple teams are adding to the product simultaneously. If everyone sacrifices quality with the mantra “we will fix it later”, it probably won’t be fixed because the team didn’t see value in it in the first place. The business wants the next feature they can sell. Eventually, it adds up and probably will require redesigning the whole feature or product.
The same problem is true for engineering. The challenge with making short term solutions to deliver now is that many short term decisions hurt the long term. It may work for a start-up working on a minimum viable product (MVP), but MVPs don’t sacrifice quality, they sacrifice capability. Don’t hide your willingness to sacrifice quality behind the idea of an MVP. It’s not the same.
If you want to scale your product, you have to consider the long term over the short term benefits. What if you could have the feature 2 weeks later, but increase quality by 10%. What if you did that for every feature? Will 10% accumulate the same way over time?
I always tell co-workers that we are either making our product incrementally better or incrementally worst. It’s never a leap. One compromise is not so bad when you know you are sacrificing the quality for the capability in the short run knowing that the next step is to improve quality. When everyone is compromising quality to deliver early, it adds up.
Are you an engineer? Is your current implementation setting your team up to deliver quality later? Or does it just meet the requirements?
“Our users are old, they are not good with technology”
Said the Product Manager frustrated after hearing about all the support calls from customers with questions about how to use her product. “You haven’t spent time with them as I have” she insisted.
But is it true? Are they incapable of learning how to use a piece of software? Is it better to say that we are bad at empathizing with our users? Is it more probable that we are designing for ourselves rather than the people we are seeking to help? Could it be that we are not good designers, yet?
After all, I have seen many grandparents with smartphones using social media to post a lot of grandchild cuteness. Somehow they figured out how to use a smartphone, download an app, register an account, and post a photo.
It might be a fact that her users are older and less tech-savvy. The goal is to understand their challenges and design for them. It doesn’t matter how I use the app, it’s not for me.
No one buys an ugly car because it’s ugly
Maybe some people like ugly cars, but the rest of us like beautiful cars we can afford. We even like the ones we can’t.
Beautiful things are easier to sell than ugly ones. We maybe overlook aesthetics for performance, but all things being equal, most of us will choose the shiny object.
Of course, beauty is not enough on its own. A beautiful woman and a handsome man must deliver on their promise of being a good partner.
Beautiful apps sell better than ugly ones, but they still need to deliver on their value proposition. They still have to do what they said they would, but all things being equal, it feels good to use a beautifully designed piece of software.
Something to think about the next time developers poke fun at the designer because she makes pretty pictures. All in good fun of course. We all like beautiful things, except when they are not useful.