Often, I’m working with clients who will say something along the lines of “well, Facebook does lists of users like this, we should just copy them.” They think that because a certain company is big and successful, they must have invested a lot of resources in determining the perfect layout or interaction for a specific challenge.
Sometimes this is true, but surprisingly often the opposite is the case. Many big companies are big because they’ve done one or two things extraordinarily well or profitably - often other parts of the company can be in complete disarray.
How can you be sure they invested a lot in this particular part of their product? What if they’re working on changing it right now? And even if it is a good solution for that particular app, are you certain that your users and their users have exactly the same goals, preferences, and perceptions at the point in time they come across this interaction?
Here are some other reasons the design might not be that good:
Are your users the same as the successful company’s? If you’re targeting highly educated professionals with specialised knowledge who use your product in a work setting, copying something designed for the widest possible international audience like Twitter may not be suitable.
How close should your users be to the users of the app you intend to imitate? Look for similarities between user ages, tech-savviness, whether or not they use similar apps, if they’re from the same countries or regions, and the tech they’re already used to.
Does the feature have the same business value relative to everything else in your app as it does in the big company’s product? If the feature you’re imitating is just an incidental or bells-and-whistle offering, but is the core value proposition in your app, think twice about copying directly.
You can find the best solution to your own design challenges by looking at broader UI patterns. What is the recommended best practice for the particular situation? Does it apply well to your issue? Can you modify it slightly to better fit your users’ demographics and goals?
You can also look for digital products that are more similar to the one you’re designing. This is where being aware of the tools you use in your day-to-day life and of what’s out there in general pays off. It may be that a small app released last year has a great solution to your exact challenge. Keep a mental note of every new interaction you see.
Of course, ultimately testing with real users will reveal if whatever solution you chose actually works.
I worked on a website redesign for a chain of coworking spaces with big ambitions. We were in a meeting deciding on the layout and information architecture of the site, and looking at WeWork’s website as an example.
My client wanted to copy exactly what WeWork was doing on their homepage and main hub pages - getting people to choose their location first. “If a 20 billion dollar company does it, it’s probably right” was his reasoning.
The fact is that WeWork changed their information architecture every 6 months or so, and likely still weren’t 100% sure of the path that increased conversions the most. Also, WeWork was targeting a different range of customers - companies of up to 1000 employees in a single location in some cases (and they had over 200 offices).
My client currently had two offices with a total combined capacity of about 600 people. It was clear that we needed to create a path that was different.
I worked on a significant redesign of an HR collaboration tool. Together with the founder I was reworking a feature that allowed users to post events internally within their organisations. The original design had several fields for inputting time and date which I noticed were slowing users down - too many clicks were needed to enter a time range.
I worked on a significant redesign of an HR collaboration tool (OfficeAccord). Together with the founder I was reworking a feature that allowed users to post events internally within their organisations. The original design had several fields for inputting time and date which I noticed were slowing users down - too many clicks were needed to enter a time range.
I suggested we look at the way Facebook lets users add events. Instead of making users always fill in an end date and time, they simply add the option of adding an end time. This progressive disclosure saves time while still giving those users who want to add an end time to their event that option:
We thought about the type of events our users would likely want to set up - typically after-work events like parties and talks. Usually these events didn’t have a fixed end time - they just tailed off until the last group left. We determined it wasn’t critical to always have the option of adding an end-time and slowing users down when creating events (potentially causing them to give up adding their event), and ended up imitating Facebook’s implementation in this case.
The key point here is that we didn’t just copy Facebook directly - we thought about the use case, what kinds of events users posted, and used that as a basis. Copying is perfectly fine - if you can properly justify it!