Agile and UX and Covid-19, Oh My!
Introduction
Like most UX Designers I prefer my portfolio entries to look polished and professional, showcasing my skills and experience. However, this time I decided the focus should be different. Instead I’ve focused on how UX, together with Agile methods, can adapt to remote working. Collaboration technology is important of course, but of equal importance is the application of core design thinking principles.
Consider this case study as one example (of many) that describes how UX can work with Agile methods while accommodating the challenges of remote working.
COVID-19 is re-shaping our world.
Problem Statement
The mobile hand-held computers and Apps used in warehouses across the UK by this client were old, no longer fit for purpose and their maintenance contracts due to expire. A new scaleable solution was needed that also included the functionality required for post-Brexit exports to EU and Northern Ireland.
The above problem statement doesn’t really capture the magnitude (or emotion) of the challenge facing the team so, with some artistic licence, I created the storyboard below. The main points are accurate but I’ve changed the individuals and scenario to protect client identity…
Design is communication
How many times have designers shared a design deliverable (e.g. persona, user journey, wireframe, prototype) for feedback, only to receive muted or vague response like, It seems to be OK? Does this mean your target audience hasn’t understood your design? Maybe they simply don’t have the time to spare for review and “trust” you to do the right thing? Perhaps the way you have communicated your designs is just too confusing. After all, not everyone understands personas, flowcharts, state diagrams, wireframes (with placeholder content). Then there is context. Without a frame of reference some shared background and understanding, it’s really hard to evaluate or relate to any design deliverable. So in the absence of critical feedback users offer polite commentary on aesthetics, “I like the looks of that” or “nice icon!”
If the design feedback I receive is mostly “polite” rather than how things work, I know I have a problem as a designer. It’s my responsibility to communicate design and help team members, stakeholders and users understand so they can validate.
… But design deliverables are not the solution
So while I do believe in good communication, design deliverables are intended to be used for improved understanding, obtaining feedback and supporting validation. Design deliverables themselves are not the solution. Often a lot of time is spent making design deliverables pixel perfect with heavy emphasis on branding, graphic design and style. I’m not saying visual communication isn’t important. However, spending too much time on “eye candy” is perhaps the not the most efficient use of scarce resources. I believe what’s more important is the thinking behind the design deliverables, what you have learned and why?
Video Walkthroughs
It’s hard to communicate everything you would like in visual or written form. Diagrams are abstract presentations and require effort to understand and text takes a long time to read and appreciate. This is where annotated audio and video walkthroughs can be very helpful.
On this particular project it was hard to get everyone together at the same time, so I decided for all of the main design deliverables (user journeys, wireframes, storyboards, service blueprints, prototypes) I would annotate the deliverable with short (4-10 minute) video walkthroughs. These “show-and-tell” involved me stepping through designs, describing the context and why I arrived at this conclusion. I included commentary of things I dismissed and why. I also communicated any outstanding questions I had. These short videos were specifically designed to provide all the context needed.
Rarely was it possibly to get all team members, stakeholders and target user together at the same time. However, most would almost find time to watch a short video and understand and give me feedback, usually a quick Slack comment.
I recorded all videos using Camtasia and published to the same secure link using the integrated Screencast.com service. I shared individual links to videos, but the team always knew where to find them so often checked-in to review the latest from the library. Later I found stakeholders appreciated how by watching a short 4 minute video they obtained a sense of progress without having to read lengthy documents.
Integrating UX with Agile
Every client I’ve worked for has their own version of Agile methods. Agile purists sometimes object to the notion of up-front design, often called Design Sprints or Sprint Zero. Complaints I hear include, “this sounds too much like waterfall” or “the designers are doing their own thing again!” . My response is, design sprints are just like “regular” sprints but their output isn’t production customer ready product increments, but instead research, pre-visualisations, simulations, prototypes that have been tested and validated (usually by target users). In other words, they reduce risk.
For me, I’ve never been able to do all the UX design from scratch with the current “development” sprint. I personally find it too demanding , hats-off to you if you can! When developers ask me, “do you have screen designs?”, “how are we displaying errors?”, “what are the font sizes, CSS?” or “how do we navigate between screens?” and I don’t have an answer, usually a mild panic sets in! What options do developers have if UX don’t have answers? They can continue hoping for the best but this risks a lot of re-work. Alternatively, developers can report (usually at the next standup) that they are “blocked” waiting for designs. This is why I try and stay at least 1-3 Design Sprints ahead of the current Development Sprint. This way I avoid being shamed during a standup.
Staying 2 sprints ahead doesn’t mean all my time is spent in Design Sprints. I usually have responsibilities to ensure developers have everything they need during the current Development Sprint. This can include graphic assets, icon, different adaptive layouts, branding, content support (and anything else not yet research, prototyped and tested).
UX and Agile – My Workflow
Here is an example of integrating UX with Agile using Design Sprints, the process used on this project. The Design Sprints can be really short, 1 or 2 days, or take up to a week. The point is they happened all the time. They typically start with the Product Backlog and rapidly go through Design Thinking stages (Understand • Ideate • Prototype • Test). The intent is to evaluate the requirements (Backlog) and potential solutions before development begins. This means delivering something e.g. a prototype, process flow, service blueprint, etc. that can validated (prototypes are “experienced”), via testing to confirm are we working on the right problem and have a potential acceptable solution.
The remainder of my comments here are restricted to the Design Sprint phase, where most of my UX involvement typically occurs. Of course there is UX needed during the Development Sprint and I’m always involved, but rather than me describing this here, there are several online resources where you can learn more including: https://www.atlassian.com/agile/scrum/sprints
Design Sprint
On this project I was responsible for the running of each design sprint with the support of the Project Manager and Product Owner, especially when coordinating calendars and scheduling meetings.
I never once set foot inside the clients’ offices during this project. Collaboration was mostly done using Slack (https://slack.com/intl/en-gb/ ) and occasionally SKYPE or Teams (https://www.microsoft.com/en-ww/microsoft-teams/group-chat-software ). Prototypes were developed with Adobe XD (https://www.adobe.com/uk/products/xd.html? ) and many flow diagrams and Service Blueprints created with Overflow (https://overflow.io ). Video walkthroughs and explanations were recorded with Techsmith Camtasia (https://www.techsmith.com/store/camtasia?) and Screencast.com. Research Interviews and testing achieved via screen sharing using Slack. Occasionally the Product Owner was on-site at different depots across the UK and moderated these face-to-face (social distancing and Covid-19 precautions observed).
Design Sprint notes
To start a Design Sprint process I would attend a a virtual meeting (usually Slack) with the product owner and sometimes a business analyst. Selected backlog items would be discussed sharing everything known about them. This included descriptions, videos of related warehouse activities, any detailed documents available. The goal was a clear understanding of the problem and agree a next step.
| 1 | Product Backlog (features) List of features with descriptions usually in priority required in the end product. |
| 2 | Select Problem One or more backlog items are chosen to be worked on in a Design Sprint usually by the Product Owner with support and input from end-users and the development team. |
| 3 | Brainstorm Ideas Typically this involved me working independently to sketch concepts, draft wireframes or process flows. The goal at this stage is to test I understand the problem correctly and suggest some ideas we could develop further. I would often record a video walkthrough of a sketch or idea. This worked as most team members found time to watch before the next meeting. Anything produced was shared in the project Slack Channel. |
| 4 | Pick (idea) Based on feedback from previously shared ideas (via Slack response/message, or Slack meeting) the go-ahead to explore ideas given, (or refined/rejected). Often alternates would be suggested. |
| 5 | Prototype (idea) This is when detailed prototypes were created. Alongside these any other design artefacts were produced e.g. flow-diagrams, user journeys, service blueprints etc. The intention is to create something that would enable end users to say “yes that would work” or rejected for some reason. Either way a lot of additional information, requirements, constraints and opportunities are discovered. Any prototypes are shared with developers for feedback before end-users viewed them. I was keen to only share what could be built. Also developers often had quicker faster and better ways to achieve a solution. I constantly reminded everyone I don’t have a monopoly on good ideas. |
| 6 | Test (prototype) The prototype was tested with end users, Product Owners and stakeholders. Observations made and recorded. This was as formal as a usability test but almost always was scenarios based the users would recognise. For this reason real (or realistic) content was used. |
| 7 | Re-define Problem The results of the tests often revealed what we thought was a requirement (backlog item) simply wasn’t a needed. Sometime it was such a low priority (to users) it was considered a nice to have. Other times users would be confused and couldn’t relate to how this would be used in their day-to-day job. So not everything works. This is another reason why Design Sprints are so valuable. It’s better to discover this earlier rather than later and expensive resources consumed developing a solution not needed. |
| 8 | Approve (the prototype) If the prototypes were approved they become ready to support the Development Sprint. Developers could review them well ahead of Development Sprint Planning. Often part of the decision criteria when selecting backlog items for sprint planning began with the question, “do we have designs for this?” Not everything needed designs to start a Development Sprint of course, but in most cases if designs were available, it was much easier for developers to be more productive. |
| 9 | Approved Backlog Items For each backlog item “approved” during the Design Sprint there now is a rich set of design artefacts including prototypes, wireframes, videos, process flows, service blueprints ready to support the Development Sprint tasks. |
Design Sprint Examples (deliverables)
What follows are example Design Sprint outputs (deliverables) created for this project.
Client confidentiality prevented me from sharing links to interactive prototypes or videos.
Example – Hub & Spoke Navigation
I often find it’s best to try-out a complete design sprint on a problem that is easy enough to tackle so we can iron out the process without struggling on hard design problems. This is how you find out what works and what doesn’t. It turned out navigating around the current legacy solution was particularly difficult. Lots of screens and sub-menus. It was very easy to get lost and hard to find your way back.
So the first Design Sprint ( duration 2 days only) involved going thought all the steps described above. These of course follow traditional Design Thinking Methodology:
- 1. UNDERSTAND – Initial kick-off
- 2. IDEATE – Hub & Spoke Concept sketch
- 3. DECIDE – Team approval
- 4. PROTOTYPE – Adobe XD Prototype involving 3 or 4 screens including video walkthrough explanation
- 5. TEST – Users either viewed video or the prototype and communicated feedback (if not observed real-time). In parallel (before sharing with end users) the development team confirmed technical implementation was achievable.
Example – Service Blueprint
It was a challenge for end-users and stakeholders to relate to front-end activities. Similarly the front-end development team needed to understand which API calls to use to support the UI. We needed something that connected different touch-points for the business, developers and technical architects. A Service Blueprint was the answer. Separate video walkthroughs and detailed descriptions of each node on the blueprint were also published. This one document enabled the business to validate the process-flow was correct, developers to understand where the UI was needed and why and technical architects to understand and develop the API calls needed.
Example User Journey
Example – Storyboards
Example – Prototype (screens)
Example – Onboarding (screens)
Theses onboarding screens were not included in the original MVP release. They were intended to provide a one-stop-shop for onboarding new users. They are intentionally simple and use visuals extensively. This is particularly important when English is not the first language.
Alan Trow-Poole's Portfolio 
Leave a Reply