| title | author | image | tags | redirect_to | |||||
|---|---|---|---|---|---|---|---|---|---|
SN Team’s first “design” sprint |
CsabaPeter |
../img/posts/design-sprint/sn-teams-first-design-sprint.jpeg |
|
Recently I got a new task which was to rework our admin UI.
Our admin page is quite clunky and is hard to work around. The main navigation is the BFT (aka the big fucking tree) which can be overwhelming if you’re not familiar with the folder structure and can give you a hard time.
We decided that we should give it a new look and make it easier to navigate around the admin system so it will save time and will be a much pleasant experience to work with it. The only thing was… it’s pretty complex and as a designer I haven’t worked with it so I didn’t know the real depths of the admin system.
Long story short after a few days of thinking how I can solve this problem and that wasn’t an easy task at all. I was stuck and basically had no idea how to start the whole redesign thing when there was so many things to consider. That’s when the lightning of idea struck. Let’s do a design sprint!
After talking with the team members and they were down to do the sprint we started the preparation with our PM.
Since it was our first sprint we heavily relied on Jake Knapp’s design sprint methodology. Me and our Pm who was the facilitator throughout the sprint started preparing for the week ahead of us, read through a mountain of articles and videos of best practices what should we pay attention to etc… and there was Monday morning.
On Monday we went through the problem we were facing which is how can we simplify the admin page so it can be used faster and easier. After we set the goal, got through the map, asked the experts (people in the company who are using the admin site on a daily basis). By the end of the day we indeed got an idea where we should put our focus on which was that we don’t need to show the whole tree structure all the time because people who use the admin page just didn’t need it.
After we picked the target it was time to focus on how we can solve the problem. We got through the lightning demos where we checked out how other companies solved this problem. Then we sat down to draw our solution sketches which turned out really solution sketches in the most literal way.
Because I’m the only designer in our team the sketches the team made were mostly focused on one single thing like query building, tree structure vs breadcrumb etc.. but it was very helpful for me as we moved deeper into the midst of the sprint as I was able to understand better and better how should we improve.
We have a bunch of solutions! Yeeey!! Now it was time to choose the best ones. We critiqued every solution and in the end we did came up with three winner solutions. After that we started the storyboarding session which ended up with no story board at all 😀 but it was even more beneficial than the sketches in Tuesday in terms of the team really got on the same page what we should do. It was long and exhausting but none the less very beneficial brainstorming where the team went through and over and very deep into every little detail. And it worked!!!
So no storyboard but a pretty solid plan on what we should do on Thursday.
Prototype time! This day was a bit strange in terms that in the sprint it says that the whole team should participate and no coding is allowed. Yeah right.. just try to do that in a team of developers. And as everything else in this sprint, worked out for the better in the end.
Me and my front-end developer teammate were the guys who did the prototyping. I did my part in Adobe XD and he did his in HTML so we ended up with two prototypes simultaneously which were pretty low fidelity. Again, it was against the sprint rules but seriously who gives a damn at this point after we improvised and tweaked here and there already.
We decided that we will prototype a scenario where the tester needed to find a file a few levels deep in the folder structure. I did the part where the tester could only find the file as he clicked through the structure. We decided that we wouldn’t throw out the whole tree structure but show only the relevant part of it to the user.
The other prototype looked the same but the tester had to use the search bar and try to find the file typing.
Friday Funday Test day! We recruited 8 people to test out the prototype and after the tests it was pretty clear that we are moving in the right direction. The testers liked the new interface although it’s far from everything you can call done and both of the search methods were clear to all of them and they told that they could benefit from the new admin site in their day to day work after it gets done.
I can call this first design sprint a success and it showed that we are on the right track resolving the problem although the real work will just begin. We’ll do a fully functioning high fidelity prototype and after another round of testing it can be implemented into working code.
To all other designers who are the only ones in their team and on the fence about conducting a design sprint. Go for it! Improvise, bend the rules a bit if you have to (we’re creative people after all) and have fun. You can help your developer teammates to have a little more insight about what you’re actually doing as a designer and you will appreciate more their work as well.
A design sprint can really improve the workflow, communication and creativity among the members and nonetheless it helps to get the whole team on the same page.
Thanks everyone for the read! See you all in the next one!