34

I'm a UX designer in a small software development start up.

Until now, I've always worked with developers since the beginning of interface creation, because I don't want to lose time working on many features and interfaces to discover we can't develop it at the end because it would be technically impossible.

I also believe that if I share with developers the design problems I meet since the 1st step of the process, and if they see me working on, they will feel more involved with the project, and it will be easier to work with each other until the end.

Until now this way to work worked! Perfectly. It was easy and efficient BECAUSE I was on a team with developers who really don't care about design. They trusted on my recommendations as I trusted on their code. Each of us did his work and shared with the other, like a ping-pong communication game.

Today, I had to work on another app development project, with another team, and It was very complicated. Here developers care about design but they are not designers and they don't know how doing good design. So they wanted me to change the interfaces, not for the users but for THEM. They would choose the interfaces that look like what THEY like. But they are not the final users.

So now I have some big doubts about how to work with them or to share my mockups with the team. I really don't want them to feel frustrated, because it's a good thing to have developers who care about design, but I can't let them do whatever they like just because they want to, or just because it's easier to code, or because they like a UI framework and they don't want to change anything on their way to work.

For me, because I'm a UX designer, the final user has the priority. I don't say my point of view is better than theirs. What I want is only one same way to make our application. Only one TEAM point of view. Together.

Do you have any advice about how to communicate, or any good design process to help me?

Improve this question
10
  • Delegation is important in Startups. It's important to explain to the Developers on why should your opinion be considered instead of theirs. You should probably give them your valuable insight and study on why did you choose the respective design and ask them what challenges they could face with it. They need to be in the frame since the beginning so that they can decide the feasibility of your designs and tell you if something isn't possible/time-consuming and you need to counter their design "suggestions" with appropriate reasonings.
    – Swapnil Borkar
    Commented Oct 29, 2015 at 16:38
  • If the startup you work in, can establish a meeting, I would recommend on conducting Design Sprints from time to time to get feedback from all stakeholder's perspective.
    – Swapnil Borkar
    Commented Oct 29, 2015 at 16:41
  • 1
    Btw, developers telling you something is "technically impossible" are bad developers. One thing I like in IT is that nothing is impossible, only the time you have to spend limits your choices and make it "technically inaffordable".
    – NeeL
    Commented Oct 30, 2015 at 20:37
  • 6
    @molot yes, you're right. It was more about how to implement on time. But we had a bad way to comunicate first so I didn't understand them. After creating this topic, I went back to speak with the team. I followed the advices people shared me here. I asked them to explain me more specifically why they wanted to change the interface, how they thought it would be better for the users and what kind of solution we could find together. I told them also about my position as designer and how I need to communicate with them and asked what they expected too. we finally found a way to work together.
    – Léa Mendes Da Silva
    Commented Oct 31, 2015 at 9:15
  • 1
    On my team (I'm a developer), the most effective message that has gotten our grubby paws out of UX is the argument that we are the experts in the system, we already know it. You have to design a UX that works for non-experts. The argument does a good job of stroking our ego while quietly taking control back before we muck something up.
    – Cort Ammon
    Commented Nov 1, 2015 at 5:55

6 Answers 6

Reset to default
21

The Sharing Mockups stage is too late

Assuming you want the developers fully engaged and understanding the reasoning behind the design and decisions made then you should have them in a UX Design Workshop - before mockups are done

In my typical workshop I'd

  • Explore related User Stories
  • Itemise concepts user will be thinking about
  • Do multiple UI ideas that support user story goal [so it's not your idea against the development team idea]
  • Heuristic review of the UI's against a Persona [this puts developers into frame of mind of user]
  • Pick the UI that had best UX for the Persona
  • Close meeting, then do 'production ready' mocks

Approx 90 min for average size User Story

On occasion I'd need to "pull rank" and make a definitive steer. At least there is a good dialog about why. Once I deliberately let through a poor design that development team was highly passionate about. User testing proved out as I expected. After that the team was very committed, not only in improving that design, but also in the delivery of other designs.

Improve this answer
2
  • Woaw, sounds great! That's exactly the kind of process I'm looking for. How did you find how doing/organizing this workshop? Did you follow a specific method? Or did you create this by yourself ? If you have any link, website or book about it I'd like to read it. Thank you.
    – Léa Mendes Da Silva
    Commented Oct 30, 2015 at 12:59
  • 1
    I think I did it the hard way. We evolved this through mix of best practices because couldn't find guiding materials. Then I found right terminology UX Design Workshop and a number of articles (in fairness many of them are recent) so cross-checked what we were doing against the other practices. It was a good fit. One article I remember as being most illuminating can't locate at the moment. I'll post it in Answer if come across it.
    – Jason A.
    Commented Nov 2, 2015 at 16:44
23

You've somewhat discovered the answer to your own question. The best time to include development in the design process depends on the development team you are working with.

Your initial intuition is correct...get the developers in sooner than later. Ideally, they are a part of the design process from the beginning. They have insights and ideas that can greatly contribute to the solution. And as you point out, they can also catch big 'gotchas' up front that would have required major UX changes down the road had it be caught late in the process.

As for your current scenario, where you have developers that aren't necessarily thinking about the UI from a user perspective, I think that's your challenge: get the developers thinking about the UI as a user would use it.

Whenever a developer suggests you change the UI, ask them how they feel that will help the user that is using the software. That might help steer the conversation more towards customer goals rather than developer goals.

Improve this answer
8
  • 7
    "ask them how they feel that will help the user that is using the software" ---> I'll try this helpfull advice. Thanks
    – Léa Mendes Da Silva
    Commented Oct 29, 2015 at 16:47
  • 5
    Well, there are probably perectly good reasons the developer wants to change the design that way, so don't forget to ask them for why they want to change it, independent of whether it helps the user. They might surprise you with something that's blatantly obvious to them, but not (yet) known to you.
    – Deduplicator
    Commented Oct 29, 2015 at 22:49
  • 1
    @Deduplicator there are often times where it has to be a certain way, and that's obviously good to know. But by asking the question about how it helps the user, you get to that other answer quicker. In other words, it's definitely not always about the user, but that should be the first question asked.
    – DA01
    Commented Oct 30, 2015 at 4:48
  • 3
    "ask them how they feel that will help the user that is using the software" I tend to do this by asking all stakeholders to re-frame comments as user stories. This forces them to take the perspective of the user automatically.
    – Peter
    Commented Oct 30, 2015 at 9:04
  • 1
    @DavidSaunders Your comment strikes a chord with me. It is absolutely disappointing when involving the development team results in bogging down the design process. It's often hard to debate a challenge in the heat of the moment, when all you are looking for is if a design is technically feasible. Culture plays a large part in this, especially when having a UX resource is new to a development team.
    – Craig Corbin
    Commented Jan 21, 2020 at 23:27
6

According to Bill Buxton "We are NOT all designers", although "we are all potential participants in the design process", but design is "a profession as reach as math or medicine" that cannot be performed without experience and knowledge.

Although the designer must process and evaluate all possible contributions, the final design is the designer's role and responsibility.

Many developers working in small to medium size companies, believe that they can be designers as well. This belief unfortunately is usually linked with their ego, and this makes it harder to change it.

So, you should try to establish the designer culture in your company by doing some presentations, sending relevant articles etc, in order to distinguish the role of the designer and the developer.

You should, though, appreciate and encourage any possible design contributions from developers. Also, developers should be rewarded and appreciated for what they can do best, develop software, which is a very important creative activity in product development.

The following diagram from Bill Buxton demonstrates the phases of product development.

Keep the role of engineers minimum at the beginning of the project, if you want to create innovative designs:

product development process diagram

Reference:

Bill Buxton, Sketching User Experiences (2007)

Improve this answer
2
  • 4
    I have to disagree with Mr. Buxton. All humans are designers. Some just have more experience and skills at it. :) I would also argue his diagram is certainly valid in a lot of organizations, but is also somewhat dated and reflects a more traditional waterfall process where developers aren't even asked to be a part of the design process. In today's Agile world, I find that yes, some developers simply aren't good at design at all, but many are--they just have never been invited to the table early enough to contribute in the past.
    – DA01
    Commented Oct 30, 2015 at 4:49
  • @DA01 I agree with your comment. When it comes to business models and processes there is not a single true answer. Just to make a clarification, you must have iterations within all phases, and iterations between phases.
    – DesignerAnalyst
    Commented Oct 30, 2015 at 6:35
5

straight away. For various reasons: they can give insight that you would never get from anyone else; can flag technical limitations very early; become emotionally attached to the project.

Improve this answer
4

I am a developer with about the same design talent as the average rutabaga.

I think you may be asking the wrong question - you should probably be asking "As a designer, how can I most quickly gain the trust of the developers on my team?"

Most of the "designers" I have worked with were developers whose management told them they were now designers, and then were given a corporate rulebook about what tools to use etc. Their managers didn't know how to use them, and didn't know how to guage productivity since they didn't produce code.

If your developers are from this kind of environment, you have a serious uphill battle to win their trust.

I have recently had the opportunity to work with an excellent designer, who is truly worthy of the name. He won my trust quickly because I know my artistic ability measures sqrt(-1) on the scale of 1 to 10, and he designed clean aesthetically pleasing interactions that "just worked". He listened to and incorporated my suggestions, but made them look really good.

Improve this answer
3

I am a developer, and the designers on my team work pretty closely with us. We set it up so we have the opportunity to raise questions and give input when the designers give us designs, but then when the decision is being finalized, the designers get to decide and we don't get a vote.

Get input from people who care, but establish a clear boundary between who gets to provide input and who gets to make the decision.

If the developers are passionate about the product, they may be able to give you good ideas, but they need to know they're not the designers on the team.

Improve this answer
4
  • 1
    Thank you. It is very interesting for me to read a developer. It's not easy to know where et and how I should establishe a "clear boundary" as you say and it's helpful to know that you, develope, are ok with that
    – Léa Mendes Da Silva
    Commented Oct 29, 2015 at 20:37
  • "we don't get a vote" = that's not a great policy, IMHO. Developers should own the project as much as the UX folks and everyone should have a vote. That said, I do agree that it's good to have 'the decision maker' (I usually prefer that to be the product manager).
    – DA01
    Commented Oct 30, 2015 at 4:56
  • @DA01 : Me too I prefer when there is a product manager to make final choice/decision. But in very small software companies as mine there are some teams of just developer. We are 2 designers for 8 softs different with 25 dév. The Product owner can have 2 or 3 products different to lead. So they give us lots of decesions to take by ourselves. And that's why I asked this question here.
    – Léa Mendes Da Silva
    Commented Oct 30, 2015 at 7:30
  • 1
    @DA01It's more accurate to say that we aren't the decision makers than to say that we don't get a vote -- our opinions are taken seriously and we are allowed to contribute, but if the designers say "No, this is how it is" we defer to them and accept it.
    – asfallows
    Commented Oct 30, 2015 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.