Design process
With the goal of enhancing visibility into my own design process I will continue with article series that I started with Design Toolset. I would like to demystify UX design buzz and open up about tangible outputs of design craft.
Every designer has a different way how he connects the dots. To me, this process is different from project to project and from release to release. Attempting to describe the overall design process often falls into holistic diagramming that demonstrates intention, but shows very little of real design craft and tangible outputs.
This story is related to a design process related to one release.
Preparation
Before first rectangles were thrown on the screen, a larger group of internal stakeholders needed to figure the right increment that fits product roadmap. Main constraints to consider were team velocity and release date.
Research
Once we found main release theme, we started with collecting inputs. To fill in the gaps in our knowledge, we defined research objectives upfront. During on-site research, we met with users. We discussed their current pains and matched found patterns with our original objectives.
I am not a domain expert in the area where the product delivers key innovative features. During this phase, it was important for me to engage with my product manager to gain visibility into the domain. Honest anecdotes about what solutions failed to solve the problem in the past and inspiration from competitors were important parts of this process.
Scenarios
Scenarios are the key artefact in Cooper Goal-directed design methodology that we are adopting. They describe an ideal experience with a product. We are using See | Think | Do formulations, but our scenarios are often a little more instrumental. At this stage, we were already aware of various constraints that we wanted to include right from beginning.
It was important to me to find a form that is appealing enough to be used regularly. I saw too many wall-of-text descriptions that nobody ever reads in its entirety. I chose headlined table that describes scenario flow as experience touchpoints with future product UI.
Ideation
Ideation was the brainstorming phase. We did not use any specific framework or tool, we just met regularly and throw ideas of possible solutions. I was recording these outputs, but these were often still too fragile to invest more time into any sophisticated documentation. I organise my sketchbook by dates and during these early stages I did new sketch per each meeting.
Project management
The design is never finished and from this moment, every design artefact is evolving as we go through design iterations. Central UX project repository is the key tool to maintain consistency. I am using an internal wiki and every single design artefact that I am producing was either part of this page or linked within.
Wireframing
I used wireframes to communicate an intention to the team and internal stakeholders. Wireframes represented main use case and for demo purpose I stitched screens together in a powerpoint demo. Wireframes are throw-away assets so I was trying to invest just enough effort to be able to communicate the idea.
There is one myth flowing around UX community saying, that there is direct dependency between wireframe fidelity and feedback abstraction level. It says that for rough sketches people will focus on global concept while for detailed page design same people will be too distracted by colours of icons and could not see through the concept. Based on my experience I can stay that this is myth. The feedback quality depends on story (scenario) that designer is passing, not design artefact itself. If there is any dependency on prototype fidelity, then it is exact opposite. Not all people can think about product in abstract layers. All they see is rectangles and placeholders — they can't see the product behind since it is just not there. For key stakeholders is is also not worth enough their attention. The more realistic the prototype is the more realistic feedback. Designer needs to adapt the story he is presenting and moderate the audience in right direction. That is just easier with high fidelity interactive pages. After all, if it is icon colour that blocks perception of multi-milion dollar technology it is good idea to discover this sooner than later.
UI Flows
I used flow diagrams to get the holistic overview about how data are related to individual UI components. These diagrams allowed us to focus on conceptual work and exclude button or icon colours from our conversation (see my previous comment on wireframes).
Layout Design
We were not starting on greenfield and from the very beginning we were trying to re-use existing components and patterns as much as possible.
This project phase is often simplified as "graphic design" and even that I use Adobe Illustrator (graphic design software) this is where the similarity with graphic design ends. My goal was to figure out how each state matches real content — from scrollbars and input forms through progress and error states. I was trying to produce as realistic page layouts as possible.
Use Cases
Uses cases provided additional levels of detail describing exact steps taken through the interface to achieve persona goals. My goal was to get enough details in use case description so that they can be used also for prototype validation.
Interaction design
I believe UML and flow diagramming is an invaluable technique in product design. For this project, I created simple interaction diagrams for components that are changing states — such as buttons contextually changing labels.
Details and States
It is always difficult to think about all the possible states upfront and design them before development starts. With this project, I was trying to focus on crucial interaction patterns. Until this release, our product was used to consume data. But with this release we are introducing input and edit capabilities.
Input forms and form validations were key design patterns to focus on early in design.
Prototype
I used InVision to maintain all screens in the form of click-through prototype. My goal was to allow all stakeholders to click through main use cases and I used the same prototype for prototype validation.
Validation
I shared the story of prototype validation tools used on this project in separate article series.
Planning and grooming
Grooming, planning and prioritising are the activities where the concept is getting real and this was key product owner responsibility. During grooming sessions, we were able to identify gaps in design specifications. Knowledge of specific technological and capacity constraints allowed me to constantly refine the design. I was making sure that key UX aspects can make it into the release and trying to find compromises as done is better than perfect.
Design Iteration
The fun part of this article is that that it might look as a linear retrospective. In reality, none of these design process aspects are fully locked until the product is shipped. Development is taking months and we are constantly refining all design outcomes based on user and stakeholders feedback. I am constantly adapting layout to match all the new states, creating new flow and interaction diagrams, diving deeper into design details and adapting prototype.
There is nothing like a set of final deliverables.
Conclusions
I could be more specific when describing design process down to every single domain specialisation that I applied e.g. iconography design. I rather based this story around main tangible outputs — assets that I used to communicate design. Even that I had to anonymise specific content I believe it provides better visibility than simple diagramming.
I am not a big fan of these diagrams. In my perception of the product design, I could not draw a line between the individual phases. There is no distinct phase, where wireframe is moved to graphic design, or where finished layout is moved to the development. Based on my perception of form and function, I could not imagine executing the design in any other than "agile" manner.
Aligning with engineering agile heartbeat is an important aspect of design iterations. Each sprint product increment provides additional input for another design evolution.
The non-existence of a final locked set of design specifications does not mean constant re-works or no specifications at all. With my design process, I am trying to communicate and document the design evolution — a better version of previous. Design specifications are valid for particular sprint, and I am not attempting to document whole concept upfront.
Main theme and scenarios are fixed, but I am always keen to explore ideas proven to be better. Once we found a better solution of a particular design problem, I cycle through all the phases from sketching, use cases, layout design, to prototype validation and I adapt all connected design assets.
Appropriate design toolset is helping me to stay effective, even that sometimes I just need to throw away some pixels and replace them with better ones. That just comes from accepting prototyping as a continuous activity, not one time only deliverable.
With this article series, I am also trying to demonstrate the value of design process. Including prototyping as a continuous activity is a much cheaper way of building products than investing in code re-works once the feature is already implemented.
Liked it? Please recommend it or continue with Part 2 — Project Repository.
