Designing for Enterprise Products Like an Urban Designer
When I first began designing for the web, I felt a great deal of angst surrounding my mastery of the tools of the trade. I had come up through a landscape architecture undergrad with a marketable set of skills expected of the industry–AutoCAD, horticulture, site engineering–but my interests had veered towards software and the web by the end of college and I wasn’t sure how to get rooted in a different design profession. Now I’m not saying tool mastery isn’t important, and it took me a while to get to a point where I felt comfortable in web related gigs, but I found that throughout this journey, my design process ended up being a far more marketable skill. In fact, it helped relieve some of the pressure I felt to learn specific tools and instead allowed me to focus on refining other stages of my process. Tools change project to project, especially if you’re a designer looking to engage problems across a variety of domains. It’s funny to look back on my all-nighters in the studio as an aspiring urban designer because today I design products for Nasdaq… and in much the same way.
I do my homework
My favorite assignment as a student came at the end of my undergrad. It was to redesign the Museum Quarter in Vienna, a hub for the arts in the Austrian city. The location was inspiring–a dynamic public space that broke from many of the more traditional assignments scattered throughout upstate New York–but we were unable to visit the site. Site visits are a crucial form of research, and as my peers and I knew, the quality of research makes or breaks a project during the final critique. I knew nothing about Vienna, or Austrians for that matter, and was forced to round out my design research in other ways: reading tour books and Austrian history, scouring the web for historical maps, watching hours of YouTube on museum programming and Vienna’s art scene. I consumed anything that could help me understand the forces that have shaped the site and provide me with the context needed for an informed design.
Today, research plays an even larger role in the work I do… I’m no longer exploring conceptual ideas but building tangible products, often in domains I’m new to. Just recently I had the pleasure of getting to design a trade surveillance tool for Nasdaq. Despite having worked several years on financial software, the world of trading was completely foreign to me. While discovery interviews and product owners helped shape my understanding of the domain, it wasn’t until I started sinking time into books, conference materials, and the like, that I began to get a better sense of the context and its intricacies. As a remote employee, where I’m not necessarily sitting down the hall from the people I’m designing for, having this domain knowledge not only helps me communicate more effectively with customers and stakeholders, but helps me arrive at better solutions.
I remember less about Vienna now than I’d like to admit and I’m often still at a loss when hearing someone discuss market structure, but the research I’ve done — and continue to do — makes me a stronger researcher on each project that comes my way. I’m also lucky to be surrounded by my colleagues who champion research within our organization. It’s from them that I continue to learn new methods and etiquette as I push to grow this stage of my process.
I bring people together
One of the great things about designing public spaces is how many different groups of people will interact with your design. People of all ages, shapes and sizes, cultures and values, motivations and intentions. Design can be used to bring these differences together in a meaningful way, and in almost every project, my strategy was to facilitate just that.
While studying abroad in Copenhagen, one assignment tasked us with designing an urban community that would provide family housing, a daycare, an elderly care center, office space, and an education space. Understanding how these groups live their day to day lives is important but its even more essential to find the places in which their lives intersect. How can the active and passive, the consumer and producer, young and old, support and fuel each other’s activities? Designing a thriving public space must aim for these collisions. Articulating this strategy to my professors typically relied on a few key artifacts like personas and activity maps, materials that could help justify the design choices I was making.
Professional practice is a bit different from an undergraduate assignment simply because it takes things a step further: we’re producing a tangible product. We still produce personas and customer journeys to articulate our strategy and support our choices, but unlike a school assignment, we can also use these artifacts as a means to assess the success of our choices down the road. We can continue to refine them. Understanding who our customers are is essential to the work we do and yet I’ve come to learn over the past several years that understanding the people on your side of the table is just as important. Our designs may aim to bring different groups of customers together–by identifying overlapping workflows for example–but we must also work to bring different voices to the table. How can different businesses across the organization work together to support new efforts? Are there opportunities at the intersection of these different interests? It’s by understanding these dynamics, for both customers and stakeholders, that we can support and fuel each other’s activities.
I develop my ideas
Developing my ideas used to involve a lot of recycled cardboard, hot glue, and Exacto knives. It was easy to jump into this part of the process without much research or thought about strategy simply because it was so much fun to get my hands dirty. At the start of most projects, my desk was piled high with quick and dirty prototypes. As the project progressed and my strategy became more clear, ideas tended to consolidate and a design language would emerge. This language was not just a visual aesthetic to guide the design moving forward but also provided a means to communicate and justify my ideas. This was important in regular critiques for our class where an inability to effectively articulate an idea would land it in the pile of discarded prototypes. After all, ideas are not necessarily right or wrong, but they must be supported by more than just your own assumptions. Critique helps expose those assumptions and uncover opportunities you may not have considered.
During school, the development of my ideas often blurred with research and strategy. While this is not necessarily a bad thing–I believe these stages to be a bit more fluid than I’m describing–I allowed it to shape my understanding of design as being driven by the development stage and the tools that facilitated this. It wasn’t until the end of college that I began to break away from this idea. The design of the Museum Quarter in Vienna, for example, was un-prototypable using the tools I had at my disposal (it relied on a complex network of pressure sensors to deliver the intended design). Instead of getting hung up on development, I worked to strengthen the idea by doubling down on research and more clearly articulating my strategy. Perhaps the final prototype was a tad underdeveloped but as a design solution, I still believe it was some of my best work.
Today I find myself using a different set of tools to develop my ideas. Sketch files and living prototypes have replaced doodles and 3DS Max. Poorly organized directories have replaced the heap of prototypes on my desk. More importantly, however, design systems such as component libraries, prototyping frameworks, and style guides have emerged as the artifacts of development. They were all essential to my projects as a student, even if I called them something different, and today they are integral to the work we do as a team at Nasdaq. However, by divorcing the design systems from the tools that created them, it’s become much easier to treat this phase as an equal partner of the process and not the driver.
I validate my choices
One of my biggest frustrations with landscape architecture and urban design was the inability to measure the success of a design… and furthermore, the inability to correct for a mistake. For a long time urban design was guided by theory. The problem with this approach is that as cities transformed across the decades, the downstream effects of seemingly innocuous design decisions were often detrimental to the health of a space and it’s surroundings. In addition, cultural or societal shifts could render thriving spaces useless. This has changed to some degree as the public has become increasingly involved through bottom-up engagement. Best practices have also evolved within the urban design community, informed through extensive research and data-driven observation.
For me, however, the feedback loop was still too slow. I was looking to the web and the Internet of Things to augment design synthesis, treating an urban space more like a piece of software that could run various programs. It could then provide real-time feedback to its designers on what is and isn’t working. Together with a flexible and modular design system, spaces could evolve towards the needs of their patrons. Looking back on some of these projects, it was clear that I was attempting to infuse these spaces with their own design process, providing tools for participatory design as well as tools for self assessment, evolution, and growth. For the Vienna project, not only did the space provide prototyping platform and API for artists but tools for researchers and designers to better tailor programming based on shifting patterns of use.
Design synthesis may not have been baked into urban design quite how I had envisioned but as I moved into the world of web and software, it was commonplace and essential. A lot of the real-time analytics I had dreamed of within urban spaces are baked into the products we design, helping us measure whether our designs are as effective as we hope they are. These quantitative metrics either validate our choices or uproot assumptions we may have had but its important to remember numbers don’t tell the whole story. We also rely heavily on qualitative feedback. Testing everything from wireframes to finished products in front of our customers ensures our ability to react to their needs and assess whether we’ve met the goals we laid out in our strategy. In the world of enterprise software, where legacy systems run rampant, it’s critical to infuse future products with the ability to facilitate this synthesis.
To close, I have one final overarching thought to touch on. I mentioned earlier that these phases are a bit more fluid than I’m describing here for clarity’s sake. Generally projects I work on tend to progress fairly steadily through these phases. As a cyclical process, however, things eventually begin to diverge from their original trajectory. A certain feature, for example, that shared it’s trajectory with other functionality, may turn out unsuccessful. Further research is needed to adjust the strategy and develop alternatives. I tend to think of this as design tendrils, spiraling out along their own trajectories but still connected at their root to an overarching process. Complexity can be a hard thing to manage and it’s important to understand how these branches relate to their original context. Strong research will help branches from straying too far. Smart strategy will keep too many from branching off. Solid design systems will make prototyping successful alternatives easier. Effective synthesis will keep the process under control.
It’s been interesting to reflect back on these various stages of my process, if only to help myself better articulate how I work. I’m sure I’ve glossed over a lot of specifics but I hope to write more so perhaps I’ll revisit. All in all, I think it’s safe to say, whether you’re designing the next urban space or the next ecosystem of enterprise software, it’s important to remember it’s about the larger design process, not the tools of the trade.
