10 Learnings in 10 Years (Part 2)

10 Learnings in 10 Years (Part 2)

 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)

Continue to Part 3