Is the Design Process slow, and is it held to a different standard in terms of efficiency?

One of the questions a Designer invariably hears during an interview process, particularly when showcasing a case study, pertains to the duration of the solutioning endeavor they have just showcased. That question invariably also comes up when strategizing anything that pertains to Design Tasks/Activities/Operations. And it makes all the sense in the world. Anyone in Product Ownership related discipline or those affiliated with Development, need to be aware of the time it takes to go through Research, Ideation, Iteration, before the subsequent steps of the Design Thinking process can occur (this impacts sales strategies, go to market strategies, communication outreach, just to name but a few tasks). And while what I just described may seem a Waterfall process, it actually is not. Design tasks can occur concurrently with development and each feed off each other (hello, Agile), but essentially understanding how long does the entire cycle last is fundamental to better define roadmaps, establish client expectations, and forecast costs and revenue (timeliness of any endeavor is tied with the availability of resources, materials, and of course, of monetary investment). For the sake of this article and for the sake of being succinct, here’s what I’ve observed and learnt from all my years in working in software design and releasing multiple products to market.

Each Case is its own case. As much as a Designer can attempt to illustrate the most realistic path of how a project will be accomplished in a certain amount of time, there are factors that are beyond their control, and that invariably permeate into the Design process itself. The first substantial software project I was involved in, was a multi-year endeavor that was already in motion when I joined the team. It had been a substantial investment of the organization for years (at the time 2 years), who had decided to channel considerable resources into that initiative. That initiative was a calculated yet risky investment from leadership, and the controlling group of the organization. They envisioned that solution as a game changer for the organization, something that would expand their brand positioning and their innovative stance on the market, alongside bringing a whole new set of adopters to that particular product. The timeline had been extended several times and the cost had been raised substantially as a result of those fluctuating timelines. And these adjustments occurred beyond Design related situations (there were many technical/technological issues to be resolved as well), though much time had been devoted to usability testing, localization, omni-channel experiences, partnerships, content creation, onboarding experiences, gamification scenarios, and the list goes on. Suffice to say, there was fear that the investment had been excessive. As it turns out, all the research that had been done was pertinent and substantiated the path the teams had been going on. Upon release, the adoption was colossal, and the product was an enormous sales success. A lesson to take from a situation such as this one is tied to understanding the value proposition, the business case that was crafted, and what the research continuously proved about what was being built, and refined during the Design process. There was a desire for such a solution, and the path ahead was a sensical one.

Each Team behaves differently. Another application that I worked on, had the premise of reshaping a previously existing solution, and bringing that legacy product to a state that met new needs that had been uncovered as a result of continuous research (and analytics). The clients were clamoring for something mobile and in tune with how they actually worked, as opposed to a solution that was locked in a desktop type of experience. This solutioning endeavor was executed in 4 months, which included all Design work/research (workshops, iterative cycles, refinements, flows, wireframes, prototypes, visual design), development, and go to market strategy. It was accomplished by a deeply committed team, where representatives of various groups made this endeavor a priority for what they were aiming to fulfill on their roadmap. What does a “deeply committed team” actually means? It means people participated in daily workshops, in all usability testing sessions, in reviewing elements for sprints that the development team had set in motion. Summarily, everyone was an active voice in the Design process, and not tourists along for the ride (or the occasional passers by). There were challenges in the development cycle, with the need for some up-skilling of some professionals responsible for the front-end development to occur, but overall it was a product that upon its release, met and surpassed client expectations (and became a case study on how to build something efficiently and with a rather minimal team). One lesson to take from a situation such as this, lies with the participation level that is expected from all partners on the process. The Design process is only as effective as it is a convergence of many interested parties and groups. Once again, it’s not Design by committee — it’s imbuing data and observations into something that will become a solution to be morphed by testing and by iterating. Otherwise, what eventually happens are teams producing output for themselves and not for clients (or acting under the illusion they know what a client wants, without interacting with said client).

Each Case requires flexibility. Another redesign endeavor I was a part of also had an initial timeline of 3 months for all its Design cycle to be completed. There was latitude in this case to do so, since the development team that was assigned to this endeavor, would only be available after a certain timeline. All activities were mapped out to meet the beginning of a more formal and structured development sprint cycle. During the 3 months of that Design cycle the workshops and working sessions were not conducted on a daily basis, but instead on a twice a week basis due to time constraints from the teams involved. All the ideation and iterative cycles occurred, but lo and behold, during the process new requirements came into play, ones that had a substantial impact to the application (its architecture, interaction and overall experience). Similarly, early feedback from prototypes and usability testing conducted with clients indicated the need to refine what had been constructed thus far. This shift in direction was discussed amongst the participants of the process, and the new deliverables and testing occurred in a prompt manner, in order not to undermine the original timeline. The new testing provided the reassurance needed, as it delivered over 95% certainty of the direction in which the solution was headed for. The lesson for a situation such as this is that the marriage between timelines and what you learn during the Design process has to take into consideration flexibility. Teams have to be able to be limber and flexible: their ability to learn during the process, is one of the aspects of Agility, of better understanding the problem, the clients, and what the business can effectively support.

The Design Process and the efficiency standards. For companies who operate with a low level maturity from a Design perspective, anything that goes beyond what they know, it is always puzzling, and even more so, something to fear because of what it will entail from a cost perspective. Engineering, much like John Maeda opined in a communication I heard earlier this year, is easier to translate in terms of ROI (number of stories finalized and tracked in JIRA that can be tracked in exacting terms). However, and this is where the crux of Design Centric Philosophies and Human Centered Design comes to play, as much of a cliché as it may be, this eternal question “Are we building the right thing?”, comes into play and shatters much of the certainty that all engineering and JIRA stories can document. Because for all the stories that can be written, for all the efficiencies that can be set in motion in making sure Developers have what they need to build the “right product”, if you’re not actually hearing your clients, and satisfying them on a holistic level, then what are you doing, and who are you serving? Much like adopting a culture of Innovation, organizations have to decide on what they want to invest and ultimately take a stand on what you want to do and be or you’ll never have substantial gains. Much like a vegetarian who still wants to eat meat, considerable decisions and investment have to be made, in order to truly commit to what a journey actually is, one that includes adopting Design in a meaningful way.

Reality check. I could expand on multiple other examples of applications myself and the teams I’ve worked with released to market and how timelines were more or less dilated, depending on: stakeholder participation, funding of the initiative, go to market strategy, overall roadmaps, and in some situations, vendor/partner availability. Oh and as a side note, I once heard someone from a Product discipline state “we had to work long hours during the week and weekends in order to assure a project met the deadline/timeline that was established prior to us joining the process”. Professionals who utter those words are usually oblivious to the reality that other teams, and I’ll address Design ones in particular, have had to do the same in order to also meet their timelines, typically as a result of learnings from clients, additional requirements, changes in priorities, whatever the case may be. And while I firmly believe in work-life balance, at times everyone has had to be flexible, and that has included working extra unexpected hours. Being tone-deaf towards other teams’ efforts only reflects poorly on yourself, and it’s ultimately detrimental to the actual Design process. What makes all the examples I listed above meaningful ones, wasn’t just the fact that the products released were indeed successful and pierced their problem statement substantially and with plenty of rewards. It was the fact that everyone participated, made the Design process what it’s meant to be: shared, insightful, and multi-disciplinary. Ah and toxicity was left at the door. If you have to take something from this article keep this in mind: establish Design Strategy, be flexible, demand participation, and escort toxicity out (I’ve written about toxicity here).

I’ll conclude this article with a quote on the topic of perseverance, from Bill Bradley:

“Ambition is the path to success. Persistence is the vehicle you arrive in.”