Design Thinking in Agile Development
As Planning Labs grows and its development practices spread through the NYC Department of City Planning, it’s important that we document & disseminate how design fuels our core values. This will allow multiple agile teams to build a consistent experience across the agency’s products.
Here are some design methods employed by Planning Labs:
From the start
Design is not an afterthought. It can’t be tacked on at the end of a project. Adding it mid-project can be challenging if not impossible. Before the first line of code is written, design thinking should frame the problem. Who’s the user of this app? Why are we building it? Do we even need to build something?
Human-centered
Throughout the development process, incorporate feedback from real users. We continuously demo and test our products. Our first step in every new project is to put aside notions of functionalities and UI so that we can clearly define the who, what, and why. Most importantly, the who comes first.
18F has a great set of human-centered design methods that we utilize — especially dot voting, which helps stakeholders make difficult prioritization decisions (including features to not build).
Everyone is a designer
Currently, everyone on our team is a developer to some degree. But the line between Designer and Developer is blurry. Designers might champion our human-centered methods, but it’s ultimately a collaborative effort. It’s the responsibility of everyone to advocate for users.
Design is part of development
Resist the urge to make separate GitHub issues for design and development tasks. Design can’t be separated from development. Design is an implicit part of every dev task. It’s easy to see how design is involved in adding a new button or styling map layers. It’s more complex to see how backend architectural decisions can affect user experience. But every decision we make needs to put the user first.
GitHub issues as user stories
When writing a GitHub issue, consider putting the user first. Almost any issue can be titled with a user story following this format:
“As a [type of user], I want [my goal] so that [my reason].”
This helps keep human-centered design at the forefront — especially with new feature requests. For example: “As a borough planner, I want to copy the URL of a tax lot so I can share its information.”
But even development tasks that have no impact on the UX can be written this way: “As a developer, I want the API to return GeoJSON so it’s easier to consume in the frontend.”
Design (not just development) is agile
Nothing’s ever finished or perfect. Be comfortable shipping apps that aren’t. Don’t become impeded by high-fidelity mockups. Striving for pixel-perfect UI can too often slow down development or force waterfall implementation. You could be spending too much time solving the wrong problem. Instead, make assumptions and test them as early as possible. Then iterate, focusing on continually improving the user experience.
These are just a few of our methods. We’re continually improving our processes and are in the process of more thoroughly documenting our design standards for agile development by creating design guidelines (which outline the ethos and methodology behind our design decisions) and user interface patterns (code snippets for implementing common design elements).
How does design fuel your agile development practices?
We’d love to hear from you on Twitter!
