A civic-minded citizen seeking the singularity

An entry

Communicating Design

Date: 2015-08-05
Status: release
Tags: design process notes

Communicating Design, by Dan Brown, has been one of the most influential books I've read related to working in software design and development with larger-than-scrum-size teams.

The processes that Dan outlines seems to cover most personalities and responsibilities I've come across in large professional organizations and modern, startup product teams alike.

Every technical project I've been on included the following actions: Understanding user needs, understanding system (or environment) capabilities, and crafting new solutions to meet goals that are a relative change for a group of people involved.

The biggest challenge is maintaining coherence through each step throughout the natural development cycle. Use each artifact to inform the next, until the application reflects the User's needs. Remember, an application is a distilled form of human thinking. So, when the environment your application exists in inevitably changes, how will your process respond?

  • The UI doesn't quite work right? How does that affect the interaction patterns in place? Would it affect the Data Model?
  • A new customer segment (Persona) is identified by marketing, how does that affect existing Use Cases and Workflows?

Building shared understanding amongst stakeholders is essential when organizational change and technical adaption is required. Communicating Design came in especially helpful for this.

Outlining Who will use the system is essential, in terms of understanding your customers (and buyers). Developing hypotheses around how and why people will Use the system is a fundamental step in Lean development. Understanding how data sources and screen components are wired together to comprise a delightful interface is useful when it comes to iterating on the designs at different fidelities (from Mockups through finely tuned Screen Designs), resulting in software that is functional and specified.


Different aspects to consider as software evolves in an Organization:

  • Personas - who will use the system
  • Use Cases - what jobs is each Persona looking to do? #JTBD
  • Data Modeling - Start with an informal list and refine to an ERD (entity-relationship diagram)
  • Mockups - Lots of sketches. Paper-prototyping. Maybe some Balsamiq mocks. Maybe some lightweight clickables. Keep it conceptual.
  • Screen Design - Refining design details; pixel level treatments. Can include deliverables like a Styleguide and Design Patterns
  • Working, Tested Software - Written software test specifications that provide test coverage for software that handles the Use Cases above


Collaborative Design Tools


If you're working on a software project big enough to have a dedicated Product Manager/Owner role, consider using these all of these Design artifacts together to support coherence throughout the Design/Build process.