Practical Design Principles
As a design team at Lyst, we believe it’s really important to be self-critical & constantly be on the look-out for areas where we can improve. We do this in part by running design critiques & retrospectives but also by making sure we review each others work (much like a code review).
In addition to this we have recently started writing down design principles to help us stay on track and focus on areas where we want to improve.
There is a huge amount of writing on what makes good or bad design (and even how to best define ‘design’)… these design principles are not about any of that. Rather, these are some specific things we as a team want to pay more attention to and spend more time on. It’s our way to kind of ‘debug’ our design process and improve.
1. Design for the best experience on every device (as much as is sensible)
Responsive design is hard. It’s much harder than designing for specific devices separately.
Beacause of this, it’s often tempting to come up with designs that could, for example, perfectly solve the desktop experience but are a bit of a compromise on tablet or mobile.
Doing this kind of ‘compromising’ design is far easier than coming up with the ideal solution and so can be tempting for a number of reasons:
- It’s often faster to build ‘compromising’ designs as it tends to be less challenging.
- It’s definitely easier to design.
- It can feel like the ‘only way’ - like your hand is forced due to how technically challenging your mobile/desktop adaptation is.
We know that mobile & tablet (and everything in-between) is going to be the way people shop and consume our product in the future. Compromising on the design for some devices at the cost of the experience on other devices should be matter of last resort - the holy grail obviously being to offer users a perfect experience on any device.
Realistically though, you have to as a team and a designer decide how much time you want to devote to the experience on each device. Creating beautiful cross-device experiences is not without a cost. Sometimes it’s simply not efficient or profitable to make it perfect everywhere - it’s a matter of degrees and as team you have to decide what is a sensible compromise and what isn’t.
Beyond the obvious consider the following when designing responsively:
Will changing your approach give you better cross-device designs?
Consider things like designing Mobile First™ as a way to challenge your designs. There isn’t a silver bullet, some approaches will better suit certain problems.
If you are in the middle of a design & are struggling to find a good solution, open a new file and wireframe the perfect solution for mobile. Then open a new file and do the same for desktop or tablet completely disregarding what you did for mobile. This might help you find out what a good compromise is.
Are the design requirements ‘equal’ across different devices?
Not every feature will be equally important to all users on all devices. Consider which use-case/scenario your feature is most interesting for.
Analytics are your friend, especially when working on an existing bit of the product. They can help you decide which user stories to prioritise per device and pinpoint usability problems for different user scenarios.
Sometimes the user’s goals will also vary per device. For example: A mobile user may primarily want a way to add to a wish list in a single tap. A desktop user however may prefer to instead have more control & be able to specify a specific wish list per item.
You should always aim for feature parity across devices but you have to consider that the priorities and goals of a user may vary across different devices.
Don’t forget about ergonomics. Thumbs aren’t quite as pointy as a mouse - keep hit areas big & spacing between CTA’s sensible. Think about when you use your phone - are you always sitting at your desk carefully looking at the screen without anything distracting you? No? Exactly.
Are the user’s UI expectations the same on different devices?
With each browser, OS & device come it’s own slight differences in terms of visual language. Each user will respond better to different visual cues and UI behaviours.
An example of a particularly painful visual expectation is the much dreaded share icon. While a given share icon may make perfect sense to an iPhone user it could be meaningless to an Android or desktop user.
Are you sure you know what is technically (im)possible?
As our product matures technically & teams grow we can do a hell of a lot more then just stack or un-stack boxes when it comes to building responsively (on both native or web!).
Check with your friendly local developer before writing something off as not feasible.
Think about load times due to connectivity
An integral part of a user’s experience is how quickly something loads when they use it, especially on mobile where connections are can be much worse.
Consider lazy-loading certain elements of your UI that are non-essential. Think about loading states & really really get your head around progressive enhancement (on web).
Try throttling your connection when testing a feature in development - the real world is not the perfect office wifi. You can easily do this using the chrome developer tools on web & using the Network Link Conditioner on iOS.
2. Design to solve a goal not a ticket
Even with the best intentions from engineers, designers, stakeholders & even PMs, design tickets can sometimes end up reading like “Add button to page to show X”.
What that really means is that we’d like to “Look into showing the user X. We will measure success via metric Y”.
Your design should be about best fulfilling that goal - not about just adding a button.
While this is painfully obvious, it can be all too easy to get tunnel vision while in a team and execute too quickly instead of thinking about the actual problem you are trying to solve. It’s ok to sometimes need more time to come up with the right solution to a problem - if you always prioritise speed and are afraid of slowing your team down you will make hasty unfounded decisions and your design work will suffer.
Even if you embark on a design ticket with a solution in mind, force yourself to try some other routes before settling. Even if they are terrible, they’ll reinforce your original decision.
Once again, analytics are you friend.
3. Measure your designs on what is shipped
No matter how good your design solution is - your design is only as good as what the user actually ends up getting.
This means you should to follow the development progress of your team so you know what is being built and how it’s broken down.
Ask for your team to mention you on Github so you can see how things shape up and provide design feedback before things are merged. If that’s too full-on, try sitting down with the developer(s) you are working with and regularly touch base. It’s not about you signing things off and becoming a blocker. It’s about working together and not only sharing designs early but also sharing the build process.
Test actual features once they are shipped on different devices. Be an advocate for the quality of build; think of yourself as QA on things you’ve designed.
Doing this will mean that you will be able to be responsive to difficulties or changes that crop up as part of the building of features.
4. Don’t reinvent the wheel / keep it consistent
Don’t innovate for the sake of doing something different. The reason design patterns become established is because they work, they solve some problem.
More specifically: when designing consider existing patterns across the product first. Inventing a new UI pattern should be a matter of last resort. It should only be done when there is a true benefit to the user.
If you are in a bind, consider introducing variations or ‘options’ to an existing pattern. For example: a carousel could be configurable to show or not show pagination dots. A button can come in different sizes.
Also - don’t forget that the product is not just the bit (and platform) you are working on. Check with other teams if you hit a new design problem you are unsure about - Perhaps a different team already solved the problem you are working on?
5. Dirty & hacky is ok (sometimes)
As a designer your utmost concern is the quality & success of the product - not of the design. That means that sometimes delivering a quick & hacky design is actually doing the product a much greater service than delivering a very complete design a week later.
Ideally as a designer you weigh the benefit of spending more or less time at a design stage in terms of how much it will ultimately benefit your team’s goals. Always co-ordinate and talk to your team, you probably don’t have all the information to decide this on your own.
Another way to say this is that it’s perfectly ok for different designs to be of different quality - it should be tied to the potential impact of your designs for the product & business.
And finally, it’s can be all too tempting to deliver a quick A/B test and, when the test is a success, just move on to the next thing. If you took a shortcut up-front make sure to go back and clean-up much like you would with technical-debt. In other words…
6. Deal with design debt
Like any company or product our website and app is far from perfect. We have lots of weirdness in terms of UI and product decisions/features: we have Design-Debt™.
When you approach a new problem or design brief consider if you have an opportunity to consolidate things & clean-up other parts of the product as you do things.
Now obviously as a product team if, every time you were to do something, you were to always refactor you wouldn’t ever get anything done. The best thing to do is to design UI patterns abstractly enough that, in time, as the other older parts of the website are worked on they can adopt your design pattern.
For example: Let’s image you would use an accordion-style UI into show information to the user and there are 3 different accordion styles throughout the product which are all slightly different visually, all have different animations and responsive behaviours.
The right thing to do is come up with an accordion solution that fulfils the generic goals of all accordion usages on the site.
As the other parts of the product that use the old accordions are worked on by anyone, your new pattern can be adopted. It can be frustrating as it’s slower, but eventually, you will have one global accordion UI pattern.
This isn’t always the best approach but often is the way to go about bigger changes. If it’s something minor like a color or tap/hover state it can sometimes be fine to make all changes in one go.
The same goes for non pattern related issues. Sometimes bits of UI don’t make sense in terms of how they are designed or are simply bad experiences / are broken.
The only way our product will get better is if everyone slowly chips away at design debt when working on new features and making changes to the product – just like technical debt follow the Boy Scout Rule).
It’s been a couple of months since we first shared these with the design team at Lyst, and the reception has been really good. The designers and product teams have been identifying with different principles to different extents, which is interesting to see.
Our plan going forward is to iterate on these principles and make sure they stay relevant to us. Our team’s ultimate goal is to be able to deprecate some of these principles and find new areas to focus on and improve.
As always, we’d love to hear your feedback on twitter @MakingLyst.