Article summary
Tech leads and developers have a vital role to play in the design of software. But with training in the abstract world of programming, many of us lack the vocabulary to provide useful critique on, say, the aesthetics or accessibility of design. Sure, we can share our feedback as people who may use it, but in many ways, a technical background isn’t helpful for this.
Experience as a software developer does help us nurture some specific super-powers, though. These are skills and abilities forged through years of writing code and unit tests, debugging problems, getting bitten by corner cases, and learning hard lessons from user stories that ended up taking way, way too long to implement.
In particular, experience in implementation tends to help build:
- Modeling skills – Software development is all about identifying and encoding a model of the real world in an abstract, precise way.
- Defensive thinking – Needing to handle every single case that can come up helps build the muscles used to identify and enumerate potential edge cases.
- Process optimization – Years of experience estimating tasks and working smartly to meet those estimates (or failing to do so!) can encourage continual critique of process and options. This can help drive you toward the most efficient path to a goal.
- Factoring skills – Building a non-trivial codebase requires continual thinking about cohesion, coupling, and reuse. This helps develop an intuition for how systems can be structured to maximize the leverage of existing components.
These skills are incredibly valuable when critiquing a design! Design is not simply what software will look like or how it will be used. It’s a blueprint for what the software development team will be doing in the future.
Tech leads have just as much a stake in the design process as anyone else, and learning how to contribute to the HCD process effectively can help ensure that development effort is aligned with business and user priorities.
Participating in Design Review
The first thing to do when coming into a design review is to make sure you’re prepared. While part of your role involves looking for possible usability improvements, those sorts of things are rather low-level concerns. What’s more important is how well the software will serve the needs of users, lend itself to cost-effective implementation, and align with the goals of the business.
Evaluating these aspects means that you need a solid basis in all three of these areas. You can start by reviewing user research, personas, etc. to build empathy with users and understand their use cases. You should also consider the goals, motivations, and optimal trade-offs for your client.
If you don’t feel comfortable articulating your client’s situation in precise detail and relating it back to the design, there are a few things you can do. For example, you can read up on available material, such as the statement of work, or get an overview from your project’s delivery lead or the client themselves.
Ultimately, the delivery lead, tech lead, and design lead should all try to master the desirability, viability, and feasibility landscape of the project. However, their individual niches and technical training usually position one or the other to examine certain aspects effectively.
To leverage my own expertise as a tech lead, I examine software through a handful of lenses. Each helps me identify potential weaknesses and generate alternatives that may not have been previously considered.
1. Maintaining fidelity to the domain model
All software implements a model — a simplification of the real world designed to accomplish a subset of potential tasks in a domain. Good software has a well-defined model that is maximally leveraged to solve user problems. Under the hood, the code must deal with implementation details such as databases and data structures, but code, users, and operations should all help reinforce and leverage the core domain model.
Software developers’ modeling skills can be put to great use by critiquing the consistency and fidelity with which a design represents a model. Is there a state that’s represented visually in one spot? Where else may that indicator be relevant? Are two different parts of an application dealing with the same aspects of a model but using different UI patterns, labels, or signifiers?
The design may well be improved by bringing both representations into alignment. This can help users recognize overlap and reinforce the model in their minds.
At the end of the day, the model’s ability to solve in-scope problems and be understood and manipulated by users is critical to the design. Experience and practice in modeling, especially in domain-driven-design, positions a technical lead to add a lot here.
2. Covering all your cases
Another question to ask is whether the design can handle all of the cases seen in practice. Will it have to deal with loading states? Or cases with data that is missing or incomplete? How well can it handle extreme cases of data variation?
Your defensive thinking skills and practice identifying unit test cases can be helpful here, revealing weaknesses that others may not catch. At the very least, thinking through these cases can help streamline implementation by giving the developer a clear picture of what’s entailed and the assets/resources required to handle it well.
Enumerating edge and corner cases can also help reveal weaknesses in the design before it’s implemented. For example, how long does data take to load? Some variation should be expected, and a design that only supports the happy-day cases may ultimately be non-viable. What are the odd cases that need to be supported and may stretch the design in unexpected ways?
3. Designing for leverage
A well-factored system has multiple points where a whole can be separated into parts that can be used independently. As one gains experience in development, the ability to create such systems and leverage those elements tends to grow.
Consider how a design builds leverage by providing reusable components — or creatively breaking down a design to maximize reusability. Look for existing components that could be used more effectively.
Designs are meant to provide tools that help users manipulate the model to accomplish goals. Most components in a wireframe are there to enable a certain type of activity. But are there other ways that could save effort, increase reuse, or make an existing component more flexible rather than creating a new one from scratch?
Look for opportunities to help the design align with existing components, patterns, and abstractions. Doing so may help lower implementation cost at zero expense to the user. Or it may make part of the experience slightly worse, but free up an additional budget so you can implement a different feature that adds way more value!
Designing for leverage is a powerful way to look for 80/20-rule tradeoffs. If you can trade long-tail, somewhat irrelevant details for more important features, it can enhance the net result at the project scale.
4. Designing by theory of implementation
One of the more famous quotes by Steve Jobs is, “Design is not just what it looks like and feels like. Design is how it works.” This quote gets at the heart of why model clarity is relevant to design, and it also points at the idea that a design needs to be implemented.
Developing a theory of how to implement a design — which I call an implementation hypothesis — helps complete the design. Without it, a user interface concept is really just a comp. Of course, any designer will be aiming to create something that’s implementable, but sometimes, a gap emerges that requires detailed knowledge of implementation to cross.
Treating an implementation hypothesis as part of the design can help produce better outcomes by forcing detailed thinking about the feasibility of a feature upfront. Do you need research or prototyping to prove feasibility? Do details of the design defeat reuse, inflating cost? Are there implicit performance requirements in the design that we may not be able to meet?
Developing an implementation concept as part of the design helps draw out all sorts of conversations that may uncover new use cases, opportunities for cost reduction, or ways to better meet users needs.
Feedback on Your Feedback
Ultimately, a healthy team design process is a dialog of generation and critique, creation and destruction. All participants bring new angles and insights to toss into the collective consciousness and factor into decision-making.
Design decisions are made in a complex environment, where there often aren’t clear answers. Sometimes, choices need to be made about what best aligns with priorities.
To work in this environment, you need to remain open-minded to possibilities. You may have a sharp critique of a concept, but what could you do to ameliorate issues and make the design more successful? You may love a concept, but are you able to spot its potential problems? If you find yourself invested in a particular option, push yourself to be an advocate for an alternative. Really understand it, its pros and cons, and where it could be stronger.
So don’t take yourself too seriously in a design review. Ultimately, you’re part of a milieu, adding color and detail to the picture. The design is for the project — the client, the user, and the budget — not for you. Set aside your pet passions and ego and move forward in the way that will achieve the best result.