Here’s What I Learned From Being A UX Designer In A Dev-driven Company
When I first started going all-in on UX design sometime in 2017, I didn’t really know what to expect. UX has always been a big part of what I do and how I approach building products—but I didn’t know that by then.
Quick disclaimer: Many of these concepts and ideas apply to the design of enterprise-grade applications. You might find, that some ideas won’t work for a small startup building a b2c app.
Over-communicate everything.
This might be caused in part by me being a remote worker, as well. But I learned that it really makes things easier when you try to be as verbose as possible. What I’m talking about here is the little quirks of your designs. It might be very obvious to you, how that particular spacing should work, or when an element should be fluid instead of fixed width.
“This applies to team members just like it does to clients. If you don’t have the chance to hand over your design in person, be as verbose as possible.”
Actually, though, not even the designer right across the table can reconstruct your thought process on that specific piece of UI. This applies to team members just like it does to clients. If you don’t have the chance to hand over your design/prototype/whatever in person, be as verbose as you can. Even if you do hand it over in person, it makes sense to persist your current thoughts, if you have to look at some early prototypes later on. Features get re-prioritized all the time, and building software is always chaotic. To be perfectly honest with you, this is a problem I still face all the time. Whenever I don’t write stuff down, it’s haunting me later on.
My tool of choice for this problem right now is Abstract. It has most, if not all the features I know and love from other tools, while also embracing a git-like workflow. This makes it exceptionally easy to collaborate with developers and fellow designers.
If you can’t use any cloud-based service or have some kind of other limitation preventing you from using Abstract, anything will do, really. At some point in time, I just annotated the screens with little digital sticky notes in Sketch, just to get my point across.
Being consistent pays off.
One of the main problems, when I went full-time designer in the first place, was consistency. Most of the time I did my designs by gut-feeling, which resulted in funky sizing, that was all over the place. This worked just fine, as long as I was the only one working on the designs and also the single source of truth for all CSS in the project. I could happily fix some sizing here, unify some spacing, merge some colors — well you get the gist. The more you try to scale this system though, the faster you realize that it has a giant weakness. So what I did was quite simple. Create Sketch Symbols ASAP, and be damned if you don’t use them across the board. Whenever I’m done bootstrapping a potential feature with a client on paper, I put up a quick mockup in Sketch. That way I can get their approval and start the work on standardizing the elements in the mockup to fit in Symbols. This makes it super easy to get moving on a feature fast, while also keeping up productivity later on.
As another mean of building more consistent and efficient design, I also adapted the 8-pt grid. The key point to the 8-point grid is sizing and positioning elements only by multiples of eight. By doing so, you make it easier for everyone on the project to approach your designs while also keeping your brand consistent.
My personal reasoning for this approach is quite simple as well: you’re a hell of a lot more productive when you don’t have to move elements by one or two pixels all the time, just to find out you still can’t settle for a final solution.
Treat your dev’s well.
I know it’s easy to blame the dev for not adopting your design properly, or being too lazy to implement that awesome animation you carefully designed for two days. For the most part, those same developers are just doing there absolute best to try and build those peculiar ideas of yours, though. So, what should you do then? Well, it depends. In my book, the easiest way is to speak a common language. If you understand the general thought process — think components, hierarchies and hard boundaries between these components — it tends to be easier to respect those concepts.
So, if you have the chance, go ahead and get your feet wet in developing apps. If you don’t, just talk to your team! They probably won’t bite your head off, when you ask for their help. Quite the contrary, they’ll probably be very eager to explain those concepts to you.
Get feedback as soon as you can.
Most days it’s very easy for me to get lost on designing just the perfect button for a project, kind of like sitting in my ivory tower. I tend to overthink problems and get distracted easily. As a general means of self-regulation, I try to present ideas as early on as I can. I generally try to send out some prototypes immediately when I feel like they don’t look completely horrible anymore.
This practice tackles several problems at once:
- You can get immediate feedback from the team and/or client. If you’re headed in the wrong direction, you can change direction before you‘ve built a high fidelity, polished and perfect screen.
- More often than not, someone in the team can give you that one idea that you couldn’t quite put your finger on.
- Over-communicate, seriously. Everyone now knows what you have been working on and can get a rough idea about when your work will be done.
Usually, I just share those first drafts through Sketch Cloud or InVision since there’s not really much more work involved than reviewing and commenting on what I’m just working on. I found that sharing this work in progress stuff via text (think Slack or E-Mail) doesn’t work as well, since comments will get lost and the reviewers can’t really focus on the task at hand, but rather juggle a few tasks at once.
Conclusion
In the end, it boils down to a few key factors:
- Over-communicate
- Choose the tools that work best for you and your team
- Try to be as consistent as possible
- Get feedback ASAP
That’s it for now! Thank you for taking the time to read this. If you have any questions or suggestions, shoot me a tweet or mail! I’d love to hear from you. 🙏