Designing Software Systems

posted in: Uncategorized | 0

I’ve been thinking of strategies to build software with speed. Usually it takes several months to iterate on software systems during the engineering phase. In order to reduce the number of engineering iterations, we can make faster design iterations prior to cutting ground. It’s analogous to building a house: if you can design a proper foundation and overall structure in blueprints, the cost of construction is straightforward. In contrast, if the overall structure hasn’t been thought out before building, it is a costly retrofit to rebuild parts of the house.

Also we want to build accurate software. Software accuracy in this case is to satisfy customer requirements. We can draw upon the design disciplines to discover customer requirements. Identifying what the customer requirements are isn’t a new idea: it started with analyzing human factors in factory assembly chains, ergonomics when using mechanical interfaces, and now human-computer interaction (HCI) when using software systems. We can draw upon this prior work, which I will briefly introduce here.

Initial Readings to Design

Everyone who thinks about building products should read The Design of Everyday Things (Donald Norman). Although this book draws upon older examples, it’s a good book to understand why products succeed: they meet both the functional and emotional requirements. The onus is on designers to recognize and design for the emotional (i.e., non-functional) requirements.

An academic introduction to design is Interaction Design (Sharp, Rogers, and Preece). This book provides a theoretical reading to interaction design. Although the book isn’t operational for practitioners, it provides many examples of users interacting with computer systems.

Design Tools for Practitioners

Once we have an understanding for the importance of design, we can shift focus to applying design methodology in our everyday work. Design methodology isn’t only for Designers: it is also for Engineers, Product Managers, and C-level Officers.

A Process Framework

Let’s start with a useful framework, the double-diamond model from the British design council. I interpreted the double-diamond design model as:

  • Discover: In this phase, we apply divergent thinking to open the solution space: consider all possible ideas through brainstorming. This phase should bring out more questions than it answers.
  • Define: Once we have diverged in our thinking, we converge on the ideas that are important for the business and customer.
  • Develop: Once certain product directions are designed for the software system, quick prototypes are built to diverge the design space again on a refined problem. These prototypes should be screenshot-fidelity or clickable interactions, but they aren’t shippable software yet.
  • Deliver: Once the prototypes explore the design space, we converge again at the software solution that should be built. A few prototypes screens are revised in this process.

Another operational framework is the Google Design Sprint. It sets up design sprints as five-day exercises where:

  • Day 1: Prepare for the sprint by researching, competitive analysis, and considering overall business strategy.
  • Day 2: Discover the problem space by producing as many solutions as possible individually. These solutions are paper sketches that contain a full user story. Ideas are then presented and critiqued.
  • Day 3: Define the best stories to implement as prototypes. Relevant C-level stakeholders are involved in choosing the best prototype ideas. The best ideas are voted upon by stickers, not consensus meetings, and avoid design by committee. If a single vision can’t be identified, then choose 2 or 3 competing visions.
  • Day 4: Develop high-fidelity prototypes to realize the prototype(s) chosen in Day 3. These high-fidelity prototypes are produced on a computer with the quality that they could be given to an engineering team to implement.
  • Day 5: Deliver the prototypes to a small group of internal and external test users for evaluation.

Notice how the 5-day Google Design Sprint corresponds nicely with the British design council’s double-diamond design model.

A Toolbox for Understanding Customers

We also need to understand what customers need and want. You can’t ask customers for solutions that they haven’t seen themselves, so it’s up to designers to find out. Ideally designers play the role of social scientists to understand customers.

The methods for understanding customers can be drawn from two books. Contextual Design (Beyer, Holtzblatt) provides a set of tools to gather customer requirements. These tools are represented as visual diagrams:

  • Flow Diagram: a diagram showing how information and artifacts flow between people
  • Sequence Diagram: when a task needs to be completed, several people have to perform tasks in a given sequence. A sequence model represents an assembly line of information inputs and outputs (e.g., document approvals) between people.
  • Artifact Diagram: physical artifacts with information (e.g., trays, folders, mailboxes, computers) are documented.
  • Physical Diagram: a diagram of physical space is drawn to show where people are working and what it means (e.g., entering an office has a reception desk to prevent disruption of other employees)
  • Cultural Diagram: a cultural diagrams shows the business roles and influencers within an organization

The second operational book is This is Service Design Thinking (Stickdorn, Schneider). Unlike the first book that studies only customers, service design embeds the software system as part of the customer experience. Each of the interactions between a customer and software system is represented as a service touchpoint. This book is also awesome because it catalogues a set of tools for designers to solve design questions.

Reference Organizations

I have outlined a few design resources that I draw upon my practice for designing software systems. I also am influenced by several organizations with strong design methodologies:

I’m always looking for inspiration in literature and organizations that emphasize design in their work processes. If you know of other good sources, send them my way and I’ll add them to my list.