Designing for Enterprise workflow: how to find the balance between flexibility & generalization with design patterns
Imagine you need a new home — you can either hire an architect and build it yourself or you can find the best match on the market. Let’s compare the two options: if you hire an architect, you can pick any point in the continuous space of possibilities, but it has overhead costs and takes effort to make it from scratch. If you choose the best match in the market, you have a discreet and limited number of options, but it has a lower cost and is ready to live in.
Assumption
Let’s simplify this situation a little bit and remove the cost and time issue. Assume we are in an ideal world where building a house is not more costly and we can magically build what we want overnight. Would it still make any sense to buy an already built house instead of designing a perfect house for yourself?
Challenge
To reach perfect results, you need to consider every small detail and unless you’ve had extensive previous experience in building houses before, it will be difficult to know all the requirements and necessary details upfront. Your context is limited based on your own personal experience and you won’t be able to see other possible scenarios that have never happened to you before. You need to make a compromise when there are conflicting details to sort out. So, even without a cost issue, just figuring out what you really need might end up being a big obstacle to designing a building from scratch.
Design patterns
It is interesting to note that “Design patterns” or “Pattern language”, a widely adopted term in software engineering, was first introduced by the architect Christopher Alexandar.
“Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” A Pattern Language: Towns, Buildings, Construction 1977 Christopher Alexander
Alexandar says that an Architect, knowing such problems so well by studying the requirements of many previous clients, is able to define and apply these patterns, creating a house that satisfies the demands of most homebuyers. Assuming there are enough houses in the market designed based on these principles, not only is it more cost-effective to find a house that has been already built, but also there is a good chance that it would be a better match for the homebuyer. Finding a match is a much easier problem to solve as the available options and corresponding details are all available to compare, whereas in the other case building the house requires mapping a vague and idealized image to a concrete and plausible implementation.
And remember so far we have been talking about an idealized world where we bracketed out all the trouble of building the design.
Software Product Design
The process of designing software and designing a house are very different: building software is an iterative process whereas building a house is a waterfall process. The software is a living system that needs to be updated very frequently, the house is a fixed installation. When an enterprise company has a need for a new software they are put in the seat of the home buyer: they have an option of either building the software (in-house or have it custom built), or buy one of the solutions that are available in the market. Similarly, the cost and the overhead of developing a complex product in-house is an issue here, but the hardest challenge is the design and product decisions that need to be grounded in knowing the end user’s needs.
Enterprise Challenge
Enterprise software is by nature a complex product. If you are working as a designer at an enterprise software company, you may find it extremely hard to find recurring problems among your clients. Enterprise workflows are complicated and each are custom to their company-specific culture. These workflows can often be older than the employees’ entire career experiences. Therefore, it’s extremely challenging to make a change when most of the people are adapted to legacy workflows. As a result, enterprise software designers may fall into the trap of designing a solution that is customized to address their client’s unique needs and workflow. As enterprise software companies add additional clients, they will find that their solution cannot adapt to a completely different workflow environment.
ActionIQ
ActionIQ started 5 years ago, as a b2b enterprise startup to solve the emerging needs of modern marketing. Rather than starting with the typical co-founder duo of an engineer and a salesperson, ActionIQ started with a trio of engineering, product management, and design. Our team was incubated within GILT, a discount luxury e-commerce business, to optimize their client acquisition and retention strategy. This gave us incredible access to observe the day-to-day workflow of its Marketing team and deeply understand their core needs. Rather than building a custom solution for GILT’s unique needs, the makeup of our team allowed us to dissect the client’s problems into abstract components, and identify design patterns that can address each one leading to solutions that can address each component.
This approach has provided us 2 benefits: First, it provides greater flexibility, allowing users within an enterprise to interact with our software according to their unique workflow and use-cases, thereby maximizing the opportunity for within-company collaboration. Second, it provides us the foundation for addressing a diversity of enterprise needs; and thus the opportunity to scale rapidly without adding complexity.
To give an example of problem patterns we identified in early days, as a user of our platform (a marketer) wants to identify a unique customer segment based on a series of attributes to launch a targeted marketing campaign (e.g., females between 24–36 that purchased a bag and shoes in the past 2 months but have not purchased anything since then). Identifying this customer segment requires a combination of a complex set of variables (e.g., gender, age, purchase category, purchase period). Using the concept of design patterns, we realized that the targeting process can be governed by a generic set of rules (e.g., suppression, intersection, etc.), which can interact with each other to build the complex logic required for this identification process. Making these composite rules allows the user to seamlessly generate various target segments by cycling through permutations of these rules and the values assigned to each rule. This capability increases the agility of the marketer to launch infinite varieties of targeted marketing campaigns and not have to rely on the vendor to custom-code each of them.
Designing software has many things in common with designing a house, and in the case of enterprise software more like designing a skyscraper. Similar to the way the architectural design of a house doesn’t only determine the aesthetics, but most importantly defines the spatial possibilities within the physical space for the habitants, design of a software defines the navigational possibilities within the informational space of the software. Using design patterns help users find themselves in a familiar and empowering space.
This is one example of many complex marketing problems. In today’s fast-paced market environment, while the needs of our clients are constantly evolving, ActionIQ’s commitment to leverage design patterns enables us to rapidly scale and fulfill marketers’ complex needs. As designers, we have a unique opportunity to identify patterns between different problems and design products that empower clients to achieve their goals effectively and efficiently, while constantly iterating our product design to reach better results.
Raschin is the head of design at ActionIQ. She enjoys the abstrusity of turning abstract into palpable and back through design.
