Two simple actions that offer lasting design integration within organizations
Originally published at uxgravy.com on 20 Nov 2018
At the height of dotcom in 2000, I had my first opportunity to recruit and build a design team at Infosys. Hubris led me to place design on a privileged pedestal. Arrogance was part of the potent mix. We used to joke “here comes another JIP job.” JIP expands to ‘Jazz-it-up’, the most common phrasing of a new design task. Jip was also our get-back-at-them slur given the popular file compression term in a local accent substituting J for Z. Sardonic design team humour apart, strictly transactional nature of collaboration turned the shortlived design act and came to a cropper.
My failure was masked by more seismic business events like the bankruptcy of Webvan and countless other dotcom wunderkind crashes. Unfazed though, growth for Infosys was starting to kick in from the enterprise side as several legacy solutions based on mainframes like AS400 or the thick client, middleware based software started leaning onto browser-based applications for captive audiences that power Intranet traffic or as a new channel. I was presented with a second chance.
2001 — A legacy client of the too big to fail kind was being pitched to and here I was onsite consulting along with a mix of specializations and experience — architects, program managers, business analysts, engineers, developers and variations of these. All these diverse experts along with me would hold conversations with client representatives. I observed that the storyteller was the same. Their story and script mostly same barring few details. However, each of us on Infosys team took away a different story. The business analyst — business processes and SLAs, engineers — performance and non-functional requirements, architects — nature of infrastructure, currently deployed stack details, and I, about the users of the legacy system.
What struck me is the sheer waste of time for the client, repeating themselves. I was convinced there was a better way of managing requirements in a multi-disciplinary setting. And that would be to model requirements visually using Vizio like tools and UML compliant symbols.
Back at Bangalore, I worked with several internal teams responsible for process and quality. Initial conversations would go like “What? There are overlapping goals? You mean you too capture requirements? Well, unfortunately, we didn’t plan for it! Can you work with the use cases instead?“
Soon with examples and doggedness managed to convince the multi-disciplinary team to view design not as jazz, but as a process! Showed them a design process. Aligned it with IT’s core process. Yes! SDLC or software development lifecycle — waterfall method, used at that time aided by CMM maturity assessments to plan, track and deliver quality software.
Soon with examples and doggedness managed to convince the multi-disciplinary team to view design not as jazz, but as a process! Showed them a design process. Aligned it with IT’s core process. Yes! SDLC or software development lifecycle — waterfall method, used at that time aided by CMM maturity assessments to plan, track and deliver quality software.
Soon with examples and doggedness, managed to convince the multi-disciplinary team to view design not as jazz, but as a process! Showed them a design process. Aligned it with IT’s core process. Yes! SDLC or software development lifecycle — waterfall method, used at that time aided by CMM maturity assessments to plan, track and deliver quality software.
Soon we had a patent pending software requirements capture framework called Influx.
Key innovation here was when we managed to tell each of us diverse experts that the detail each is interested in stems from the same story but differs in granularity. Our breakthrough was in respecting these differences and nesting them — business workflows breakdown into more granular task flows such that a business function such as user authentication could break down into a user navigating through a bunch of screens, and each screen breaks down into performance engineering requirements on validations, server response times etc. All beautifully nested in a single diagram with multiple levels of zoom. In fact, it inspired me to present this vision to management by layering it on the fascinating film by American Design guru Charles Eames titled ‘The Powers of Ten‘ (sponsored by IBM). As a primary contributor, I attribute the success to the mantra ‘Align and Integrate‘ — the theme of this post.
Align and Integrate worked here at the process level. What I did was to first convince members that design is not a black box activity but an explicit process that lends itself to planning and managing. Next, I examined the classic design process of understanding users, tasks, explore design solutions and prototype both layouts and flows, visual design, high fidelity prototyping and user testing/validation. With these steps, I cut the process up into well-contained steps/design activities and aligned them with the other core processes defined in software engineering. Alignment was based on when to execute best, in which context or location, with whose inputs, with what outputs, and other dependencies. Note that most projects followed the waterfall model. Agile manifesto was being drafted at the same time at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah. Rational and OO architectures were the flavour. With the well-aligned tasks representing multiple domains, next, we examined the quality goals and efficiencies. It was obvious that even within certain aligned tasks, there were opportunities to integrate them to better represent and capture. One example is in how workflows were captured as a sequence of actor actions in a use case, and also as a set of visible, tangible actions where the actor is a human user, represented in swimlanes above the line of visibility. Integrating these ensured better collaboration and holistic requirements.
At another too big to fail bank, my design team saw the challenge that when stakeholders were presented usecases as ordered lists of text items, they were dense to read and comprehend, resulting in approval delays. With a better-aligned design integration, we were able to present the same for approvals visually as a prototype. To bankers, this was more exciting and elicited significantly better participation. We all know that a picture represents a thousand words, right! Lesser cognitive load in some sense.
Now, that we could model requirements for design upfront, it proved to be a viable tool to not just capture design requirements, but as a tool to discover business requirements. I continued to help improve the Influx tool. The next step was to have the tool generate the English language text of the usecases. This clearly showed the dual nature of requirements — in discussions and at elicitation it was visual, but below the hood, it was XML. Post elicitation, for software engineering, it was a well defined, structured UML compliant requirements document, generated from the underlying data.
Align and Integrate at the process level worked fine. My team's effort was recognized with Infosys Chairmans Excellence award in 2002.
As a designer, I continued to build on this process foundation. I extended the Align and integrate principle to resources and staffing. Here I have a confession to make. Designers are not easy to manage. Perhaps its the nature of work and talent. A leading Boston designer who worked on MasterLock redesign said their team size sweet spot is 20. Beyond that it becomes unmanageable. Perhaps why design companies don't scale their services like software service providers. At Infosys, I realized staffing the exponential demand for UI design across projects is huge. For designers to align well with the teams, we need to have them fit well into the base organization structure. I worked with top management to create new roles in our recently acquired SAP HR system. I used their structure to define career path and performance appraisal criteria. Compensation was pegged in line for the value that design brings to the table, plus bearing the supply of talent constraints. New hires were trained on our unique design processes and artefacts that were integrated within the overall software engineering frameworks. This ensured designers as a team remained well-aligned and integrated within the overall organization. Where the first attempt of a JIP service failed at a single digit, the new approach has scaled very smartly to hundreds of designers, and the number is only growing.
To be continued…
