User experience (UX) is an enigma to many developers, but is something I think developers should have a firm grasp on to excel as well as create apps that not only impress, but also work for (as well as with) the end user. Many developers do not understand the difference between UX and UI (user interface). UX defines how a user interacts with your application, whereas UI is the actual implementation of the patterns selected for the interaction. If UX is not considered in detail up front, I always expect several iterations of extra development resulting from user acceptance testing (UAT).
I had the unique opportunity to work with Will Evans and watch a master in action which really sparked my interest in user experience design. I don't have the opportunity to apply his overarching tenet that 'You are not the user' in full, I always keep it in mind when speaking with clients and while developing the UX for any app I architect.
A few important assets to understand in getting you started in UX are listed below.
User Personas
User personas were something that were uncomfortable to me at first. I was used to defining different types of users while architecting systems and agile user stories, but adding information like salary, education and age seemed uncomfortable at first. Properly defining descriptors like this help to develop usage scenarios. The user persona allows us to understand how a specific user will access the system, where they will access the system from, their technical proficiency and even if they need adaptive technology to overcome a disability. Also, being able to identify deeply with users really helps when creating stories and process flows. Performing user interviews really helps! So does observation of users performing their tasks or interacting with an existing application (if one exists).
User Stories
Much like standard application development, UX involves the creation of user stories. In software dev we generally build these stories by working with the product owner and their understanding of the system. During UX discovery it is a great idea to look beyond standard requirements and involve additional stakeholders, and EVEN MORE IMPORTANTLY: a sampling of end users. These user stories define not only a user's interactions with your application but also the process flows identified by the stories. Unlike Agile development stories, UX stories can be much more verbose, and also define personas within the context of the system.
Information Architecture (IA) and Content Inventory
For developers, this is a very familiar deliverable. Consider this a sitemap, but even more importantly, the hierarchy of how information is organized within your application. This defines how users will find information or services. IA is a huge topic in itself, and we won't be going into it in detail in this post.
Process Flows
Another familiar asset for developers, these flow diagrams are perfect for demonstrating user interactions for common system tasks. I like to create these as UML activity diagrams. Being able to walk a user or stakeholder through a workflow is very helpful and saves time in the longrun, especially considering how visual users are.
Wireframes
I'm pretty sure every developer has been in a client meeting at some point explaining some complex method of attacking a problem using a image, and the client turns to you and says, 'You know what, I think that shade of blue should be slightly darker, and perhaps the logo should be larger, and maybe we need a san-serif font here that blinks and ....'. Somehow they've entirely missed the decision they were supposed to be concentrating on and got caught up on ancillary topics. Wireframes are an awesome solution to this problem for a few reasons. Aside from just allowing you to focus on process and function over form, they are also simple to create and take much less time than full visuals. Wireframes allow you to develop experience and interaction first, managing visual design at the appropriate time once the processes have been clearly defined. Wireframes generally do not stand on their own and require annotations that call out specific details.
UX Design Patterns
I could dedicate an entire series of posts to UX patterns. Just like in software development, user experience designers have also identified common problems and sets of solutions that address said problem. By understanding the needs of your users by observation and interviews, you can apply the correct pattern (or work from a pattern) to provide a good experience. Yahoo! has a list of pattern libraries to get you started. I also highly recommend Martijn van Welie's pattern library.
Visuals
When creating high fidelity visuals (also referred to as comps) it is important to remember that you don't need to create visuals for the entire site. Generally you will have a few variations of pages that will need created. I still find lorem ipsum text important during this stage with some clients to allow to to focus on the proper items. Make sure the visuals tell enough of the story you are attempting to convey within the application flow. Many times this step is handed off to a visual designer, but ti is imperative that the UX designer remain engaged during this stage. Not always necessary, but important nonetheless, sometimes mood boards help define the artistic direction (especially when developing an entire brand experience). Mood boards can also be used to demonstrate design concepts and themes to a client before creating fully fledged visual designs.
Style Guide
A style guide is an important asset to deliver with your UX design. This allows developers to easily recreate your vision utilizing the correct hexadecimal colors and fonts. Creating a cascading style sheet is simple utilizing a style guide, and prevents developers from taking too many creative liberties with the design.
These are just a few assets to get you started. I have quite a few good examples of UX in action that I'll post depending on interest. If anyone wants additional information or examples on a single asset above, let me know and I'll wire them up.
Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts
Saturday, October 16, 2010
Monday, November 30, 2009
Living Agile: 90 Day Action Plan
So, in breaking out of the post summer slump, our board at Twin Technologies had the executive team create 90 day action plans. I posted mine, and was surprised at how comfortable it was to create. Then, it hit me.. 90 day action plans are just a form of Agile planning.
I've always kept lists of tasks on 3x5 cards as well as various text documents that become intertwined over time. Whenever I start to feel like I am not focused, I return to the cards and find something that seems high priority to me. As a Scrum Master, the correct path should have been obvious, but sometimes we are blinded.
A 90 day action plan is simple to create. I used a Google Docs spreadsheet as my platform:
1. Create a new spreadsheet
2. Create two tabs - Goals and Actions
3. List high level goals you feel you can accomplish in the next 90 days on the goals tab
4. Prioritize these goals
5. List high level actions for goals
6. Create small action "tasks" for actions you plan to work on in the current week
7. Track status (%) against done.
In each goal and action there is an identifier so I can reference between tabs. I also have a column for marking predecessor tasks. You'll notice that this is very similar to a typical Scrum project:
1. Create backlog
2. Prioritize backlog
3. Estimate high priority stories
4. Determine what stories in the backlog can be tackled in the next sprint
5. Create tasks for accepted stories and give detail estimates
6. Track status (%) against done
The same benefits exist:
1. Ability to point to what goals suffer if other goals become a higher priority
2. Ability to self organize
3. Detailed reports can be generated against status daily
4. Reprioritization and goal changes are encouraged and expected
These are just a few. It took me about 30 minutes to create my 90 day action plan, and I encourage you to spend 30 minutes trying it out as well. I find myself more focused and really getting things done!
I've always kept lists of tasks on 3x5 cards as well as various text documents that become intertwined over time. Whenever I start to feel like I am not focused, I return to the cards and find something that seems high priority to me. As a Scrum Master, the correct path should have been obvious, but sometimes we are blinded.
A 90 day action plan is simple to create. I used a Google Docs spreadsheet as my platform:
1. Create a new spreadsheet
2. Create two tabs - Goals and Actions
3. List high level goals you feel you can accomplish in the next 90 days on the goals tab
4. Prioritize these goals
5. List high level actions for goals
6. Create small action "tasks" for actions you plan to work on in the current week
7. Track status (%) against done.
In each goal and action there is an identifier so I can reference between tabs. I also have a column for marking predecessor tasks. You'll notice that this is very similar to a typical Scrum project:
1. Create backlog
2. Prioritize backlog
3. Estimate high priority stories
4. Determine what stories in the backlog can be tackled in the next sprint
5. Create tasks for accepted stories and give detail estimates
6. Track status (%) against done
The same benefits exist:
1. Ability to point to what goals suffer if other goals become a higher priority
2. Ability to self organize
3. Detailed reports can be generated against status daily
4. Reprioritization and goal changes are encouraged and expected
These are just a few. It took me about 30 minutes to create my 90 day action plan, and I encourage you to spend 30 minutes trying it out as well. I find myself more focused and really getting things done!
Wednesday, July 22, 2009
Monday, June 22, 2009
Understanding User Stories
I recently had a co-worker ask me the best way to go about creating user stories, so I pushed them to a presentation by Mike Cohn. The presentation listed the framework to be applied as well as some theory. The response was "Yeah, we know all that. How do we get the Product Owner to write the stories, or how do we help them write the stories?"
This got me to thinking and after an hour long conversation I think I have some ideas to share:
1. Scrum Product Owner Training is a must, but not always feasible depending on the client environment.
2. Don't expect to hand off the process to your Product Owner. Explaining the process in detail might excite some clients, and be off-putting to others.
3. Before the Product Owner and the Scrum Master know how the other works, I find it easiest to start with Feature Groups and work them down into user stories one at a time. Feature groups define the higher level items that exist within your project/product. Each Feature Group may then be tracked to show progress against requested functionality. Starting at Feature groups allows the Scrum Master to get the ball rolling and soon the stories will flow faster than you can write!
4. Don't Talk Tech! User Stories should be written to solve the 'What' and even 'How', but are not meant to define the underlying implementation. In most cases tasks will define the implementation.
5. Make sure the Product Owner and Scrum Master have time alone to prioritize the stories. Bluesky sessions with the extended team are very beneficial, but block progress on prioritization.
6. Ensure your Product Owner is empowered. If they are not empowered, the user stories process will fail. Prioritization will be undermined. Use the transparent nature of Scrum projects to determine and call out risks with the Product Owner.
7. Especially early on, write the user story framework down and refer to it often: 'As a ____ I can ______ so that _____.' Don't forget the 'so that' as that becomes imperative in the ongoing prioritization process as well as provides clarity for the team.
8. Don't insist that the Product Owner speak to you in user story form. Take notes as the Product Owner talks and then work with them to write the official stories. The process will improve as iterations pass.
Hopefully this helps someone out there who is struggling with a client who is new to Scrum, or who is having a hard time getting the juices flowing!
This got me to thinking and after an hour long conversation I think I have some ideas to share:
1. Scrum Product Owner Training is a must, but not always feasible depending on the client environment.
2. Don't expect to hand off the process to your Product Owner. Explaining the process in detail might excite some clients, and be off-putting to others.
3. Before the Product Owner and the Scrum Master know how the other works, I find it easiest to start with Feature Groups and work them down into user stories one at a time. Feature groups define the higher level items that exist within your project/product. Each Feature Group may then be tracked to show progress against requested functionality. Starting at Feature groups allows the Scrum Master to get the ball rolling and soon the stories will flow faster than you can write!
4. Don't Talk Tech! User Stories should be written to solve the 'What' and even 'How', but are not meant to define the underlying implementation. In most cases tasks will define the implementation.
5. Make sure the Product Owner and Scrum Master have time alone to prioritize the stories. Bluesky sessions with the extended team are very beneficial, but block progress on prioritization.
6. Ensure your Product Owner is empowered. If they are not empowered, the user stories process will fail. Prioritization will be undermined. Use the transparent nature of Scrum projects to determine and call out risks with the Product Owner.
7. Especially early on, write the user story framework down and refer to it often: 'As a ____ I can ______ so that _____.' Don't forget the 'so that' as that becomes imperative in the ongoing prioritization process as well as provides clarity for the team.
8. Don't insist that the Product Owner speak to you in user story form. Take notes as the Product Owner talks and then work with them to write the official stories. The process will improve as iterations pass.
Hopefully this helps someone out there who is struggling with a client who is new to Scrum, or who is having a hard time getting the juices flowing!
Subscribe to:
Posts (Atom)