In this methodology, the designer is whoever is responsible for deciding what gets built and making sure it is useful. Depending on the organization, that might be a systems designer, a UX designer, a product owner, a product manager or a business analyst. Titles vary; the job is the same.
A designer is ultimately responsible for one thing: making sure what gets built serves the mission and the people carrying it out. That means making a project, feature or product genuinely useful to its users, while staying pragmatic about what internal and external stakeholders need and what can actually be built.
Isn’t Building Software Just Writing Code?
Writing code is essential, but saying software is just code is like saying winning a war is just shooting rifles. Drop 10,000 skilled riflemen onto a battlefield with no goal, no communication and no support, and they won’t succeed. When a team focuses only on code:
- It writes code that was never needed
- The code works on a developer’s machine, but not the customer’s
- It works until someone uses it differently than expected
- It delivers a product users hate, because it isn’t what they wanted or expected
- The project starts, but never really finishes
- The team thinks it’s done, and the customer doesn’t
Sometimes a one-hour meeting saves weeks of wasted work.
The Glue in a Project
The best way to think of a designer is as the glue in a project. Complex software brings together many kinds of expertise and many interests that pull in different directions: the customer, the product, the developers, the business. The designer:
- Connects expertise. Translates between subject matter experts, developers, testers and stakeholders.
- Connects interests. Balances what one customer asks for against what is good for the product and every other user.
- Holds the vision. Keeps the key ideas of a project in mind and turns them into artifacts others can use: use cases, design documents, mockups, tasks.
- Reduces risk. Above all, the risk that what the team delivers doesn’t satisfy the people it was built for, usually because the requirements were misunderstood.
- Balances viewpoints. Brings a user-centered view to a team that naturally thinks in technical terms.
Bring Options, Not Just Questions
Designers constantly hit decisions that aren’t theirs alone to make, especially when stakeholders want conflicting things. Resolving those conflicts is ultimately the product owner’s or customer’s call. The designer’s job is to make the decision easy: “There are two very different ways to do this. Here are the pros and cons of each. We recommend B.” Know when you need to ask, and when you can simply make the call yourself.
Know How the Business Works
Design overlaps with business more than most development roles do. A designer needs to know how the company makes money, for example through development contracts, product licenses, and ongoing maintenance and support, and why it takes on a given project. Sometimes a project is strategic: the features matter less than entering a new market or keeping a competitor out. That changes what deserves the most time and budget.
How a Designer Helps the Team
- Helps the team understand what the customer and users actually need
- Gathers research: subject matter, competitors, how things work in real life
- Talks to people outside the team, such as subject matter experts and stakeholders
- Creates and shares the vision, usually in a design document
- Prototypes, and sometimes implements parts of features
- Creates sketches, wireframes and mockups, or works with specialists who do
- Prepares playtests (user testing sessions) and demos based on use cases to get feedback from stakeholders, developers and customers
- Brings in ideas from outside the company and its products
When in doubt, err on the side of over-involvement. Get involved whenever something is being built for end users, even if you won’t write any of the code. Developers naturally focus on implementation and can overlook what makes a feature useful. More perspectives mean higher quality and lower risk.
Product Development Functions
Building a product takes several functions: areas of knowledge, practice and work that all contribute. There is no official list, but this is a useful one:
| Function | The question it answers | Bodies of knowledge |
|---|---|---|
| Team leadership | How do we work together? | People management and leadership, Scrum Master |
| Product ownership | What should we build? | Product Owner, business analysis (BABOK) |
| Project management | How can we deliver it on time? | Project management (PMBOK), general management |
| Design | How should it be used? | UX design, business analysis |
| Implementation | How do we build it? | Software and systems engineering |
| Quality assurance | Does it work properly? | Software testing (ISTQB) |
| Business communication | Does anyone know what we are building? | Marketing, documentation |
Functions roughly follow job roles, but they overlap, and high-performing teams blur the lines even more. Some specialization helps; too much creates silos that look inward instead of at the customer. Whoever leads an effort is responsible for all of these functions being done well. They don’t need to be an expert in each, but they need to understand how the functions fit together. The designer focuses on product ownership and design, and works closely with the rest.