The chronicles of an agency creative turned product designer.
I’ve been in the design industry over 9 years now — 8 of those being purely in agencies — with my transition to the product design arena being very much a leap of faith. Your agency “catch-all design” and product design are very different disciplines. I thought I’d share some of the differences that stood out to me, as perhaps they will be useful to anyone else considering this leap. Or at least spark conversations around them. Onwards!
• • •
10 years ago, if you came to me and said “James, this university education has really paid off. I’m going to work as a designer for a take-away delivery company!” I’d have looked at you a bit funny. (Hi, Deliveroo 🍕)
When I started out, fresh out the university oven, the job title ‘product designer’ was given to those who designed chairs for contortionists, or giant lemon squeezers that looked like space ships. As a designer you got a job at a design agency and that was that. Facebook had only just been released to the world, when you no longer required a university email address to sign-up.
The thought of working for the likes of Facebook at the time brought with it images of being hunched over a computer in a window-less room with a pool of vitamin D forming under my chair. Now it’s where designers aspire to be. Either there or Google. Or Instagram. Or Spotify. Or Deliveroo. Or any other company that offer up Product Designer roles for that matter — and people are now excited to work at these places for good reason. They tend to be focussed, disciplined and most importantly, pleasant places to be, but more on that later.
If your career as a designer has been anything like mine, it’s been varied to say the least. Working in design can be as euphorically rewarding as it can be emotionally draining. Amplify those extremes even further if you’re in an agency.
To be clear, this isn’t an agency-bashing post, there’s a lot going for them. If you want out, there are a lot of good things that you have to consciously decide you don’t want any more. The breadth of design work, the camaraderie, the work hard play hard attitude, the ferocious pace (which has its own pros and cons of course), and there’s no denying the addictive energy.
I guess it was around the 7-year mark (maybe the “7-year itch” applies to careers, too?) when I first decided I wanted to try something different. Product design in the digital world was now a well-respected thing, and even though stories about Google offices having beds and giant slides weren’t realistically achievable for me to experience, they added to that itch. I was fortunate enough to work on some fairly big projects at my previous agency, allowing me to taste those flavoursome acronyms of IA, UX and UI. It was a taste that I couldn’t get rid of.
So fast forward to the summer of 2017. In a single weekend I said goodbye to a role I knew inside-out, celebrated my son’s first birthday, and began a new job with a title I’ve never had before, working remotely. Gulp.
Spoiler alert — turns out it was the best decision I could have made — and I figure a year is a nice point in time to have a bit of a retrospective on the whole thing.
What’s the difference?
Process
There’s a massive difference between how agencies and in-house product teams operate. Put simply, agencies answer to clients, and products answer to customers. The challenging relationships the vast majority of agencies have with clients makes it incredibly difficult to be proud of the finished article. Creative juices become so diluted that you question whether you even put any Ribena in there in the first place.
I’ve witnessed countless times projects go back and forth to clients and mutate into an unrecognisable monster, so that in the end you can’t wait to see the back of, which is a real shame. But, ultimately, the clients are the ones paying the bill, and particularly if it’s a big bill you often have to sacrifice your creative vision to get that cash in the bank.
Paid-for products, in particular SaaS products like GatherContent, have an entirely different approach. The obvious difference is that there are no clients. There are no rounds of amends or the need to manage client expectations. The caveat here is that products don’t get the luxury of making rounds of amends — you keep failing and you’ll lose customers, it’s as simple as that. Therefore, before releasing a new feature or even a tiny update, there’s a lot of work that goes on behind the scenes, more-or-less involving:
Review business needs
Research customer feedback trends
Research the market
Prototype
Test prototype
Iterate
Visual design
Test
Build
Test
Release
In agencies, it’s the kind of process that gets sold to new clients in a pitch, but rarely happens. In most cases it’s because the client doesn’t deem research, prototyping and testing valuable, and so cuts them to reduce the budget. What you’re often left with is:
Visual design
Build
Release
A far simpler process, granted, but one that rarely hits KPIs. The end result is something that’s built on assumption. You should never assume. It makes an ass out of you. Just you. And don’t even get me started with content.
Products must focus on quality, above everything else. Imagine if Facebook’s Like button didn’t work after an update? The world would implode. Releases regularly get delayed because they’re not quite ready. It’s the reason why you never get solid release dates on roadmaps — by doing this you’d be just setting yourself up for failure, and a barrage of messages from frustrated customers. Monzo’s public roadmap demonstrates this nicely. Ultimately the lack of hard deadlines make for a far nicer environment to work in, and one that directs focus toward product quality.
On the flip side, agencies are all about speed (gotta bill them clients, yo!). I’ve spent the same amount of time working on a settings menu for GatherContent than I have working on an entire website design for my previous agency. Was I proud of the website I designed? No. Was I proud of the menu I designed? Yes. Because I knew it was correct and meaningful — confident that it solved real problems. It wasn’t just something designed to go in my portfolio.
Product/In-house = quality.
Agencies = speed.
Yes, that speed trait is pretty valuable, but 9 times out of 10 you just can’t have both. It’s a case of looking at the iron triangle and picking sides, and given the choice I’d always side with quality. Quality paves the way for memorable experiences.
Details
Time was a luxury that took the longest for me to adjust to. From working into the early hours designing a website for a pitch (😑), I’ve now got all the time in the world to really dive into the details. It took me a while to learn to take a step back. To not go in so gung-ho with each project. To research, draw, prototype, test. Not always in that order, and not always all those steps, but it was these bits that filled the time, and made sure I ended up with a considered solution.
To give you a tangible example, a recent feature we’ve been working on is search. Yeah, search. Everyone knows what search is. We’ve all used search before, and we’ve all got that magnifying glass icon seared into our brains — so you just whack in a search icon, maybe even include a text box, and be done with it, no?
No.
This is where states come into play. Scott Hurff talks about states in far more detail than I’m about to, but ultimately states consist of every conceivable possibility a user might encounter when interacting with your app/website/thing. Scott calls these a UI stack, and it consists of; blank state, loading state, partial state, error state and ideal state (your money shot).Even before any of that — it’s the planning stage. We need to figure out how we want search to function, before we get close to designing anything.
The user flow of using our search component
This shows our desired user flow. The user clicks on the search icon/text box and are shown recently viewed items/files. They then type a search string and the recently viewed list turns into actual search results — each with their own target when clicked. If the user deletes the text they’ve entered, they see recently viewed files again. Easy.
So we know how we want search to work. Let’s quickly sketch out what we want it to look like. Let’s not get ahead of ourselves. We aren’t reinventing the lemon squeezer. Besides — we want users to instantly know how to use it so it needs to use familiar design patterns. It doesn’t belong in MoMa.
Not the neatest, but it doesn’t matter
Isn’t that beautiful? We’ve got an active search showing categorised results — “content” and “assets”. Content results show how many instances of the search term were found, and which item those terms are found in. There’s also some useful meta data below each result. Matching results under assets would display a thumbnail of that asset, along with its name. Just out of crop are some other sketches I did of a full-screen search experience. This is the best place to test out ideas like that — you very quickly get a good feel for how a feature will work just by drawing.At this stage we’re pretty confident this approach will work. It’s a small component of the app, so we decide not to spend any time working up a complicated Axure prototype. Design times!
That infamous search icon just sitting there, chilling (and my pesky face)
Our search component features an expanding text box, so to prevent this part of the UI from jumping around all over the place, we’ve made search the left-most menu item.Below are designs of the partial, error and ideal states.
Partial state, before the user types anything
An error state, when there are no results
The final, ideal state of search results
So as you can see there’s a ton of detail we can go into for the simplest of functionality. And as I’ve said before, we need to go into this amount of detail to make sure that it not only works, but effectively responds to our customer and business needs—in this case increasing engagement and NPS, and customer retainment.
Search is an issue we’ve had validated for months via customer feedback, so the solution had to be right. Without search, users were wasting time opening each project and reading content to find what they were looking for. Now, with this work, we’ve made their lives a lot easier and ultimately they’re now getting much more value from the product.
More on details
If you’re not obsessing about the details, you’re doing it wrong. Dan Saffer says it best in his book on Microinteractions:
Details demonstrate that some care, some thought, some attention has been paid. And this is ultimately what we all want to feel: that some attention has been paid to us and our needs… Think small, and change the world.
If you’re serious about designing meaningfully, go do some reading on microinteractions. If a dedicated book is too much to take in right now, here are some more digestible Medium articles:
A fine example of a microinteraction is in Dropbox Paper. Paper automatically saves as you type, but they recognised that people will instinctively hit CMD/CTRL + S, like, all the time if you’re anything like me. Every time the user hits save, a useful message appears informing them of their auto-save feature, with an ASCII emoji that keeps changing. Brilliant.
Example of a microinteraction in Dropbox Paper
Iteration
In design agencies a lot of projects expire. You complete a project and hand it back over to the client for them to worry about.It’s not the same when working on a product in-house. You’re dealing with an ever-evolving living thing that requires your undying attention. You give it so much that eventually you identify room for improvement, and that’s fine. We have an insanely easy ability to change our minds, to test, learn, tweak and repeat. Occasionally you make an update and it doesn’t quite work out, but that’s not a problem — “fail fast” as they say.
The market is constantly changing, which means so too are our customers’ needs and expectations. If we were to stand still our customers would leave us in their dust. From a design perspective, they have no emotional attachment to our product, so neither should we.Here’s another real-life example. With GatherContent being a Content Operations Platform, the core part of the UI is our content editor, and features a sticky status bar that sits at the bottom of the browser, sharing useful info, unobtrusively, to the user. Too unobtrusively it turns out, because we started getting customer feedback saying that it was easily missed.Here’s how it used to look:
Previous status bar design
At first glance, and without a comparison, there’s not much wrong with this design, it contains the information without anything spilling out. There’s a keyboard shortcut button on the left, followed by the word count of the item. It’s 30px high — adequate for a status bar.Let’s look at the updated one:
The current status bar design (with added text formatting indicator)
Look at the breathing space! This one is 40px, a mere 10px increase in height but in comparison it’s a whole third bigger. This allowed us to push the font size to 14px instead of 13px, and have equal horizontal and vertical padding. All of these changes combined make for a more pleasant viewing experience (even with the added formatting indicator), and what’s more, this bigger size now makes it feel more part of the UI rather than an after-thought.An important take-away from this would be that, just because customers negatively fed back on the original design, it didn’t mean we had to reinvent the wheel. We simply iterated, and no doubt we’ll iterate on it again in the future. Such is product progression.
Design systems
In agencies I created my fair share of brand guidelines. The anatomy of a brand, documenting every decision ever made verging on OCD; the do’s and don’ts of the logo, where to put the logo, where not to put the logo, what temperature to wash the logo, not to mix the logo with dark colours… you get the idea.
If you’re lucky you’ll get a couple of pages giving examples of “brand usage” — how a presentation might look, or how a website might look. If a third-party agency or designer picked up some design work, there’s a distinct lack of direction when it comes to creating digital assets.
Design systems aid design thinking at a granular level, so you can spend more time providing solutions to problems rather than spending time drawing rectangles, adding rounded corners, adding shadows, and so forth.
They are very quickly gaining traction in the modern designers toolkit — particularly in product design where repeating UI components is the way of life. They are no longer a mass of button styles that you cobble together at the end of a project to share with the world and say “Hey everyone, come and see how good I look!” — Ron Burgundy.
Design giants Sketch, InVision and now Framer are getting on the design system bandwagon by implementing them directly in their arsenal, allowing you to reuse design elements in the form of “symbols” or “components”, depending on your weapon of choice.
Tired of recreating the same button style over and over again? Use a design system. Know for a fact you’ve already got a dropdown menu designed but can’t find it anywhere? Use a design system. Other designers in your team keep changing padding values? Use a design system.
Yep, they’re time consuming beasts to create. It’s the primary reason why agencies don’t allocate resource to build them (again think of a typical project’s lifecycle), but in order to maintain efficiency and accuracy in large-scale design projects, design systems are a no-brainer.
I believe a lot of pressure is being put on agencies over this very subject. Companies are now wise to the fact that customers want experiences, and how their websites look is no longer the top priority. Try to think of a marketing website that doesn’t have some sort of social media campaign tied to it. These long-term campaigns add to the longevity of websites — so the argument for design systems is ever-growing.
A snippet of our design system
Design systems are very much organic. Unlike brand guidelines that are rarely touched once completed, they grow in tandem with the growth of a product. Ours is a relatively young system, but over time will mature into a well-mannered being that you’d be proud to introduce to your grandparents.To get started in the world of design systems, here are a few tips you might find helpful:
Name effectively. If you use Sketch you’ll learn very quickly that the way you name symbols is an art form. Always allow some flexibility with your naming rules. For example, for a search icon, don’t be tempted to name it “search/icon” — instead use “icon/search” — that way should another component of your design require a search icon, it still cognitively makes sense, without having a design system featuring multiples of the same icon. Try to keep as close to the top of your UI hierarchy as possible.
Create as you go. It’s an easy mistake to make, we made it. Retrospectively creating a design system is a tedious task, not only in creating the system itself, but then replacing all of the UI elements with those from the said system. You don’t need to have a final button style before it goes into your design system — that’s the beauty of them. If you decide to change the way your button looks, you just need to change it once.
Learn your tools. This seems obvious, but every software has its quirks. For example in Sketch (at time of writing) symbols must have the same dimensions in order for them to be hot-swappable, maintaining any applied overrides.
Don’t limit yourself too much. If nothing in your design system feels right in that new bit of UI, then it probably isn’t. It can be tempting to force elements from design system into areas that just don’t work, so if a new feature is calling out for a new component, add it.
A final thought on design + code
I’ve always questioned the seemingly required relationship of design and code. A quick scan of product design openings reveals that the vast majority of them require some sort of development knowledge, usually along the lines of HTML, CSS and JS, branching out into React territory the higher up the food chain you go.
In contrast, a design role at an agency very rarely requires experience with code (though they do tend to go in the opposite direction, isolating designers from developers). Still, they recognise that they are indeed vastly different practices.
Yes, you’ll be well placed to understand about web languages, particularly their limitations, but you shouldn’t be expected to work with them. The best architects know how a building is put together, but they don’t have the ability to build it themselves.
In the last 12 months I’ve not been expected to touch a drop of code. I‘ve dipped my toes in water occasionally to help out during some busy periods (and even that was to just update some CSS), but on the whole, nada. When I applied to GatherContent it was considered a nice-to-have. I work with considerate developers who care about the details just as much as the designers, who can put up with us asking them “could you move that left by 1px please?” without batting an eye. It pays to have patience in all areas of a product team, as that patience will always translate into quality.
Don’t get me wrong there are lots of designers who design with code and kudos to you, but jumping straight into the browser to design has never sat right with me. Pencil and paper is still a solid foundation for solving design problems, and is my go-to starting point. I just hope companies continue to recognise this and not limit their pool of creative talent.
Let’s wrap this up
It’s been a very interesting year for me. I’ve learnt a staggering amount, not just with the hands-on designing of a product, but with the way a remote working product company operates. I’ve also been forced to more deeply understand our domain, and that of our customers. Gone are the days of mindlessly pushing pixels around until it looks nice without truly caring about a clients’ business or vision.
And don’t forget a year is nothing. I might have a few years design experience under my belt but as we’ve discussed this is a very different role, with plenty left for me to learn, and I hope to share more of these findings with you in the future.
To summarise:
No cutting corners. Product design is heavily reliant on process. If big chunks of process is missed, then the product suffers, and a poor product will ultimately struggle to maintain users. First impressions really count.
Pay close attention. Details matter. Search isn’t just a search box, it’s a magical gateway, transporting users to any part of a product in seconds. Treat the small stuff like it’s the big stuff.
Show you care. In product design it pays to finesse, to make users feel something. To not just look pretty, but have personality too.
Be one with the system. Invest time in creating and managing a design system. Don’t be tempted by pre-built system templates until you’ve mastered your own.
The chronicles of an agency creative turned product designer.
I’ve been in the design industry over 9 years now — 8 of those being purely in agencies — with my transition to the product design arena being very much a leap of faith. Your agency “catch-all design” and product design are very different disciplines. I thought I’d share some of the differences that stood out to me, as perhaps they will be useful to anyone else considering this leap. Or at least spark conversations around them. Onwards!
• • •
10 years ago, if you came to me and said “James, this university education has really paid off. I’m going to work as a designer for a take-away delivery company!” I’d have looked at you a bit funny. (Hi, Deliveroo 🍕)
When I started out, fresh out the university oven, the job title ‘product designer’ was given to those who designed chairs for contortionists, or giant lemon squeezers that looked like space ships. As a designer you got a job at a design agency and that was that. Facebook had only just been released to the world, when you no longer required a university email address to sign-up.
The thought of working for the likes of Facebook at the time brought with it images of being hunched over a computer in a window-less room with a pool of vitamin D forming under my chair. Now it’s where designers aspire to be. Either there or Google. Or Instagram. Or Spotify. Or Deliveroo. Or any other company that offer up Product Designer roles for that matter — and people are now excited to work at these places for good reason. They tend to be focussed, disciplined and most importantly, pleasant places to be, but more on that later.
If your career as a designer has been anything like mine, it’s been varied to say the least. Working in design can be as euphorically rewarding as it can be emotionally draining. Amplify those extremes even further if you’re in an agency.
To be clear, this isn’t an agency-bashing post, there’s a lot going for them. If you want out, there are a lot of good things that you have to consciously decide you don’t want any more. The breadth of design work, the camaraderie, the work hard play hard attitude, the ferocious pace (which has its own pros and cons of course), and there’s no denying the addictive energy.
I guess it was around the 7-year mark (maybe the “7-year itch” applies to careers, too?) when I first decided I wanted to try something different. Product design in the digital world was now a well-respected thing, and even though stories about Google offices having beds and giant slides weren’t realistically achievable for me to experience, they added to that itch. I was fortunate enough to work on some fairly big projects at my previous agency, allowing me to taste those flavoursome acronyms of IA, UX and UI. It was a taste that I couldn’t get rid of.
So fast forward to the summer of 2017. In a single weekend I said goodbye to a role I knew inside-out, celebrated my son’s first birthday, and began a new job with a title I’ve never had before, working remotely. Gulp.
Spoiler alert — turns out it was the best decision I could have made — and I figure a year is a nice point in time to have a bit of a retrospective on the whole thing.
What’s the difference?
Process
There’s a massive difference between how agencies and in-house product teams operate. Put simply, agencies answer to clients, and products answer to customers. The challenging relationships the vast majority of agencies have with clients makes it incredibly difficult to be proud of the finished article. Creative juices become so diluted that you question whether you even put any Ribena in there in the first place.
I’ve witnessed countless times projects go back and forth to clients and mutate into an unrecognisable monster, so that in the end you can’t wait to see the back of, which is a real shame. But, ultimately, the clients are the ones paying the bill, and particularly if it’s a big bill you often have to sacrifice your creative vision to get that cash in the bank.
Paid-for products, in particular SaaS products like GatherContent, have an entirely different approach. The obvious difference is that there are no clients. There are no rounds of amends or the need to manage client expectations. The caveat here is that products don’t get the luxury of making rounds of amends — you keep failing and you’ll lose customers, it’s as simple as that. Therefore, before releasing a new feature or even a tiny update, there’s a lot of work that goes on behind the scenes, more-or-less involving:
Review business needs
Research customer feedback trends
Research the market
Prototype
Test prototype
Iterate
Visual design
Test
Build
Test
Release
In agencies, it’s the kind of process that gets sold to new clients in a pitch, but rarely happens. In most cases it’s because the client doesn’t deem research, prototyping and testing valuable, and so cuts them to reduce the budget. What you’re often left with is:
Visual design
Build
Release
A far simpler process, granted, but one that rarely hits KPIs. The end result is something that’s built on assumption. You should never assume. It makes an ass out of you. Just you. And don’t even get me started with content.
Products must focus on quality, above everything else. Imagine if Facebook’s Like button didn’t work after an update? The world would implode. Releases regularly get delayed because they’re not quite ready. It’s the reason why you never get solid release dates on roadmaps — by doing this you’d be just setting yourself up for failure, and a barrage of messages from frustrated customers. Monzo’s public roadmap demonstrates this nicely. Ultimately the lack of hard deadlines make for a far nicer environment to work in, and one that directs focus toward product quality.
On the flip side, agencies are all about speed (gotta bill them clients, yo!). I’ve spent the same amount of time working on a settings menu for GatherContent than I have working on an entire website design for my previous agency. Was I proud of the website I designed? No. Was I proud of the menu I designed? Yes. Because I knew it was correct and meaningful — confident that it solved real problems. It wasn’t just something designed to go in my portfolio.
Product/In-house = quality.
Agencies = speed.
Yes, that speed trait is pretty valuable, but 9 times out of 10 you just can’t have both. It’s a case of looking at the iron triangle and picking sides, and given the choice I’d always side with quality. Quality paves the way for memorable experiences.
Details
Time was a luxury that took the longest for me to adjust to. From working into the early hours designing a website for a pitch (😑), I’ve now got all the time in the world to really dive into the details. It took me a while to learn to take a step back. To not go in so gung-ho with each project. To research, draw, prototype, test. Not always in that order, and not always all those steps, but it was these bits that filled the time, and made sure I ended up with a considered solution.
To give you a tangible example, a recent feature we’ve been working on is search. Yeah, search. Everyone knows what search is. We’ve all used search before, and we’ve all got that magnifying glass icon seared into our brains — so you just whack in a search icon, maybe even include a text box, and be done with it, no?
No.
This is where states come into play. Scott Hurff talks about states in far more detail than I’m about to, but ultimately states consist of every conceivable possibility a user might encounter when interacting with your app/website/thing. Scott calls these a UI stack, and it consists of; blank state, loading state, partial state, error state and ideal state (your money shot).Even before any of that — it’s the planning stage. We need to figure out how we want search to function, before we get close to designing anything.
The user flow of using our search component
This shows our desired user flow. The user clicks on the search icon/text box and are shown recently viewed items/files. They then type a search string and the recently viewed list turns into actual search results — each with their own target when clicked. If the user deletes the text they’ve entered, they see recently viewed files again. Easy.
So we know how we want search to work. Let’s quickly sketch out what we want it to look like. Let’s not get ahead of ourselves. We aren’t reinventing the lemon squeezer. Besides — we want users to instantly know how to use it so it needs to use familiar design patterns. It doesn’t belong in MoMa.
Not the neatest, but it doesn’t matter
Isn’t that beautiful? We’ve got an active search showing categorised results — “content” and “assets”. Content results show how many instances of the search term were found, and which item those terms are found in. There’s also some useful meta data below each result. Matching results under assets would display a thumbnail of that asset, along with its name. Just out of crop are some other sketches I did of a full-screen search experience. This is the best place to test out ideas like that — you very quickly get a good feel for how a feature will work just by drawing.At this stage we’re pretty confident this approach will work. It’s a small component of the app, so we decide not to spend any time working up a complicated Axure prototype. Design times!
That infamous search icon just sitting there, chilling (and my pesky face)
Our search component features an expanding text box, so to prevent this part of the UI from jumping around all over the place, we’ve made search the left-most menu item.Below are designs of the partial, error and ideal states.
Partial state, before the user types anything
An error state, when there are no results
The final, ideal state of search results
So as you can see there’s a ton of detail we can go into for the simplest of functionality. And as I’ve said before, we need to go into this amount of detail to make sure that it not only works, but effectively responds to our customer and business needs—in this case increasing engagement and NPS, and customer retainment.
Search is an issue we’ve had validated for months via customer feedback, so the solution had to be right. Without search, users were wasting time opening each project and reading content to find what they were looking for. Now, with this work, we’ve made their lives a lot easier and ultimately they’re now getting much more value from the product.
More on details
If you’re not obsessing about the details, you’re doing it wrong. Dan Saffer says it best in his book on Microinteractions:
Details demonstrate that some care, some thought, some attention has been paid. And this is ultimately what we all want to feel: that some attention has been paid to us and our needs… Think small, and change the world.
If you’re serious about designing meaningfully, go do some reading on microinteractions. If a dedicated book is too much to take in right now, here are some more digestible Medium articles:
A fine example of a microinteraction is in Dropbox Paper. Paper automatically saves as you type, but they recognised that people will instinctively hit CMD/CTRL + S, like, all the time if you’re anything like me. Every time the user hits save, a useful message appears informing them of their auto-save feature, with an ASCII emoji that keeps changing. Brilliant.
Example of a microinteraction in Dropbox Paper
Iteration
In design agencies a lot of projects expire. You complete a project and hand it back over to the client for them to worry about.It’s not the same when working on a product in-house. You’re dealing with an ever-evolving living thing that requires your undying attention. You give it so much that eventually you identify room for improvement, and that’s fine. We have an insanely easy ability to change our minds, to test, learn, tweak and repeat. Occasionally you make an update and it doesn’t quite work out, but that’s not a problem — “fail fast” as they say.
The market is constantly changing, which means so too are our customers’ needs and expectations. If we were to stand still our customers would leave us in their dust. From a design perspective, they have no emotional attachment to our product, so neither should we.Here’s another real-life example. With GatherContent being a Content Operations Platform, the core part of the UI is our content editor, and features a sticky status bar that sits at the bottom of the browser, sharing useful info, unobtrusively, to the user. Too unobtrusively it turns out, because we started getting customer feedback saying that it was easily missed.Here’s how it used to look:
Previous status bar design
At first glance, and without a comparison, there’s not much wrong with this design, it contains the information without anything spilling out. There’s a keyboard shortcut button on the left, followed by the word count of the item. It’s 30px high — adequate for a status bar.Let’s look at the updated one:
The current status bar design (with added text formatting indicator)
Look at the breathing space! This one is 40px, a mere 10px increase in height but in comparison it’s a whole third bigger. This allowed us to push the font size to 14px instead of 13px, and have equal horizontal and vertical padding. All of these changes combined make for a more pleasant viewing experience (even with the added formatting indicator), and what’s more, this bigger size now makes it feel more part of the UI rather than an after-thought.An important take-away from this would be that, just because customers negatively fed back on the original design, it didn’t mean we had to reinvent the wheel. We simply iterated, and no doubt we’ll iterate on it again in the future. Such is product progression.
Design systems
In agencies I created my fair share of brand guidelines. The anatomy of a brand, documenting every decision ever made verging on OCD; the do’s and don’ts of the logo, where to put the logo, where not to put the logo, what temperature to wash the logo, not to mix the logo with dark colours… you get the idea.
If you’re lucky you’ll get a couple of pages giving examples of “brand usage” — how a presentation might look, or how a website might look. If a third-party agency or designer picked up some design work, there’s a distinct lack of direction when it comes to creating digital assets.
Design systems aid design thinking at a granular level, so you can spend more time providing solutions to problems rather than spending time drawing rectangles, adding rounded corners, adding shadows, and so forth.
They are very quickly gaining traction in the modern designers toolkit — particularly in product design where repeating UI components is the way of life. They are no longer a mass of button styles that you cobble together at the end of a project to share with the world and say “Hey everyone, come and see how good I look!” — Ron Burgundy.
Design giants Sketch, InVision and now Framer are getting on the design system bandwagon by implementing them directly in their arsenal, allowing you to reuse design elements in the form of “symbols” or “components”, depending on your weapon of choice.
Tired of recreating the same button style over and over again? Use a design system. Know for a fact you’ve already got a dropdown menu designed but can’t find it anywhere? Use a design system. Other designers in your team keep changing padding values? Use a design system.
Yep, they’re time consuming beasts to create. It’s the primary reason why agencies don’t allocate resource to build them (again think of a typical project’s lifecycle), but in order to maintain efficiency and accuracy in large-scale design projects, design systems are a no-brainer.
I believe a lot of pressure is being put on agencies over this very subject. Companies are now wise to the fact that customers want experiences, and how their websites look is no longer the top priority. Try to think of a marketing website that doesn’t have some sort of social media campaign tied to it. These long-term campaigns add to the longevity of websites — so the argument for design systems is ever-growing.
A snippet of our design system
Design systems are very much organic. Unlike brand guidelines that are rarely touched once completed, they grow in tandem with the growth of a product. Ours is a relatively young system, but over time will mature into a well-mannered being that you’d be proud to introduce to your grandparents.To get started in the world of design systems, here are a few tips you might find helpful:
Name effectively. If you use Sketch you’ll learn very quickly that the way you name symbols is an art form. Always allow some flexibility with your naming rules. For example, for a search icon, don’t be tempted to name it “search/icon” — instead use “icon/search” — that way should another component of your design require a search icon, it still cognitively makes sense, without having a design system featuring multiples of the same icon. Try to keep as close to the top of your UI hierarchy as possible.
Create as you go. It’s an easy mistake to make, we made it. Retrospectively creating a design system is a tedious task, not only in creating the system itself, but then replacing all of the UI elements with those from the said system. You don’t need to have a final button style before it goes into your design system — that’s the beauty of them. If you decide to change the way your button looks, you just need to change it once.
Learn your tools. This seems obvious, but every software has its quirks. For example in Sketch (at time of writing) symbols must have the same dimensions in order for them to be hot-swappable, maintaining any applied overrides.
Don’t limit yourself too much. If nothing in your design system feels right in that new bit of UI, then it probably isn’t. It can be tempting to force elements from design system into areas that just don’t work, so if a new feature is calling out for a new component, add it.
A final thought on design + code
I’ve always questioned the seemingly required relationship of design and code. A quick scan of product design openings reveals that the vast majority of them require some sort of development knowledge, usually along the lines of HTML, CSS and JS, branching out into React territory the higher up the food chain you go.
In contrast, a design role at an agency very rarely requires experience with code (though they do tend to go in the opposite direction, isolating designers from developers). Still, they recognise that they are indeed vastly different practices.
Yes, you’ll be well placed to understand about web languages, particularly their limitations, but you shouldn’t be expected to work with them. The best architects know how a building is put together, but they don’t have the ability to build it themselves.
In the last 12 months I’ve not been expected to touch a drop of code. I‘ve dipped my toes in water occasionally to help out during some busy periods (and even that was to just update some CSS), but on the whole, nada. When I applied to GatherContent it was considered a nice-to-have. I work with considerate developers who care about the details just as much as the designers, who can put up with us asking them “could you move that left by 1px please?” without batting an eye. It pays to have patience in all areas of a product team, as that patience will always translate into quality.
Don’t get me wrong there are lots of designers who design with code and kudos to you, but jumping straight into the browser to design has never sat right with me. Pencil and paper is still a solid foundation for solving design problems, and is my go-to starting point. I just hope companies continue to recognise this and not limit their pool of creative talent.
Let’s wrap this up
It’s been a very interesting year for me. I’ve learnt a staggering amount, not just with the hands-on designing of a product, but with the way a remote working product company operates. I’ve also been forced to more deeply understand our domain, and that of our customers. Gone are the days of mindlessly pushing pixels around until it looks nice without truly caring about a clients’ business or vision.
And don’t forget a year is nothing. I might have a few years design experience under my belt but as we’ve discussed this is a very different role, with plenty left for me to learn, and I hope to share more of these findings with you in the future.
To summarise:
No cutting corners. Product design is heavily reliant on process. If big chunks of process is missed, then the product suffers, and a poor product will ultimately struggle to maintain users. First impressions really count.
Pay close attention. Details matter. Search isn’t just a search box, it’s a magical gateway, transporting users to any part of a product in seconds. Treat the small stuff like it’s the big stuff.
Show you care. In product design it pays to finesse, to make users feel something. To not just look pretty, but have personality too.
Be one with the system. Invest time in creating and managing a design system. Don’t be tempted by pre-built system templates until you’ve mastered your own.
Share on Facebook
Share on Twitter
Share on LinkedIn
Share with email
