Why Careful Design Isn’t Cheap

My company operates under a design-first approach to building software. We also serve a lot of segments — some clients are massive, multi-national, cash-rich law firms. Some are small non-profits focused on delivering legal aid to the poor. Some are legal tech startups, some are large legal technology enterprises. I’d love to say that there is some consistency among each segment on how they value design effort, but it really comes down to client by client and their experiences with design/knowledge of the level of effort.

I’ve seen a prevalence of software development RFPs recently that focus heavily on the need for good design, user feedback, iterative processes, etc. But the budget often does not align with that focus. We had some good twitter conversations on this issue yesterday. Here are some highlights:

To help address this issue, I thought I’d offer a breakdown of the processes involved in careful design, that is, design that is carefully tailored to both meet the organization’s goals and to serve the user, so that organizations looking to hire designers and developers have a better sense of what they’re really asking for.

The Problem Phase of Design

We start out a project with a discovery/design phase, working first to fully understand the problem that we’re trying to solve for. This is a critical piece in building a successful product. This involves some combination of the following activities:

• Workshopping with the client to understand their organizational goals, project goals, and their understanding of the problem and user, and more. We typically kick off a project with one or more client workshops where we create a project charter and make sure we’re all honest about the goals of the effort and the metrics for success. If not, we’re just throwing darts blindfolded.
• Reviewing research and existing data. For the intended user, what devices do they typically use? What is their level of tech-savviness? This level of understanding is critical to framing how a product should be designed. An elderly rural user has vastly different needs than a general counsel of a Fortune 50 company.
• Interviewing users. You, the client, come to us with a problem, but you understand it from your perspective, not from the actual user’s perspective. It’s easy to say “well, I used to practice law, and if it were me, I would xyz.” But you left the practice, which makes you necessarily different than your user. Skip this step and you’re likely to miss the mark in product-market fit.
• Interviewing stakeholders. Success of a project is typically not only defined by whether the user finds value in your product, but also whether your organization’s goals are met. I’ve yet to meet a product that didn’t have several layers of politicking involved, so this piece is essential. We can nail it for your users, but piss off your funders/partners/leadership — I wouldn’t call that a success.
• Observational research. This isn’t always necessary, but for work that has a process element, observing a user in the environment or process that the application effects can shed a lot of light on the needs that users aren’t able to articulate in interviews.
• Reviewing existing solutions. Identifying solutions that exist on the marketplace and how your product fits into the existing market helps to define product goals. If you miss this, you risk flailing trying to create differentiation for your product.
• Journey map exercises. Again, not always necessary, but when we’re working towards behavior change or process change via the product, understand the user’s existing path to resolve the problem is very helpful in conceptualizing the UX for the product.
• and more…

The Solution Phase of Design

Unless you come to us saying “I know exactly what I want to build and who I’m building it for and how I want it to look,” a period of ideation and design then takes place. This involves any combination of the following:

• More journey mapping. This time, we want to focus on the ideal, improved path for a user to solve his/her issue, including using the product. This is often a first step towards sketching out the user flow for the product.
• Client sketching sessions. In a solution-focused client workshop, we will run through some sketching exercises where, based on very specific problem statements, we all work independently to generate a number of idea and then come back together to review and vote. This process helps to generate a wide range of ideas so that we’re not stuck with one pre-assumed product.
• Internal sketching sessions. Our team will then hold internal sessions to refine concepts and get us closer to some ideas to prototype.
• Wireframing of one or more ideas. We then create low- or mid- fidelity versions of some of the ideas. This allows us get user and stakeholder feedback before committing to full design.
• Conducting stakeholder and/or surveys on look and feel. To create the UI, we work to gain an understanding from stakeholders about what feelings and look they want to convey to their users.
• Moodboard creation and review. We don’t typically pick colors and fonts at random. They are all designed to create the mood that the product is aiming for. We’ll create several options for client review.
• Style Guide creation. Once we’ve settled on a look and feel, we will create a guide with all of the colors, fonts, and more laid out to all the development team and any outside marketing team to be able to quickly get that information.
• Branding. We don’t always get involved in branding, but needless to say it’s an essential part of a product unless you’re using existing branding.
• Prototyping of one or more ideas. Depending on the goals/purpose, we may then apply the styles to the wireframes to create more realistic experiences to then go test and validate with users. This helps us to refine or course correct if we’re finding that either we have the wrong product or the wrong market. If the project is more of a rapid pilot to get something out the door for testing, we may skip this step.
• Design reviews galore. We typically do several rounds of design review with clients, including wireframes, style guides, and full UI.
• Planning and organizing logistics of testing sessions. Defining the users, carefully defining the goals of the testing, determining methodologies, recruiting users, writing scripts, etc. may all be a part of the planning process and can be extensive.
• Holding testing sessions. The effort here depends on the number of participants, the type of testing, location, etc.
• Revising wireframes/designs, etc. If we don’t learn and correct from our testing sessions, there’s really no point in doing them.
• and more….

In short, the process involves a ton of work and the talents of a multi-disciplinary team.

This process requires a project manager, a designer, and a product manager at least. Typically one or two developers (one front-end, one back-end) would be involved so they understand from the start what they are building towards and can offer input into feasibility, viability, and cost.

This phase can last anywhere from 1 week to 6 months depending on the complexity of the issue. This piece of the puzzle can take between 100 and 700+ man hours depending on the size of the project, the budget, the issue we’re dealing with, and more. The average project falls in the 4–8 week range of effort, or approximately 130–300 hours of effort based on data from our last few projects.

We leave the discovery/design phase with designs of the critical path of the application ready to be implemented, a strong sense of confidence in our validated product, and a solid, shared sense of what we are all working towards.

Continued Design throughout the project

Design doesn’t end when the build phase begins. We leave the build phase with the critical path designed, but there are always a number of additional interfaces and interactions that need to be considered (think profile pages, administrator pages, modals, email templates, etc.). There’s no need to design those up front. In fact, as requirements and priorities change, it’s best to incorporate design in an agile manner, having the designer working a sprint or two ahead of developers to make sure that we can be as responsive as possible to the changing project needs without creating any rework or roadblocks for the development team. Design, particularly on the UX side, also needs to be involved during the build cycle to address any misaligned user expectations uncovered by QA or user testing.

To try to put a number on it based on our averages, in a typical build cycle, design remains involved around 25–40 hours per sprint (or 2-week chunk of work).

Risk Control in Technology Development

As you can see, there’s a ton of effort that goes on here. So why do we do it? Why don’t we just create a design and go with it? Why wouldn’t you just hire someone from Upwork and make it happen?

The one thing we as a design community know very well is that for a product to have its highest chance of success, it needs to be designed with intent. You can build inexpensive products with a generic design, even an attractive design, but that doesn’t mean it’s going to be right for your users and designed to meet your organization’s goals. This entire design process exists to increase the chance of a product’s success by working toward fine-tuning the product-market fit (which, yes, is a consideration even for free access to justice products).

You can definitely find freelancers for considerably less, but clients come to us because they want the range of expertise we have in-house as well as our industry-specific expertise — but this is certainly a strategic decision your team needs to make.

Really, this comes down to a calculation of risk. If a product isn’t mission-critical with high stakes, then hiring that one developer to Grip it and Rip it and no designer or just some kid in your neighborhood that designs WordPress sites might be completely fine. The cost stays low, but it’s also more likely to be an unsuccessful effort.

Spending money on custom technology involves risk. Risk that you’ll build something that no one ever uses, risk that you’ll build something that doesn’t work, risk that you blow your budget, risk that it never results in your organization’s goals, etc. Every decision we make on process and staffing is to de-risk the effort to the greatest extent possible, and to give products the highest chance of success based on our years of experience. We certainly cut corners for clients who want or need a leaner approach and can usually accommodate most budgets (within reason) but not without making it very clear what the consequences of that might be.

None of this is to say that you can’t build technology on the cheap. You absolutely can. Your expectations just should be well-aligned with the value you seek to get given your budget. If after reading this you’re saying to yourself “well, I definitely don’t need all of that, it sounds like overkill,” one question to ask yourself is,

“will I be happy at the end of a project if we release any product, or will I only be happy at the end if we release the right product with good outcomes.”

If what you really want is a carefully designed, well-built product, consider what you’re asking for in your RFP. My hope is that this article will give you a sense of what’s really involved so you can better budget for the outcome you’re looking for.

Also, we’ll be announcing next week a product development bootcamp that we are holding in NYC June 26–27 in conjunction with the Legal Geek event on June 25. We’ll be going through these concepts in depth to give the industry a really firm sense of the effort involved in product development. Stay tuned for info on that.

My next post will cover the real effort of a build cycle. I’m always happy to talk through budgeting if you’re thinking of a project. Don’t hesitate to get in touch!