Post written by Nazia Hasan (https://twitter.com/NazarahTheCat).
Before jumping deeper into this “highly philosophical” title, on which we can have hours long argument with bottles of beers, I want to tell a little back story.
What is the Big Catch?
I came to Finland on 2014 with the intention of gaining my Masters’ Degree. Coming from a Software Quality Assurance (SQA) background, I decided to choose User Experience as my major. My work in back in Bangladesh did not leave many opportunities to directly interact with people who were “The Real users” of the services we were implementing, testing and delivering. There was no doubt ensuring the “YES” answer to these 2 traditional questions “Are we making the product right?” and “Are we making the right product?”, but my inner me insisted “Go and talk to people, know their stories”. I am glad I followed my instinct to develop a new career path for me. Besides User Experience was gaining the much awaited recognition more and more as companies started to comprehend its importance in achieving their business goals and the Scandinavia seemed to be thee breeding ground. A major part of our studies required we work on final projects proposed or sent to the faculty by different Finnish Businesses. Studying in a traditional university which focuses more on research related activities, naturally I grew a different perspective on how UX should work. There is no shame to admitting I was arrogant about following the “books’ sayings ”as my “Quran”, thinking books are written based on research and validations so then can’t be wrong.
Image Source: Visually
What did I do Wrong
I forgot on my own that researches can get old and could be done in conditions maintaining many constraints and considering limited time and resource allocations. I was focusing on taking user interviews, gathering research data, making user personas, creating user flows, designing wireframes or even a single UI view of an app intended for smartphone. But in doing so, I often chose to ignore the other half of the coin - The actual implementation work. I did not address one significant element - DX or to be precise, Developers’ Experience. In My defence, I did not yet do experiments with field level applications of technology we use to build good user experience. I was yet to work side by side with a development team, employed in a company or startup, working to implement a new service or technology that would bring value to people and the organisation. Like a newbie UX designer, I was more interested in developing out-of-the-box UI elements or interactions to make sure the target customers and end-users finds our services “exciting” and of “a new experience”. I wanted to ignore style-guides developed by Bootstrap thinking they are too boring to work with.
Since 2016 I have worked in 2 different workplaces which helped me remedy my erroneous judgement. Probably I could have done better, or someone reading my experience might contradict my thoughts. But things started to become easier when I started to treat my development team as intrinsic stakeholders for the service I was working with. Developers are indeed a very special kind of creature, who needs pampering and the feeling that their advices and opinions are actually being valued and taken into account. If your company’s core business involves service generation for mass population, presenting counter logics in favour of your concept might be easier and even convincing to the developers, considering they will not eventually be the intended target users. You have your demography data, user data on their limitations and expectations on solving problems, possible use-cases, etc. But things take a totally different turn when your intended service would be used by app developers, core developers and system architects. User Experience turns into Developer Experience.
Designed by katemangostar / Freepik
My past three years have been spent in designing services or systems that are heavily intended for developers. From my known associates in User Experience field, from university or other workplaces, I have often heard them complaining that the implementation teams are often clueless about what we do and has an accusation about us being too impractical when proposing a new design, App page or a simple UI element like a menu. It is very possible that in order to align people’s vision of a service experience as our own, we tend to unconsciously ignore technical possibilities, limitations and resources at our hand - in 2 word: “Developers’ Expertise” from the team itself. For designing great experience, if we need to put one foot in the users’ shoe, then we need to put the other foot into the developers’ one. Here, the core development team of your team could be your greatest allies. They can give you the wisdom, knowledge and experience which is difficult to comprehend unless you are a developer yourself. The job of identifying common usage patterns becomes easier when you compare information shared by your internal development team and experiences observed by 3rd party developers. This hypothetical battle ground that we UX designers tend to maintain against the “developers”, this could become a playground for everyone who mutually aim to create the proposed business value for an organisation. Just a little change in work and attitude. And as the mediators, UX designers should come forward and take the initiatives.
My Own Takeouts
So for my own case, what did I do? Here is a list:
1. Study the Intended Business Value
And I don’t mean only the product the end users would get. Before jumping into planning for user research or making a simply home page, it is important for me to understand the vision behind an intended service. The initial customer scenarios, often brought by product-owners or managers, are intercepted by developers into use-cases. Core features and technology used (or to be used) rotates around the primary use-cases. So studying and understanding them help me out in future to evolve the experience that would be observed by the end users. I didn’t comprehend word meaning by meaning, and honestly did not try to. But it helped me easier to approach developers with questions when I had some know-hows.
2. Ask, ask and ASK
In the beginning I often used to hesitate thinking if I am asking something silly. If something I can’t understand is obvious to everyone. A lot of people reaches into the same situation as I do. Usually our professors teach this thing into the university that “No question is silly question”, so We need to also integrate this ideology in our working pattern. If dig deeper, developers are usually kind hearted, but misunderstood creatures! :D Yes, they have tons of things to do at their hand and their brains plan at least 5 things at a time! So whatever I need to ask, I always write them down into clear questions in a paper. If I find something on which you have doubts or own arguments, I write them down side by side in shorthands. It helps me to be well prepared and not wasting anyone’s time to correctly phrase sentences.
3. Make developers inclusive of your work
The final decision is always mine to take, but I seek out opinions from developers about an upcoming UI and UX concepts I am working on. It doesn’t have to be every single developer from the team. When I design the logic of an intended feature over a wireframe, I evaluate it with the system architect or backend developer to validate the flow of actions. This validation is especially needed when you are designing something intended for developers. Developers can help out from verifying input conditions to a simple feedback message with better intuition. At present, I am jointly working with one of the front-end developers to design basic UI elements to be used across different services and we are partners in crime. ;) I review initial design specs in Figma or Codepen with him and he evaluates them from technical perspective. I gave him the choice of selecting the initial style guides fro either Bootstrap or Material UI and his selection made my life easier in customising the elements representing our brand values. We may nag sometime, with silly stuffs from both ends, but it never was a big problem to reach out a common decision. Not to mention, I have a great teammate who is supportive and encouraging. :)
4. Be humble
My partner always says that the more knowledge you gain, the more humble you should be. And knowledge acquisition in a never-ending process. I take this note from a different angle. I admit to the fact that I will not understand every single technical jargons and their intended purpose. So in my discussion, I try to phrase my words in a way so that it doesn’t sound me mocking someone or making me appear as an ass. :P “Can you please explain…”, “Please correct me if I am wrong…”, “My apologies, but I am having difficulties…” etc. makes a big differences. You are making yourself humble when seeking out helps. And not only developers, but also most people would appreciate this approach. Even straight-forwardness could be expressed in humble tone. May be this is not at all Finnish, but this is my way to avoid the high way! :D
5. If need - seek out help
We are not mentally designed to fine tune with everyone. So there are high possibilities of clashes with developers in opinions and perspectives. For me, sometimes tones and judgements have been sounded rude. Could be my fault or the other side’s. But if something is bothering me, I seek helps from none other than the Product Owners (PO). They are people with experience and knowledge to keep the product in check and maintain truce in all stakeholders. I have two awesome POs with whom I work close by. If I have a question about the product or the company I go to them. If I am feeling low and exhausted from a heated discussion, I seek help from them. It helps me not only to restore my inner peace, but also to find out errors in my own judgements.
Designed by rawpixel.com / Freepik
Last few words after such long venting…
How have things turned out for me? I’d say things are good. There are small frictions now and then, but dealing them is part of my growing up and learning new things. Would my checklist work out for all? I don’t know and I can’t guarantee. Circumstances are always different for different persons, so people adopts unique strategies to make favourable working environment. I didn’t feel talking about our own jobs as UX designer, because I don’t need to advise people who are already talented and efficient in our fields. Someone wants to object in my thinking. Be my guest. After all, “100DaysOfDX is solely based on personal opinions!”” :D
and we can coexist by agreeing to disagree! :D
Some more to read from 100 Days DX
- #100 - The biggest open resource on Developer eXperience so far
- #99 - Hackers - the top 1% of engineers
- #98 - Invalid Open API spec files ruins the developer experience
- #97 - Lightweight API evaluation framework
- #96 - Embracing open source community driven tools development
- #95 - Exploring the multilevel nature of API Design Guides
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!