Menu

Ux/Ui DesiGN Sprints

What a design Sprints looks like to me

Finding out what the real issue is

Planning the process
Planning is everything in a design sprint and being able to have the right people in the room to help contribute is key. I use Mural as a starting point for this, gathering as much information as I can about the current flow or 'problem area' as I can. This also includes talking to the people who are directly affected by the challenge.

User research
Surveys, focus groups and testing prototypes with customers forms the main focus of the beginning and the end of any sprint. Having user feedback at the start of the process can help discover the sticking points and inform stake holders of the 'real' issues. User testing at the end of the sprint irons out any kinks in the prototype and removes any 'guessing' or solutionising which is common when dealing with developers or teams not used to design research.

Journey mapping
How do we do it now and why did we do it like that in the first place? along with user research, finding out why things have been created in a certain way is also as important. Technical restrictions and understanding how a platform interacts with all of its components will have massive impact on what can e considered in the further solution. It can also influence change in wider infrastructure which has greater knock-on costs.

Ideation and prototyping
This is the fun part! The initial design phase is all hand rendered and based heavily on the research and user input. Using internal design groups to help shape and interpret the initial concept through to wire-framing and LO-FI visuals that can be forged into a prototype and tested through Maze or Userbrain.

Finally
Once I am happy with the performance of the product I would arrange a walk through it in a 'Des/Dev' session where I would show the development/stakeholder team how I would expect the product to look and feel in HI-FI loveliness. As we already have 'buy-in' from all teams involved at this point, its more of a case of removing any doubt as to how the product will act and work for the customers and the business as a whole. It's a chance to field any questions team members may still have and be on hand to answer any queries.

My Philosophy for teams
Collaboration is the key to get any kind of 'buy-in' on projects. I find that even the most difficult developer or stakeholder or whatever will become more enthused with a product if they have involvement at the beginning and, further along, at the right time. So many teams develop work in silo and then shock (in good and bad ways) the business when it is finally shown in its later stages. I work hard to remove as much of this as possible by using clear communication and not being afraid to review work at any stage with the team at large. It just makes sense to include the right people on day 1. Multi disciplined teams are the way to go!