Reflections as I Transition From Software Development to UX Design
In my limited amount of time in the professional world, I have had the opportunity to get a taste in both software development and user experience(UX) design. I came to notice the differences and connections between the two fields, and I’d like to share some of my personal observations.
When switching from development to design, the first mindset change for me was an examination of one’s own knowledge, or sense of “expertise” in one’s field. When you are a developer, you, hopefully, know your product better than anyone else. You strive to make your product robust and efficient. Solved 835 dependency issues? Read through all those unreadable API documents? Impressive. You may feel proud of yourself, and it’s okay to brag.
In design, however, I am forced to see beyond myself. “You are not designing for yourself” is probably the first thing one will learn when stepping into the design world, and I have been repeatedly reminded of it. One might think she knows what should go into the product, but that’s almost never true.
I have lost counts of how many times before I walked into an interview or a testing session with a user, that I felt so confident about how my product was well-thought-out, only to be proved wrong later. I quickly learned that I can never know enough about my users as they do themselves. Each time, I left the session feeling humbled and deeply appreciative of things the users have shared with me, good or bad, explicitly or implicitly. It is an experience that I hoped I have had more when I was doing development work.
Another significant shift is the matrix for success. In development, the passing criterion is rather straightforward: if you have considered all edge cases, handled all exceptions, and driven down your run time to a small enough number, you could quite confidently say that you have finished it. Sure, you have bugs to fix later, ways to optimize the performance, but even those are relatively well defined. When it is working, you know it is working. The code, the number, is your judge.
But in design, things are less clear-cut. There certainly are quantitative rubrics to judge the success rates of some aspects of design, yet the rest still remains subjective: What if I phrase a question in another way? What if I give the user one more task to finish? What if I use a different navigation? What if I ask for users’ credit card information before they have entered their email address? What if…. Because of the endless “what if”s, I often feel like I am never completely done with a piece of design. Further, whenever you roll out something, you get feedback. And then you can’t help but go ahead to fix them and roll out a new version. Perhaps this is also why they say that a designer’s portfolio is never finished — there is always something new you can improve. Although this also rings true for developers regarding getting feedback from shipping a product, the need to iterate seems more pressing when I am designing.
Lastly, user-centered design takes more time — more time that is out of your control, I should clarify. I am not saying development is easy or takes less work. It is not, as anyone who has taken Software Development 101 can testify. What I meant is that the progress of the development depends more on the developer than outside factors.
This was another thing I needed to wrap my head around during the transition. A developer can work when he is the most productive. But designers need to work with users. Designers accommodate users’ needs. Surprise.
To be frank, this wouldn’t be a surprise to me had I not come from a software development background. Software development, or the Internet business, is a field that is known for its fast pace: you can “hack” things together: or making MVPs, like some would call it. A caffeinated developer can stay up two nights straight and hack a usable product. The velocity is more predictable.
But design, in a user-centered fashion, is constantly engaging with users. The nature of user-centered design indicates that the designer is not in complete control of everything. Much more is up to something else, and often someone else. For example, interviewing users takes time. A/B testing takes time. Recruitment of participants takes time. Having a nicely distributed demographic of target users fill out your survey takes time. Making your team buy in “Pamela-the-persona” takes time. Etcetera etcetera. You can’t just interview people at 3 a.m. in your garage(unless you are talking with users in another time zone, which is another story on its own). You cannot collect enough data to observe users’ behavior patterns overnight. You certainly can’t obtain meaningful research insights in a blink. Fortunately, more and more teams are adopting the Agile approach in their design, and I believe this will bring exciting changes to how design is done.
There are many more things I can ramble on: the teamwork, the communities, fashion choices(just kidding☺) that I observed from the development and design worlds. But I’ll pause for now. No doubt, both domains are powerful, influential, and challenging in their own ways, and I feel incredibly fortunate to be able to get immersed in both.
Like I said at the beginning, these are documentation about my own experience moving from development to UXD, and I am far from being an expert in either field. In a few years or even months, I might look back and find my findings above utterly naïve and short-sighted. I might and probably will laugh at my “insights”, but hey, isn’t that how one grows and matures?
I’d love to hear what you think, regardless of what background you are from!☺
