A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want, and why they want it. User stories follow a simple format:
As a [type of user], I would like to [do something] so that [a specific outcome is achieved].
While a great number of engineering and product management teams are using User Stories, they often focus on only the first two parts: WHO would like to do something, and WHAT they would like to do. The WHY gets forgotten. I work with my teams to make sure we're identifying the entire story so that our solutions fulfill the needs of our users.
“Styles come and go. Good design is a language, not a style.”
Storymapping is a top-down approach of requirement gathering and is represented as a tree. Storymapping starts from an overarching vision, which is achieved via goals. Goals are reached by completing activities. To complete an activity, users needs to perform tasks. Tasks can be transformed into user stories for software development.
Through brainstorming sessions, I guide teams in gathering requirements, and then group them into larger themes. It helps the team prioritize the work into sprints when the relationships between features have been mapped out.
“If I had asked people what they wanted, they would have said faster horses.”
I have a variety of tools in my designer toolbox. These are a few of the ones that have become favorites over the course of my career.
The ability to sketch is a core design skill. While a lot of designers jump immediately to pixels and comps, I see an enormous amount of value in generating initial ideas with paper and pencil. The advantage of sketching when designing with Agile engineering teams is that it's a quick way to make sure everyone is on the same page about what we're building. It's a low-investment way to talk through the team's ideas, allowing the team to quickly identify the solutions that won't work as well as those that will.
I have a sketching kit that I've built over the years, filled with grid paper, markers, pens, pencils, erasers, and post-it notes. I am always happy to guide a team of designers, product managers, and engineers through sketching sessions that will help our team further discussions about the products we're building.
Wireframes come in when we have a good idea of the direction we're headed, but we need to do some work defining the information architecture of the product, site, or page. They're "skeletons" of the actual user interface, usually in grayscale and relying mostly on simple shapes to communicate layout ideas.
For me, the wireframing and prototyping steps often go hand in hand, because I prefer to get ideas in front of users for testing as quickly as possible. For this reason, I try to make my wireframes as close to "real" as I can without compromising the low-fidelity spirit of this phase of design.
I have a great deal of experience creating high-fideltity comps. I prefer to work with existing UI kits or partner with a visual designer rather than create them from scratch myself. While I've certainly created original UI kits in the past, these days I feel that there are a number of extremely talented visual designers who can do that work much faster than I can. To create high-fidelity comps, I use the "lego pieces" created by visual designers and suggest modifications those UI elements when the existing assets don't achieve the needs of our users.
Prototypes are useful for walking through the user's path through your product. They're very helpful for identifying gaps in the design, as well as for putting in front of users for usability testing.
I have experience with a variety of prototyping tools and techniques. My favorite prototyping tools are Balsamiq, Axure, and InVision. I've conducted user testing sessions with interactive prototypes and old-school paper prototypes. I've also partnered with motion designers to demonstrate animation interactions when we need to get executive-level buy-in for our product direction.
I have several years of experience gathering user feedback from current and potential users of the systems I've designed. I've conducted usability studies on my own, and I've also been lucky enough to partner with user research experts. I prefer not to be responsible for collecting sophisticated metrics on the performance results, but to instead focus my reports on the qualitative learnings from our studies. The feedback I've gathered has included user interviews, focus groups, and individual usability testing sessions. I've used clickable prototypes, paper prototypes, card sorting, and product walk-throughs and demos as ways to guide the conversation and discovery.