10 learnings in 10 years
That help UX designers in making sure that UX is done right by the developers
I have been designing digital experiences for almost a decade now. A large part of that required working closely with developers to make sure that the intended vision and user experience eventually reflects in the final product. During these years, I worked with different developers that possess almost all levels of expertise, right from entry level fresh graduates to super senior rockstar coders. Not only that, I have been fortunate to have worked with developers from diverse cultural backgrounds and geographical regions (makes you wonder how is this relevant, doesn’t it?).
My journey of teaming up (or designing) with developers started in the summer of 2006 while working with Mads Clausen Institute of University of Southern Denmark during my undergrad internship. While I was designing user interface concepts for an application that is used by field technicians to configure supermarket refrigeration sites, I had to continually understand and investigate aspects such as feasibility and how well UX is understood by the software developers (majority Danish). Some unlikely design concepts at the beginning of the engagement produced learnings that led the way towards a few successful designs in the end.
User testing session with engineers at a refrigeration site (Denmark, 2006)
Fast forwarding to few years in full-time employment. At SAS Institute, I got the opportunity to work quite closely with American, Chinese and Indian developers while designing a range of industry-leading software solutions in the realm of business analytics and intelligence. A large part of this engagement at SAS was on remote basis which presented some exciting challenges to tackle. With the team in Beijing (China), trials got even more interesting when communication aspects played a significant role. The question is how do you communicate design if ‘design’ is the only language you can use for communication?
UX workshop with development teams in Beijing, 2013
In my current job (with HUED, a leading Innovation and Design consulting firm based in Riyadh, Saudi Arabia), I have had the opportunity to work with developers from different parts of the Arab world (Egypt, Jordan, Saudi Arabia to name a few). It’s been a remarkably exciting journey so far with many takeaways worth sharing.
Over the years, as a designer and as an eager beaver, I could manage to learn enough ways to overcome cultural, lingual and lack of general UX know-how related challenges. Some of these novel methods practiced during the engagement yielded positive results while others failed.
In this article, I have tried to sum up all the decade-long experience of working with developers from extremely varied backgrounds in 10 key learnings ordered chronologically.
1. Interactions must be thoughtfully “designed”
Web app development team, India
10 years back, the idea that all possible user interactions can be designed without writing a single line of code was evolving.
I was already into almost a year of working with tech team of Brijj.com, back then a community based professional networking portal trying to compete with rival entrant in the Indian market, Linkedin.com.
Let’s talk about interactions now. A common misconception about interactions is that developers can tacitly understand the functioning by merely looking at how “static screens” are linked. Back then the idea that a single page can have several states and technologies like AJAX can help designers conceive creative state-based, in-page interactions was somewhat coming to existence. Even today, not many designers are on board with the idea that every little nuance that goes “undesigned” hence “unSPECed” leaves enough room for the tech guy to misinterpret expected behavior. I realized the value behind all the blood and sweat that went into designing every possible interaction in the “UX” phase. Soon, the tech team found themeselves talking to different product divisions and evangelizing the importance behind thoughtful IxD.
Snapshot of interactive prototype of professional networking portal mentioned above (2007)
2. Coding logic is as much a designer’s game as a developer’s (2009)
Enterprise platform development teams in India
Writing code is a fraction of any puzzle-solving, that occurs only towards the end.
Designing complex platform-level tools and sub-systems that do not necessarily qualify to be referred an end-user experience on their own could require a lot more use of the left brain than one may imagine. These sub-systems are often part of the holistic enterprise level app experience. The challenge here is most of the functioning of these sub-systems is left for the product team to imagine, make calculated guesses and inform thinking via second hand, tacit sources since technically there would be no end user of these components.
So when it comes to “imagining” rather complex scenarios of how the end user might experience with this particular component or a sub-system, in a holistic app experience, UXers should find themselves as much abled as the rest of the tech team. In one such project (design of a “Software Bugs Tracking and Reporting System”), I got the opportunity to get myself involved in initial if/else and all sorts of analysis much much before discussion for possible user interface started. Those early “logic” discovery sessions turned out to be a tremendously fulfilling experience. Which made me realize that the habit of always thinking about the end user that designers cultivate over the years makes them analytically very strong to discover patterns that sometimes tech team may not find instantly capable of.
3. Hangout with the developers more often than not. Even better, move your work desk closer to theirs (2010)
Enterprise apps development team in the US
Engineering teams turn your vision into something that people eventually benefit from and draw satisfaction from, the end goal that you care about most.
In 10 years I have experienced all sorts of team distributions. Most of my years in SAS were spend sitting close to different functions (dev, test, PM and so on), notably closer to the dev team. These years made me realize that several-times-a-day sneak peeks of dev team members’ desks and vice-versa could be a guaranteed recipe for a successful “meeting UX standards” product. Simply witnessing how a dev guy’s “coding canvas” turns your vision into a functional product could lead to many different ideas on what you can do to help him understand the ins and outs of your design solution.
4. Good UX does not emerge out of hatred for legacy systems; it arises out of carefully understanding 5W1H of legacy (2011)
cross-functional teams located in various locations (US, Europe, India)
You may find that most legacy systems have been “designed” by revered engineering vets in your organization. The validity of this statement largely depends on one’s definition of legacy.
For the purpose of this article, any software that got shipped to the market in the mid-1990s or earlier can be referred as the legacy, largely because UX design was being brought to broader notice around that time. In my years of designing B2B apps and platform components, I have often run into situations in which carefully designed interfaces with the promise of good user experience demanded legacy code to be re-written.
What would you do if your new designs need a legacy system to be completely rewritten, which was originally coded by the CEO or a co-founder of your company?
You could start by digging into everything that legacy has to inform. Understand what has been relevant for years is still relevant or not? Then all your energies could go into finding stories of today and how end users may perceive that their true intents may have been compromised by clinging on to the legacy. Telling these informed stories of users’ continued pain to product stakeholders might just do the trick.
The mockup here is an example of how legacy informed design thinking. What appears here as a simple search app required legacy code which was originally written in the early 90s to be rewritten. (parts of UI have been altered to not reveal any IP)
5. Before your designs go into development cycle, make sure you do rigorous reviews with Product Manager, Development Lead, Testing Lead, a representative User, possibly one from customer support, Agile Project management lead, all in one room (2012)
industry-specific B2B apps development team in the US
No brainer? Well yes, it is. But it often takes more than one may imagine. It requires a bit of skill development to carry out successful validation sessions with all the perspectives being in one room.
One of the underlying principles of Agile UX is runtime thinking. Runtime judgment is one crucial aspect that UX community does not seem to have written much about. In a typical agile development cycle, a UXer may get between 2-3 weeks of time before designs are pushed in the development sprint. To make the best of these short sprints, one often needs to bank on the previously acquired understanding of user behaviors and anticipate intentions while canvas is being UIed.
Segwaying into something not entirely related but here is one of the examples of runtime design judgment that was made while designing interfaces for a predictive analytics based Oil and Gas industry solution.
We needed to plot different data streams for maintenance engineers to be able to identify various sensors emitting corresponding data. Using color could have been a no-brainer solution. Well, It could not have been if you are dealing with 10 different data streams that needed be plotted together. We know enough from various cognitive studies that humans have difficulty in processing more than 5 distinct colors if they are all representing 5 different things. The context in which maintenance engineers in Gas fields operate is even more difficult. While UI is in the making, these runtime + judgment + acquired learning based decisions that one would make help in being truly agile.
Coming back to the topic of learning, I am a firm believer and practitioner of the idea that UX not only needs to be agile, UXers can also lead rest of the team in a way that puts team energy and skills to optimal use.
All stakeholders-review session or design concepts for a refrigeration mechanics software, Denmark 2006
Snapshot of “10 different data streams UI challenge” mentioned above
6. Design specs are meaningless unless those are substantiated by relevant and engaging stories from users’ context (2013)
a cross-functional team in Bangkok
Often designers think that developers do not exclusively care about why something is designed in a particular way. They could be so wrong about it.
Developers do care about the stories from the user’s context just as much as the designer would. There is more and more need for designers to find more engaging ways of putting the specs together. Most critical UI decisions have a compelling story to tell, more often than not. What if we, as UXers, attempt, go that extra mile and juxtapose stories with UI solutions. In a similar effort, stories of what we observed, what users said etc. in several discovery sessions with Risk Analysts (end users) while designing an enterprise solution in the Banking domain, were presented with the initial UI solutions in the form of an engaging app-like experience that developers enjoyed referring to. Stories not only help in substantiating design decisions with reason and rationale but often give a much-needed break from the complex, analytical life of a developer.
An app like interactive digest of all the relevant stories captured during discovery sessions with Risk Analysts in Bangkok, 2013
7. Video demos with voice-over and contextual annotations could be compelling design documentation that most developers would love to engage with (2014)
enterprise platform developers in Beijing, China
Allan Paivio, a psychologist, hypothesized Dual Coding theory in 1971. In a nutshell, theory suggests that recognition and learning could be significantly enhanced by presenting new information in both visual and verbal form.
This is one theory that designers often successfully apply in the design of interfaces. The principle is just as much applicable in UI design as it is in case of design documentation that gets passed on to dev and other product teams. For several years now, I have relied less on verbal-only form of documentation. Although I am always on a lookout for novel and more engaging ways of doing just about anything, this alternate method of documenting design solutions mostly started with development teams in Beijing (primarily Chinese with a modicum of English skills). To be fair, I know Chinese as much as I know Greek. It was all the more responsibility on me to make sure that I do everything that helps them understand the vision.
My early experiments with interactive video demos supported by voice-over and contextual annotations turned out to be a great way of communicating just about everything I wanted in a given UI prototype. This practice instantly became a hit in the design group I was part of. Documenting design solutions in interactive video formats not only gave my Chinese colleagues an opportunity to be familiar with the solution in a much more engaging way, but I could feel a noticeable difference in their “more confident”, “more aware” presence in weekly review meetings.
Example of design documentation portal setup for remote development teams. Portal had interactive video demos, UX notes, mockups, review comments all in one place (Beijing 2014/15)
8. Don’t detest coding. Embrace it. At least be aware of possibilities (2015)
cross-functional teams in KSA
Making delightful and relevant experiences happen is often an arduous journey, full of challenges for which designers may not always have a perfect solution.
For the most part of my commercial endeavors in the realm of UX design, I worked with product organizations that have very dedicated core engineering teams with a clear understanding of what is waiting for them in the coming sprints. During this time, I was not particularly required to practice a fair bit of coding that I learned during my academics.
In March 2015, I moved to KSA to take up a consulting role that till today requires more and more efforts into making delightful experiences happen. “Making delightful and relevant experiences happen” is often an arduous journey, full of challenges for which designers may not always have a perfect solution. Embracing engineering mindset helps to a great extent. Easier said than done for those who have zero background in coding beautifully designed solutions. But isn’t everything in the world is? I consider myself a bit fortunate there, having studied in a partly engineering-led design undergraduate. Regardless, one needs to put him/herself in the shoes of a developer more often in the never-satiating quest to discover technological possibilities.
All it takes is some sincere start; there is no better satisfaction for a designer to witness end users realizing satisfaction and delight, a result of flawlessly engineered solutions.
9. No amount of hard work put in careful documentation of UX design solutions will ever be enough (2016)
various development teams (Egypt, India, KSA, Jordan)
Don’t get me wrong. Discouragement is not the message here. As a designer, the idea here is to stay on your toes, never rest even after you may get clues that your job is done. Your job is never done.
We tend to set the bar as high as possible when it comes to “designing” solutions that are utterly relevant for the end users. We often give priority to “meaning” over immediate technological feasibility. Most often this helps us push technological boundaries, in any given context. While development teams try to give their best in making designs happen, there is a higher likelihood of gaps occurrence owing to the fact that at design stage the bar was set higher than what is immediately feasible, in the given time, resources and with skills in practice.
Let’s understand more with an example. Back in late 2015, and early 2016, I designed an AR utility in a productivity app (iOS) that allows a high ranking minister to be able to control many facets of his demanding schedule. The utility allows ministers’ protocol team member to visualize and create table plan by using the device camera. As the camera is on, he/she could see how the app would recognize tables and chairs, and some basic shapes which would help in creating an outlinish layout by simply taking a photo of an empty meeting room. To be honest, I was not even sure if I could have called it AR back then since the technology was emerging (still is).
Control Panel table plan AR utility
Developing this utility turned out to be a challenge then and remains that way even today in the latest release of the app, we could not develop it the way we wanted. Detailed documentation and thorough research of immediate technological possibilities helped to a great extent. Closing gaps will remain a pursuit for most designers unless of course one is surrounded by exceptional engineering teams who do not need a designer to think about near future possibilities, which I would consider a privilege most teams are not blessed with.
Robust library of in-depth Control Panel ( iOS app) interaction design explainer videos for development, product and QA teams
10. You (as a UXer) are the ultimate QA of meaningful experiences that your designs bring forth (2017)
various development teams (Egypt, India, KSA)
Unspoken, often undocumented nitty-gritty of conceived experience can only be entirely QAed by the one who designed it. In layman terms, the difference between functional and experience testing.
A large part of my team’s 2017 has gone into QAing apps and solutions in various stages of development. In all cases, the core QA team had several difficulties testing experiential side of these digital solutions. We often received builds that might have gone through a good amount of functional testing, but a lot of times we felt that outcomes are not bringing forth the experience as it was conceived during the design phase.
Getting users’ tasks done is not enough. Getting their tasks done and leaving them with the desire to come back is often the goal. The ‘desire’ part of user interaction needs to be validated through rigorous experiential testing that UXers specialize in.
Experience testing (of app builds shared by the development team) being conducted by the UX team, KSA 2017
