Since the rise of the commercial web, I have been intimately involved with all aspects of internet design & development. I have also been immersed in mobile application design/development since 2008. More recently I have accumulated 2.5 years of experience in Augmented Reality design/development, a natural extension of my impressive web, mobile and user experience design career path.
“It’s difficult to make UX and Agile work together, and if you’re a UX person struggling with Agile, you’re not alone. Typical Agile processes don’t take into account the time, resources, and scope that UX people need in order to deliver user-centered products. Despite that, UX and Agile can coexist well, provided that (1) the organization’s management understands and supports UX work, (2) UX practitioners display leadership and spend time on outreach their colleagues, (3) the Agile workflows are flexible enough to accommodate the needs of the UX, and (4) UX people are part of the product teams, where they can build respect and rapport with developers."
Before a successful product can be built, its context for existence must be understood. Getting all stakeholders together to work as a unified team towards the same goal is essential to success. The ideal team will include reps from all relevant functions/all levels within the organization such as sponsors, senior managers, marketers, designers, developers, CSRs, sales, user support, etc. The ultimate goal is to ensure that they’re all aiming in the same direction.In this discovery phase, the team strives to “uncover” all the knowledge of the problem to be solved. Sometimes it's helpful using an external facilitator - one whom can ask questions necessary to help people stay focused without anyone in the team having to lose face to do so. Ideal components of this phase:
Once defining is complete and everyone is on the same page, it’s time to split the team up and get started working on solutions. Sketching is an individual effort. Everyone is tasked with coming up with a detailed solution to the problem. It’s best to do this on paper as changes are quick and not everyone is a master of the same software (wireframing) tool(s).For more complex or large-scale problem solving; it is best to break up the problem into manageable chunks and assign these chunks to individuals of the team. The overall aim is to get as many ideas down as possible. If the team is larger than usual, possibly generating numerous ideas – you might want to allocate an hour at the end of the day to quickly reduce the number of ideas to a more manageable number before you go into the next Sprint stage. Remember:
This stage is all about making a decision as to which idea (or ideas) you’re going to take to the prototype phase. However, there’s more to this than making a decision – it’s really about working out how your solutions may conflict with your objectives, abilities, resources, users, etc. Some assumptions to consider as you decide: Budget, Users, Technology Capacity and Business Drives.You should have an objective in mind during your review. Will you be looking to take a single great idea forward to prototyping or are you going to pick the top few and take them all forward to find out which idea resonates best with your users? Be looking to constantly refine the list and remove ideas that simply aren’t feasible early in the process or those that generate conflicts - which you will be tasked with overcoming with other ideas. Once you have the idea or ideas you should:
This is where the work gets serious. In a single day a lo-fi prototype is created that your users can test on the final day. The core goal here is for rapid prototyping of the idea(s). In tandem, the research team should be finalizing the testing schedules and developing the interview script for that schedule.Tools I use:
User experience requires user involvement. User testing serve as a validation of design, based on tests with real users. Ideally 6-20 users are brought together - one-on-one, they play around with the prototype. Everyone involved in a test should make notes and record what they feel they’ve learned. You want to take these notes and summarize them at the end of the day. This should help you decide what needs iterating and improving.The UX Process often has considerable overlaps and there’s typically a lot of back-and-forth. As the UX designer learns more about the problem being solved, the users and details about the project (especially constraints), it may be necessary to revisit some of the previous understandings or even try out entirely new design ideas.
When user expectations from the product are established (it’s clear what their goals are and how they like to operate with it), designers move to the “final” phase. An effective design phase is both highly collaborative, communicative and iterative - meaning that it cycles back upon itself to validate ideas and assumptions.The work doesn’t stop here. It’s important to understand that UX/UI design isn’t a linear process. Ongoing testing and design iterating is essential to ongoing success. As business goals change and as users habits change, so must (the solution to) the product. Tools I use:
© 2017 Neil A. Aalto.