Over the last year, I have learned a lot about what it means to be an independent worker. Mostly it means that you are never satisfied with the project you are on, and that you are continuously looking for new challenges to sink your teeth into. During this past year, I’ve done a lot of reflecting on what types of challenges I want to take on, and have talked to others about this topic at length. It feels like, as a design community, we are always looking for the same big challenges. Working for ABC because they did this campaign, working for XYZ because they did this talk at this conference, working with DEF because only the best designers work there. Talking with my peer review group a couple of weeks ago I found myself asking, are we a profession that is obsessed with reputation? We are always talking about innovation and creativity, yet the majority of us want to work at ABC for the same reasons. How, then, do we expect to foster the principles of change that we all speak of?

What am I trying to get at? I’m asking you as design professionals to tell me the advantages that you see working for the big guys? What products have they produced that are more fun & challenging that Joe Smoe’s website start up? For me, I’m really beginning to think how much of it is what these companies/agencies produce and how much is just for the reputation that they have? We follow these guys like they’re rockstars and we’re the groupies… “John from DEF is speaking at yadda yadda (some UX designer faints from excitement)”, but how different is the work that you are or could be doing for someone that can’t afford to hire DEF? Isn’t it time for our community to expand beyond the big names, isn’t it time for us to start to create different big names and great ideas??

All this being said I know that we are all doing really great work that is creative and helpful in our careers, but my question is would you trade all that work to go to a giant agency? And if so, is it because you will learn more & solve great problems, or is it because of their reputation? I’m definitely starting to lean the other way myself, but that’s not to say I’m not also guilty of being a groupie. What it means is I’ve start asking myself these questions and determining where I want my career to go, and what types of challenges I want to entertain in my future.

What are your thoughts? I would love to hear them!

Share this post:

Ok folks it’s time for reason number 4 why your developer hates you. That is “We don’t like when you change your mind… especially when we don’t hear about it”.

Ever been knee deep in some really great experience work? Ideas are flowing; flows, screens and goodness is coming together. You have a great and, more importantly, usable solution and then you present it to the business, and you hear “By the way that requirement, that requirement has changed.” “Really, when?” “Oh some time ago.” “Oh, well why?” “well bla bla bla bla.”. Yes, I’m sure we have all been there, and probably all consumed a good amount of alcohol after said meeting. There is nothing worse then being a proactive designer doing your best not to “slow things down” (because that’s what design does afterall) and getting kicked in the gut with miscommunication. Nothing worse perhaps unless you are developer designing the code to support a UX design solution that has changed without your knowledge.

Developers go through similar processes in creating their solutions as we do as UX designers. Whether in a formal or informal way, they take the current development environment, future plans for this environment, other projects and timeframes and put together a design for how to lay out their code. As you are presenting your design, their brains are working to figure out the best way to stay within their constraints while addressing your requirements. They may start actually creating code (especially in an agile environment) to come up with the perfect solution. And while presenting that code (maybe in a prototype of sorts) they hear “By the way that screen, that screen has changed.” “Really when?” “Oh some time ago.” “Oh, well why?” “Oh because bla bla bla.”. You know the feelings and thoughts that come next because you feel and think them yourself. Why the %$#%^ didn’t you let us know?? Why did this have to change, why can’t we do it this way?? This is crap I don’t feel like part of the team. Etc, etc.

We need to treat our developers as partners. We need to go to them right away if there are shifts in our thinking. This is obviously much more essential in an agile working environment, but all the same should be practiced no matter what. Software development is a balance between many different skills and expertise, but should not be a war between them. You know how you feel when requirements are changed, so don’t allow others to feel that way because you’re not willing or don’t think to communicate well. You as a UX designer promote and stand up for the user, but don’t forget to promote and stand up for those that allow your visions to come to life. The lesson of this week is to communicate your ideas and changes to your development team. Let them know why your solution is changing and listen to their ideas and thoughts on the topic. And most importantly, let them know as soon as possible, so that they can revise their design.

Next time: We don’t like when you make us do work.

Tech UX Developers Development

Share this post:

This is the third post in a series devoted to helping UX Designers see where the tension begins between them and their development team. You can read the first and second posts here, and remember if you have suggestions, ideas, other reasons why you think there is tension please, pretty please, pass along your thoughts.

But now let’s talk about reason why your developer hates you numbero 3. I tagged this in the last post as “You don’t really know what I do and don’t take the time to care.”, but I’m not sure that’s the route I’m going to go this week. First let me explain where this idea came from. In my roles both past and present, I’ve seen designers get extremely frustrated with their developers. “Why can’t you just do blah blah blah? I don’t get it it should be easy!”. And the developer says “It depends. etc etc”… sound familiar? Looking at this transaction of words and ideas I can’t help but think about when people ask me what I see as whacky or “it depends” questions about the user experience. If I had a dollar for everytime I’ve heard something like “Why can’t we just throw blah blah on the home page or blah blah blah in the global nav or blah blah”… well you get the point. No one took the time to really understand my role and its importance and constraints. Isn’t that how we are treating developers when we get frustrated with them for working within their role and constraints?

There are several bits of information that we as UX designers may not be aware of. First, developers are working within the role. What does that mean? It means, as a developer I’m trying to stay within some role boundaries and that can lead to “it depends” answers. Solution ABC would be an easy thing to code if we were working on this technical platform, but we’re not, we’re on that platform and in that environment solution ABC is much harder and more expensive. If we want to take the entire site and move it to a new platform then we can do solution ABC easily, but we’ll also be spending millions of dollars. Also, a developer may have expertise in one code base, but not in another. In other words I know all about the code that serves up the blue screens, but the green screens are not my cup of tea so I’m going to tell you what I think, but it really depends on what the green screens team says. And lastly, they have senior developers and tech leads who oversee their work as well, and although a developer might think that solution ABC is easy, their lead is telling them that they must do solution ABC another way… which is more time consuming and therefore more expensive, however it fits better into the design of the code base. The design of the code base is important because it ensures stability of the website and efficiency.

This leads to the next bit of information that UX designers may not be aware of. Developers work with, in some cases, some severe standards and constraints. So, just as we need to work with existing pattern libraries, standards, or experience themes, they also need to work within limits. Page load times, error logs, calls to the back end, the amount of code they put on the servers… they are only allowed by their superiors as well as other units so much leeway in these areas and we need to be aware of this and take this into consideration when compromising with our technology partners.

I would suggest that you talk to your developer about their role and any existing constraints. Do some research, ask them questions, or even interview them informally. This will only inform your design process, and help smooth the rocky road to product delivery. Be warned, that this is not to say that your creativity should be imposed on. By all means go all out and design the ideal solution, but when it comes to scoping a design effort you’ll be much more informed as to what can and can’t be done in the present time, and what will be needed on the technical end to get to your end goal.

Coming next week: We don’t like when you change your mind… esp when we don’t know why.

Tech UX Developers Development

Share this post:

Recently I’ve decided to start a chain of posts talking about tension between developers and user experience designers (Note: sometimes these roles overlap). Here, you can read my first post and also a great response from Lee Fastenau an amazing designer/developer/genius over at Frog Design.

On to reason number 2 why your developer hates you. I alluded to this last week and it goes something like “You bring us to the playing field after the game is over.” As UX designers we complain about this ALL the time. Oh the effects that we could have had and the solutions and ideas we could have brought to the table if only we were involved up front! This is exactly how your developer feels. There are a couple of pieces to this.

First, remember what it was, and is still like when the product owners do this to the UX team. The frustration in knowing how you could have helped is almost overwhelming. You feel useless and say “why am I even part of this company?” Remember how it feels and the problems this causes for the product and, ultimately, your end users who you advocate for day in and day out. Well here’s something to keep in mind. You are not the only one who is advocating for them. Just because it is in your title or job description, doesn’t mean that others aren’t thinking about the end user. They just may not be thinking about them in the same way… which is a good thing as this balance is what makes product/software/web development exciting, interesting and successful. And if you don’t bring your developers into the game, you not only lose this balance, but you create the same feelings of frustration on their part.

Secondly, keep in mind that just like you have a list of user experience upgrades that you’d like to see to your site, your development team also has a list of upgrades that they would like to make. When these are in sharp contrast (which happens so often when the two groups are siloed) then heated arguments and frustration ensue. These arguments do more than cause frustration however, they waste money something that the development team usually has a eye on at all times.

Let me explain this a little further. While at a past employer I was a part of A LOT of planning meetings. One thing that was eye opening was that the technology team (even in this VERY technology/IT driven company) found value in hearing the UX department’s “to do” list. And not only value in hearing it, but value in collaborating on the two lists in order to come up with scoped projects. This almost caused me to pass out from shock and awe, but these technology political powers knew that working together up front would bring a better solution for our customer at a cheaper cost. And yes, IT wants a better solution for the customer and not just to do cool and new stuff within the system as we sometimes think. Once we collaborated with the development team, things began to actually move within the corporate environment. But leaving them out of the game fostered the same non movement that we all complain about.

Also, in companies that I have worked in any way, the development team has a much clearer view of one thing… budget. Because of this, working more effectively up front is ideal because it involves less churn on the back side of the project which in turn saves money. It also enables teams to not have the massive descoping efforts that we go through in order to bring our UX solution inline with what the technology can handle. We as UXers should remember this and use this reason to collaborate with our IT team up front.

Remember if you don’t like to be treated one way… don’t turn around and do it to another person. If you want to be included up front, before a project even begins, so too will your development team. When they see your UX vision and user end state, things are much clearer as to what they are developing for and what the end product looks like. You see what their challenges are and gain empathy for their role. That’s the way a team works.

Coming next: You don’t really know what I do and don’t take the time to care.

Tech UX Developers Development

Share this post: