Design process — Project repository

My design process is constantly evolving depending on the problem that I currently solve. I decided to not change my previous post, but rather continue in a blog series with Part 2.

My design toolset is evolving over the time as well. Even that I now use Sketch over Illustrator, my toolset is only there to support appropriate and structured design process. By design process, I mean a repeatable structure that I am able to apply as a problem-solving framework.

In this post, I would like to focus on the design project repository. I found out that when someone asks this simple questions "What is your design process?" my immediate reaction is to walk him through my current project repository.

Concept

In rapidly evolving agile environments, I am advocating for a single source of truth when it comes to design. The attempt to introduce the concept of design thinking within large and distributed environments comes with a certain level of informational chaos. A good designer acknowledges these external constraints and mitigates it with appropriate toolset and communication type.

Two Skypes, Flowdock, Slack, Hangouts (and Yammer).

Tools

My team's project management toolset remains simple and in fact, there are just two tools:

  • Wiki (Atlassian Confulence)
  • CA Technologies Agile Management (previously Rally software)

I am indeed using more tools to sketch the initial idea, design the final layout or validate the prototype. But the outputs from all these tools are embedded in these two two central repositories. For example, I am using InVision screen embedding feature to include the screens directly into wiki.

The walkthrough

Disclaimer: All the screenshots are describing the product release that is publicly available. APM Command Center is a part of CA APM Product portfolio.
UX Project repository Informational Architecture.

Homepage

All the content is accessible from the main landing page. The initial section groups the data about Personas and other user engagement activities. The wiki serves as a complete information repository and the page related to User Research does not only contain the research outcomes, but the whole research lifecycle documentation — Objectives, Interview Guide, Invitation, Interview notes and Synthesized results.

Main design project landing page.

User engagement and design validation represent a specific challenge of enterprise UX design practice. I am always keen to experiment with new methods of getting the design validation feedback, and the output is always linked from this repository. One of the user engagement activities are private beta community posts. In an attempt to win the attention of user and stakeholder community, I record a short video overview demonstrating goals of the new feature.

A sample beta community post with an embedded video.

Design Framework

The big picture is defined as a product mission. This is also the section where I maintain the overall progress and status overview. I love the concept of OKRs and I honestly believe that a key essence of any successful autonomous agile team is its ability to define, track and measure its own success.

Colour coded OKRs page with a sample of results evaluation.

Features

The features overview page is matching the actual production engineering backlog. We went through a number of terminology changes as a part of larger SAFe implementation program. The release field for a work-in-progress item contains Product Increment ID that is turned into an actual release number once the feature is publicly available. Design feature is matching the engineering backlog feature, that is broken down by the team into implementation stories and tasks. For a technical specification, the feature usually links another page with detailed functional specification maintained by the Product Owner.

Design Backlog structure.

Sample Feature

The actual content changes from feature to feature. The UX Improvement feature contains different deliverables than brand new product capability. Any new feature would likely contain Scenarios, Interaction Design flow diagram and an interactive prototype matching key use cases.

A sample design feature page.
A sample scenario page with extracted JTBD.
Use cases matching the interactive prototype used for prototype evaluation.

For this particular feature, I used a KLM heuristic to validate the projected feature ROI. Since it is possible to achieve the same goal with or without the product, by simply comparing times on tasks I was able to quantify the expected UX improvement.

Design System

The design system that I maintain is only local and it is, in fact, a side-effect of my screen based prototyping process in Sketch. I use Atomic design structure to export my Sketch or Illustrator symbols into a structured wiki page. Indeed this far from ideal and I am aiming for a significant improvement for my future projects.

Design System structure following Atomic design principles.

Conclusions

I love using Sketch and InVision, but I am not stuck to any particular tool. I am always keen to explore new ways how to produce, share and validate design deliverables.

For the actual project repository, I am advocating for a singular, clear and stable structure.

There are many ways how to approach design and each designer establishes his own design process and problem-solving approach. But the actual project repository documenting the thinking process from a very initial scenario narrative or UI sketch, through flow diagrams and interaction design iterations up to high-fidelity screen layouts and design system specs speaks volumes about the design quality. To me, design is about a repeatable structured process and design repository is a tangible representation of this process. If it does not exist at all…then, well, it's about to time to create one ;)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.