User Experience Design… the iterative steps…

Posted by on May 30, 2013 in User Experience Design | No Comments

I know that this has been written down a thousand times but the notes here also comes from my perspective of UX design working for a large corporation with a development team split across multiple sites. This means a lot more groups to involve, a lot more iteration and treading carefully when ‘politics’ arises. Often, cross-site communication means being very specific when putting together guidelines and making sure that you and your team are aligned and available to answer questions. Communication is always key. Let the fun begin.


Meet with the project stakeholders; discuss high level project goals, supporting business goals, desired time-frames and identify Subject Matter Experts (SME) and ‘friendly’ customers who may effectively represent the targeted end users.


Identify key terms or any terms that may cause confusion and work with stakeholders and SME’s to agree on the definition to be used within the project. Often it is best to work on the definition rather than the actual word. Focus on the actual word can cause a delay during this. Once definitions are agreed, any contentions word can be replaced with placeholders during discussions (it’s better that people ask ‘what’s that’ than make assumptions).


Identify and develop the target personas (and persona transitions – most people don’t keep the same job forever). At this point, preferably include actual customer (or SME) interviews rather than invention.


User goals should be identified based on the user stories and the early interviews. Workflows (i.e. what the user needs to do right now, not the proposed solution) should also come those interviews and be based around those goals. Depending on the complexity of the area, follow-up interviews may be needed to correctly identify those workflows.


Often the best way to get the early ideas flowing is to get the team into a room with white boards, pens, sticky notes and pre-printed base layouts. Then get sketching the ideas. Some target platforms such as phones can make particularly effective use of the large format sticky notes as they are just about the same size as a smartphone.


Map out the relationships between the main and subsidiary information presentation/gathering areas (pages, dialogs, etc.). At this point there should also be notes around how information transitions (e.g. a selected item, some entered data) through the system and what key information/actions would be available in each area. Use of card sorting, affinity diagrams and experience/familiarity with the problem space are effective techniques to make use of here.


Produce wireframes to effectively communicate how the user will navigate and interact with the design. Include enough detail to be able to talk around the design but not so much that the result will mean discussions around fine details such as colours or graphics. When working with remote development groups a lot more information and detail will be needed. Tools such as Balsamiq and Axure can really work well at this stage.


To carry on the communication and inspire the teams and stakeholders; getting together some prototypes and pictures of how things will really look. This is normally the point at which everybody starts to feel that the project is “real”. It’s time to get to work in the development tools, Photoshop and Illustrator.
Don’t forget the brand identity.


As this point, the feel for the graphical look will be determined ready for the style guide. Between this phase and the production of the style guide the graphics to be used within the application will either be commissioned or produced in-house.


In order to make sure everybody stays with the same vision, a style guide will need to be produced. The detail level needed here depends, to a degree, on the size of the teams. The time invested in this reference will be recouped later in a reduction of emailed questions. The style guide will need to include visual, layout and graphical design cues and should be treated as a working document – as questions arise, answer them and include them in the guide.


All the way through, there should be check-points where formal or informal reviews are conducted to make sure everything stays on-track. As soon as something that can be user-facing is ready – work to get it in front of some users and get some feedback.


It never hurts to get as much feedback as you possibly can. Keep iterating.