Outcome
I led the product delivery team to create software that was fit for purpose using lean methodologies. My role in the beginning was to teach my team and stakeholders how to run design sprints and guide them to the process. At the beginning my role was really hands on, helping with almost all the activities in the design sprint but with time, my team got a hold of the process and they were running with it, which allowed me to detach a bit from it.
The biggest win was to get a really big team working together harmoniously with a common goal, which in Canon's complex environment was daunting and seemed far-fetched.
High Level Process
Just as I did in ‣ with the ‣ and Gavelytics with the User Centred Design process I followed. Canon was not too different, only better. This process is a continuation of the work done in Product Strategy.
Design and Development Sprint Process
At a very high-level, this is how the Design and Development process looks like. Design and Development Sprints running in tandem. Sprints lasted 2 weeks and take ambiguous roadmap items as input.
This process is my own take on Sy and Miller’s “Staggered Sprints” model.
What is the product of the sprints?
As mentioned before the purpose of a Design Sprint is to take an ambiguous roadmap item and convert it through its processes into a design and development specification.
Then of course, the purpose of of the Development Sprint is to convert that Design and Development specification into tested working software features.
To reduce the risk of producing foul software we test during both, the design and development sprints, this will help identify flow gaps and reduce user friction before creating the spec, and at the same time the development sprint is tested for logic and runtime bugs to make sure that the outcome of the effort is optimal.
Low Level Sprint Process
I have already showed you what the Staggered Sprint approach looks like at a high level. Now let's deep dive into the details of what happens in the design sprint.
- Day 1: Defining Scope – Scoping the problem we are trying to solve
- Day 2-3: Co-Design – Defining the solution
- Day 4-8: Iteration – Testing the solution and refining it.
- Day 9-10: Spec – High-fidelity wireframes and user stories
Now let's get into what happens each day during the two week design sprint. And for the scope of the exercise I'm going to focus on what happened during sprint 1 only.
Day 1: Defining Scope
Preamble – Roadmap
Our Product Strategy session produced two things from wanting to merge Canon's brand website and the e-Commerce site:
- A User Story-Map and a,
- Sprint Sequencing Diagram
First we sliced up the User Story-map into logical/functional sections.
Then we named those logical/functional sections.
Having produced the whole map first allowed us to see the big picture, and segmenting it allowed us to see a more narrow scope of work without fear of getting tunnel-vision while designing.
Understanding As-Is
Prior to our first workshop, as we moved into the first sprint, we took the section of the map that was labeled Sprint One: Category and Product Subcategory Pages.
Since the overarching goal of the website is to blend to websites together, we looked at the look and feel of both as well as what information they held at that point in time.
Below are examples of Product Category Page Example in Both Sites
The exercise of putting it all together, the section of the story map, and examples of what we currently had and what we wanted changed, would help the whole team get in the same page during our first workshop of the sprint.
Discussing To-Be
Our first workshop of the sprint was the Scope workshop. It typically lasted anything between 30 minutes to an hour.
Agenda
- Discuss the Design Problem
- Walk through the User Story-map section
- Discuss the Goals for the Collaborative Design Session
- Discuss Design Considerations
- Look for what's missing
- Ask people to think of how others are tackling the problem
Design Problem
We set the scene for what the big-picture problem we are trying to solve. This main goal didn't change much from sprint to sprint, but still had to be said, as participant stakeholders changed from sprint to sprint.
How can we merge all content in the e-commerce and brand site so that it doesn't look crammed or too busy.
Goals for the Collaborative Design Session
Goals for the collaborative design session are more narrow than the overarching Design Problem and are aimed to give the participant stakeholder enough context in the sprint workshop sessions to follow, including co-design and vetoing sessions. These goals were facilitated during the session. For example:
- Be able to display Canon range of product categories in an user friendly way.
- Lead users to the right product for them in as few steps as possible.
- Explore how can we promote products or content at a higher level.
- Allow for users to drill down into each product category.
- (Optional) cross navigate subcategories
After this was done, these bullet points were transformed into a use-case story that covered all the angles that we wanted people to design for in the collaborative design session.
Design Considerations
Design considerations are things that came up from the Product Strategy session that were true for all different touch-points.
- Pressing our Advantage (This meant something to Canon People)
- Focus on Local Community Engagement
- Closed loop engagement and re-engagement
- Email Automation
- SEO Optimised
Day 2: Co-Designing
In order to explore a wide variety of designs, I run Design Studios. Design Studios are time-boxed, collaborative sketching sessions that allow stakeholder participants to talk about their individual point of view without creating groupthink (a psychological phenomenon that occurs within a group of people in which the desire for harmony or conformity in the group results in an irrational or dysfunctional decision-making outcome). The workshop is held as follows:
Agenda:
- Reviewing the work done in the scoping session the day before.
- Getting participant stakeholder comfortable with the sketch quality required (this is being able to draw boxes, lines, stick figures and other doodles.
- First round of individual sketching.
- Presentations to the other stakeholders.
- Second round of invidual sketching taking ideas from the first round.
- Second round presentations.
- Summary of high level of patterns.
Below you can see examples of how the rounds of design went.
1st Round
One or two pages per participant.
2nd Round
One or two pages per participant too, here you can see how participants ease into drawing and into the exercise, as compared to the first round. Also, patterns start to emerge.
A co-facilitator in the sessions, the Product Manager in my team, figured out that doing some of the note taking, in the form of a storymap, as the presentations were taking place, was useful to save time. So we enhance the process with this little nugget for the following sprints.
Day 3: Consolidation
Consolitdation is a 3 pronged approach:
- Finding design patterns in the second round of design,
- story-mapping the patterns, and features and,
- creating a wireframe after the story-map session
See the examples below:
Pattern-Finding
Adding markup or overlaying text with different colours over the different aspects that appear in the design helps finding those common elements across all of them. In the example below, you can easily see how stakeholder participants can think about the same solution in different ways, as they have different mental models.
The Seniour UX Designer in the team had a really good idea, which was, naming the patterns, and also duplicating them in a different space to see the frequency each concept appeared on each design. This too was included in the process for follow up sprints.
Solution Story Map
A solution story map is a tiered conceptual description of the product's architecture.
The structure is the following:
A page (a blue sticky note) has multiple sections (green sticky notes). A section has multiple features or details (pink sticky notes).
This particular layout is really useful as it allows you to sketch out a paper prototype or other kind of early design, by looking exactly at what needs to be included and not only track progress, but also walk others through the design. Which is the next step in the process.
Low Fidelity Wireframe
The following sketches then are produced in the most cost- and time-efficient form with the intent of soliciting early feedback from three kinds of groups, stakeholders, SMEs and most importantly: actual users.
The three wireframes above reflect the structure from the story-map produced ahead of the wireframes.
<aside> 💡 The last little square is not displayed to proportion. It was done much bigger with the intent of adding as much detail possible as it was a critical part of the design: A list element from the products list.
</aside>
<aside> 💡 Designs displayed here are a combination between digital and hand-drawn sketches, which made our Senior UX Designer move faster with the low-fi wireframe. The best of the digital and analog world.
</aside>
After getting internal feedback, we used these wireframes to test with actual users.
Day 4 - 8: Iteration
The goal of the iteration days is to get a better understanding on what doesn't work from the prototype and fix it.
To do that we set up a T-prototype in invision that consisted on screenshots that worked from the actual product and sketches of what we changed.
During this process we did the following activities:
- Created a screener
- Booked suitable participants for a remote usability testing session.
- Documented the results in an online board.
Remote Usability Testing
When designing we had really specific goals we wanted to accomplish with the design. We placed those goals next to the wireframes when we asked for stakeholder feedback, and we also used those same goals to create tasks and jot them down in a semi-structure usability test.
Rapid Iteration
We ran usability testing sessions with at least two people in them, to make sure that note taking was thorough. Notes were then organised in the same way as with the Solution Story-map was.
There were two kind of notes: usabilty issues and feature ideas generated mentioned by the participants.
Day 9 – 10: Spec
During the last two days of the sprint the team focuses on two things:
- Writing user stories and
- Producing High Fidelity Wireframes for desktop and moblile.
High Fidelity Wireframes
During the last two days of the sprint the team's Senior UX Designer worked tirelessly and did a fantastic job getting the High-Fidelity Wireframes that represented the sketches that we tested with done.
During the last two days of the sprint the team's Senior UX Designer worked tirelessly and did a fantastic job getting the High-Fidelity Wireframes that represented the sketches that we tested with done.
At this stage I also had the senior UX designer walk stakeholders through the wireframes with the goal of getting anything that we could have missed at this point. But since we have tested and reviewed the designs thoroughly, feedback is minimal or really positive at this stage.
Wireframes were linked from the Mural board to their counterpart in Abstract, where developers could inspect the wireframes to see measurments, heights, widths, font sizes, colours, etc.
User Stories
One of the nifty little features that our digital board mural sports, is the integration with JIRA. Which meant that our Product Manager could create user stories using our current story map.
User stories were then reviewed by the tech-team for completion and to acknowledge their understanding. Which was the last step of the design process.
Change Spec Boards
Through all this process, we created Sprint Boards in Mural, which encompassed the whole design process from beginning to end.
These documents resembled the walls in a crime-scene investigation office, where invesigators had everything they needed to capure their perp in cotext.
But instead of being a crime-scene investigation office wall, it was a sprint, and instead of perp, was design, design rationale notes, feedback, user stories, etc. which was really well welcomed by the developers.
"This is the time that we've received the designs that has been most useful. We can see everything we need to develop in the same screen, and since we've been involved from the beginning in the discussion, we already understand what it is about, which makes the hand-off a really easy" – Lead Developer.
Every sprint we produced a different Mural board. The images below contain 5 consecutive sprints we ran and complete a workflow.
As documentation go, change-specs are great. They are transcient pieces of throw-away highly contextual documentation, that happens during a short, time-boxed body of work such as a Sprint.
They allow to communicate easily with your team, and to get everyone involved and engaged through the SDLC.
More Examples of High Fidelity Wireframes
Other screens produced through the same process.
Key Learnings
The last thing that is worth mentioning is that we went meta with the whole process. We storymapped the design sprint to collect feedback from our core team (myself as head of product, a product manager, a business analyst, and our senior UX designer), and our stakeholder teams, including SMEs and development.
We mapped it the following way:
- Key activities are in pink sticky notes at the top
- Then we have process, three blue sticky notes that say
- Prep
- Execution
- Post
- And in yellow next to them we have the particular things that happened to either Prep for that activity, execute it or do post work.
- The green sticky notes are postive things that were said by either group of people
- The red sticky notes are things that we could have done better (we definitely paid more attention to the negative).
- And lastly in purple we have ideas of what we could in order to make things better.
As you can see there are far more stages here than the ones described in this entry. This is because we wrote down feedback relating the development process.
