One week – fast UX design
Context
A client needed a feature implemented immediately.
Challenge
We had one week to design, test and write the stories so the developers could pull this epic into the next sprint.
Stakeholders
- The client
- Client services
Monday – fast ramp up
On Monday we found out about a feature that had risen to immediate development status over the weekend. We got the feature and business requirements doc, then walked through with client services to clarify questions.
Our team ideated quickly and got the basic UX worked out. I immediately drew up wireframes.
Tuesday – fast fails
On Tuesday we did an in depth design sprint. Immediately we identified a big requirement gap in our design. Our question set was not “twin proof”, so we added an email address field to fix this glaring error. We also failed fast by experimenting with the language and drawing ideations of a strength status bar. Eventually we came to the conclusion that the bar was really only needed when the user was making an alternate question combination.
Wednesday – Internal feedback
I made a quick mockup in sketch that I could show to internal stakeholders to get feedback on our design.
Upon seeing the design mockup, one of the stakeholders realized that there was no explanation of this complex UX. We added a big helper text block, because this was a concept unique to our system that people would not be familiar with. We changed the mockup in real time, editing copy to make it as concise and explanatory as possible.
During this interaction we also came to the conclusion that the status bar was not MVP, so we took it out. Instead, We added a simple red text answer to make sure the user understood why the save button would not activate.
I spent a few minutes with the stakeholder identifying and drawing up a simple contextual help solution that made the UX clearer.
Thursday – client feedback
Client services needed to get feedback from users right away. I gave them pngs they could use to get immediate feedback from the clients who asked for this functionality.
Friday – scope reduction
A basic version of this feature needed to be pulled into the upcoming sprint, so we had to reduce the scope of our design. We did another design sprint and reconfigured the stories to reflect a reduced question set that would pass as MVP.
Two weeks later
At the next sprint review we got to see the new feature in code. Sometimes things have to be done quickly. It is good to have a responsive optimistic team that can switch to all hands on deck, dive deep and design a surprise feature for immediate implementation.
