Loading...
Answers
MenuHow should the dynamic between a ux designer and a developer who are working together look like?
I'm noticing a situation where the developer might feel like he's bossed around by the ux designer.
Answers
It depends a lot of in the skill sets and experience of both people but in most cases the ux designer should be controlling the developer pretty heavily in order to make sure his ideas come through properly.
The UX designer may just need to work on his approach so people don't feel bossed around and more like they are working together.
In an ideal world, there would be a project manager who makes sure everything is communicated well and keeps the dynamic feeling great.
I've provided IA and UX direction for nearly 200 websites over the past 4 years.
The dynamic between a UX and developer depends on both the designer and developer technical skillsets.
Some IA/UX designers solely provide wireframes, flowcharts, and mockups. Great UX designers move their role forward by providing rapid prototyping with working knowledge of HTML5/CSS3/jQuery/JavaScript.
This being said, I believe the ideal dynamic between a UX and Developer is to achieve the proposed goal, using the least amount of resources.
Use whatever you have to as a team to get there, so long as you get there.
This is quite simple: Honesty and Openness is the first step to a strong relationship between Designers and Developers.
Designers need to be very open about what they are trying to achieve and why and developers need to listen to that. At the same time Designers need to be very transparent about how they need to do something to get the design working and why that may not work the way the designer has planned it to work - rather than just saying something like 'that won't work' to avoid an argument. Remember rational arguments are a good thing.
And get the developer involved from the start - that's just human nature that you don't want to be left out. The designer should feel like they can ask the developer for advice about the technical implementation - rather than be scared the developer will say no.
The more honesty and openness there is in your work environment the less people are making assumptions about what others think and you will have less friction between resources.
John's right that ultimately there needs to be a Project Manager or someone playing the PM role. Ultimately, there are *always* compromises or at the very least "adjustments" required between what the design team envisions and the engineers implement. Most often, these are compromises to meet business objectives (deadlines and resource constraints) but sometimes, there will be issues around implementation that the design team hadn't considered, depending on the experience and technical understanding of the design team.
I've worked with (and currently work with) brilliant designers and engineers and spend a good portion of my product team managing the tension between the design ideals set forth by the design team and implementation issues raised by the engineering team.
It's almost impossible to expect either camp to effectively reconcile the issues of the other.
Who are you in this dynamic? If you're their leader, then lead. If you need help with that, let me know. Your question suggests you are unsure whether there is an issue at all. If you are genuinely unsure as to whether there is a problem, ask your developer.
A shared attitude between the UX designer and the developer is not only healthy but necessary. Both of them have to focus ultimately on what the users will get, and use. It's not about having the fanciest, most unique and innovative user interface. Nor is it about having the most whiz-bang technology or groundbreaking coding techniques. It's about having a software that will be easy to use, useful, and usable. "Easy to use" because the user interface is intuitive. "Useful" because it does what users need it to do. And "usable" because it works when users need it to work.
The UX designer should be able to explain and illustrate adequately to the developers how the software works, looks, and feels - whether that would entail showing a functional spec, wireframes, or a complete set of mockups would depend on the maturity of the developers, and the ability of the UX designer to explain. But as long as the developers do not fully understand what the product is supposed to be and do, then you will always have problems along the way.
I realized this as a major industry challenge a few years back, as the designer would throw the design that has been completed across the fence and will wait for the engineer to execute it. This would result in either the designer imagining completely pie-in-the-sky scenarios which cannot be engineered within the given timeframe. Or the Engineer building it and the designer later realizing it could've been a much better design. This leads to a lot of back and forth.
For the last 8 years I've actively tried to solve this problem, and have been at the helm of roles which straddle both ends of Experience (Design and Engineering). I am a strong advocate of designers being able to code, and vice versa.
However, this is a very rare hybrid skill-set in the market as of the moment. To counter this, I've worked with teams to have both the designers and developers on the same team, and collaboratively build stuff. The trend that is working very well is reducing time spent on PhotoShop, Omnigraffle and design more so in the eventual medium - which might be the web, for example.
This collaboration helps engineers bring available affordances and interaction possibilities of the medium to the conversation and designers can focus on the larger taskflow solutions and interaction design.
Happy to answer any queries in person, Feel free to reach me.
Developers and designers are both sensitive with feedback, ( guilty as charged) as a UX UI designer i make sure i collaborate through out the project with my developer and team. Goes both ways too. I benefit greatly from developer input and has saved me from making decisions i regret if i had not asked if it could be built. I also agree having a project manager or scrum master in a team is a great idea.
It does depend on the experience levels and responsibilities outlined for each role, but in an ideal collaboration the developer feels like he or she has had input on the designs so that something out of scope or technically impossible is not handed off for development. Likewise, the designer feels as if they continue to have creative oversight and that the UI and UX meet their specifications and that changes are not implemented without first discussing the reasoning and there is agreement on the compromises.
Today, screen sizes vary from a tiny iPhone5 to mega-desktop monitors. As the user changes their screen size, the app should fluidly adjust based on the ratios of the design. This is where you can stand out as an excellent UX designer. They love creating a great product, so they will love when you share your user research findings. Research the user base. Provide suggested break points in pixels based on how most users will be viewing the app and hand over mock-ups for each break point that are based on percentages, not pixels. UX designers often build with accessibility in mind, carefully choosing layouts and colour schemes to increase usability. Yet style guides still indicate font size in points, which is less accessible on the web. No matter what the engineering team decides to use, you have covered all your bases and made their lives a little easier. Developers use responsive container elements like Flexbox and Grid to easily handle the transition. While designers don’t need to know how to code with Flexbox or Grid, understanding how it works will make it easier to communicate with your developer teams, and create designs that work with this styling in mind. Trust me, your developer will thank you.
Recently, a designer lamented that her team could not implement a dark mode mock-up she gave them towards the end of a project. Developers are often judged by their output metrics, so when they balk at a design, it might be a time constraint issue. Understanding what Frontend Developers do at a high level and how HTML/CSS/JavaScript work together, will allow you to create easier to execute designs for the given timeline. Involving developers in the process right from the start will make the entire communication process better. Collaboration is a key part of creating thoughtful, beautiful apps that are accessible to all users.
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath
Related Questions
-
What's your opinion on using something like usertesting.com vs. real time usability testing (online and offline)?
UserTesting can be instructive in terms of understanding whether people understand your copy, CTAs, and intended flows but generally, I've found the quality of their panels to be pretty low. You're almost always getting people who are not your actual users, so the feedback can only be generally applied as above. I find whatever web analytics package or packages you're using are generally able to provide much better insights. I also really do believe in *real* user panels. Buying pizza or offering small financial incentives to real users to click through new flows where they are talking out loud or answering specific questions is going to give far more actionable insights than anything else. What I like to do is take my best guesses as to what's not working or what I'm looking to improve and then discover/validate via real in-person customer panels. Happy to talk through this in more detail with you in a call.TW
-
How do I run a closed beta test for my mobile application? Development will be finished in 3 weeks.
You should try to engage people using social networks, it is easier to spread than email. The conversion rate on emails are low but is still a valid tool for that. Send and email with a simple and objective message that will make people want to try. The best way to have feedback from users is to watch them use the app. You should put them on the hands of everybody that you can and without any instrucions and just watch, don´t even say that the app is yours. Try to do it a lot. If you want feedback from others, you can include the feedback form inside the app and suggest users to answer occasionally. I would also strongly recommend to use a tool as Flurry Analytics. Is the best way to get data from how is the use of the application. Pay attention to those data and be open to change your app a lot, you may need more features or cut some off to make it easier to use. If you need more help please contact me.BS
-
I have a great app idea, and I need help bringing it to life.
I'm not sure if this is how you imagine this world to work, but at least according to the order you wrote it "raising funds" was first. In reality it should actually be one of your final steps of the stage you are at right now. It may even come after a year or two! So you have this great app idea, and you're looking for a place to start... Don't! Don't start yet before you decide whether you have what it takes to get into a roller coaster that can ruin your life and make you miserable! Not trying to scare you but I think most people only hear about these great success stories. They have this dream of maybe, possibly, becoming the next big thing... Because they have the best idea for an app... You don't hear about the failures so often. And even if you do, you don't hear about what the founders of these failing startups had to go through. Truth is you are most likely gonna fail. And I'm saying that without even knowing what your idea is. There are so many barriers on your way that even a great product with a great team is likely to fail. Some people would say "I'm not afraid of failing", "It's good to fail cause you learn", "Failing will make me stronger for the next startup". That's somewhat true but it doesn't mean that failing is easy. As oppose to what people sometimes say - you do not want to fail! It's very painful!!! You have to understand what failing in a startup means. You can work your a$s for 2-3 years, have little to no salary, waste other people's money (most likely your friends and family first), lose friends, fight with your partners, your family, your spouse, devote 20 hours a day for your startup all this time, forget about the little and big things you used to enjoy in life, and only then, after debating 100 times whether you should quit or not, you finally decide that it's not gonna work and you've failed. Disappointing your family, your investors, yourself. Trust me it is painful. Are you sure you wanna do this to yourself? If yes, give me a call. I have the experience you need! From idea stage, to proof of concept, to running beta tests, getting millions of millions of users in ways you can't even imagine, creating features and experience that will make these millions of users completely addicted and viral, raise money in a smart way, hire the right people, find a great co-founder, succeed, fail, be persistent, and enjoy the ride! Good luck, RoyRM
-
Is having "HOME" button in navigation menu necessary if I have a clickable logo? What makes most sense from UX POV?
We have been collecting usage data on the home button from about 750 websites we manage across North America in an effort to try to determine if it is necessary or not. While each website is different, and much of the data is statistically insignificant, we have started to operate with a few assumptions. 1.) Most users, particularly younger users, recognize the logo as a way to get to the home page. 2.) Websites without home buttons seem to get a comparable amount of traffic to the home page as those that do not. We don't see a significant difference between having a home button or not. 3.) Websites without a home button often will see an increase in direct traffic from returning users during a session indicating that users who do not know the logo is a route to the home page will instead clear the address bar back to the root domain to get back home. Based on our research, we have decided to omit the home button in most instances. Although when it is present, it is often used, most users seem to understand how to get to the home page regardless of the inclusion of a home button. With the complexity of modern websites, we are usually pressed for space in the header and can better use the real estate that would be dedicated to the home button for other UI elements. That said, if the audience for our website skews older, we will still include the home button. Our research has indicated older users are less familiar with the concept of the logo being a home button.RS
-
What would be a good approach for marketing a software development businesses?
For software development business LinkedIn ads, content marketing and Google Adwords don't work well. The best and most cost effective method is email outreach. Try to find the contacts of key decision makers in Bay Area from your target companies. You want to present yourselves as custom mobile and web development specialists and highlight your core competencies to get an initial call to discuss their mobile strategy or software development needs. Attaching your case studies how you helped other similar businesses and your portfolio can be extremely helpful as well. Try to always focus on the benefits in you pitch that they can get by working with you and point their missed opportunities of not having certain types of software or apps for their business. Clients love that software development companies have not only strong execution but also ideation skills. Hope this helps. If you have any questions I am also available on call for your convenience.AA
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.