Product Design in an Agile Environment
One of the most important aspects of designing thoughtful experiences is talking to your users and understanding their needs and existing problems. This takes an understanding of their context, thought processes, current workflow and intended task at hand or goals. But as a designer, how do you allocate the time to do this and still keep up with how development teams work, which is usually in some form of agile?
Over the years I’ve altered my design process countless times to keep up with today’s fast-paced product development (refer to agile) cycles, attempting to keep ahead to allow for more learning and understanding to increase chances of building the right thing. An example of an attempt to do this comes from a concept from the Lean UX methodology, which promotes the idea of putting less focus on deliverables and more focus on your user’s experience and validating assumptions. Yep, gone are the day’s of lengthy spec documents and countless versions of highly spec’d out, time-consuming deliverables that at the end only get stored away on a server somewhere.
We as designers need to change up how we can better integrate and adjust our processes to provide maximum value and quality for our users and at the same time keep up with the fast paced nature of agile. Below are some tips for staying lean when working with product teams and providing a quality experience. Keep in mind that every project is different and you will likely need to adjust based on un-controllable factors such as budget, deadlines, short sprint cycles, etc.
First, know what you’re working with
Every team works differently, some slower than others. The first thing you need to do is get a feel for how the team works. How large is the team? Who’s involved? Who are the stakeholders? How long are the sprint cycles? How does the team collaborate? Do they collaborate? What’s currently being worked on? What’s on the backlog? Getting a better understanding of the current landscape allows you to better map out how design can provide the most value for your team. Once you’ve gotten a grasp of how the team works, work closely with the Product Manager to plan out how you can work ahead of the team by a sprint or two (nothing less or more) and plan out how you can schedule and integrate research and other design activities into the process.
Research
I first want to state that due to the nature of certain external factors that are out of your control (i.e. users personal schedules), the research phase may take the longest (next to recruiting/scheduling for user testing) compared to any other step in the design process, but is absolutely necessary. When it comes to conducting research, you need to determine what you want to get out of it. The research methods vary depending on the stage of your product and what you’re trying to validate or understand. If you’re new to the team and just getting your feet wet, I’d suggest compiling as much existing findings as you can from the teams prior research and analytics (quantitative and qualitative), if any. Get to know the various personas and have that direct whom you reach out to when conducting your research. The main goal here is to completely immerse yourself in the understanding of your user. Go out and focus on how customers are working today within their environment. Understand their goals. Ask good questions, but initially, you’ll want to just observe. This is called a contextual inquiry. Be sure to notate your findings, but you don’t need to have extensive documentation. The initial research is to better understand your users’ day to day process when using your product, other products or some other way they currently work that may be improved. After several research session’s you’ll be in a good place to validate existing persona’s or build out your own and be better informed with your design decisions moving forward.
User Testing
In addition to research, user tests, such as usability testing, should be conducted throughout the entire design process, even after launch. You know the old saying, test early and test often — it never hurts to do this. Typically, I’ll test out flows, patterns, layouts and navigation during the sketch phase. This low fidelity approach keeps costs low and iterations fast. First, you’ll want to create a quick plan on what you’re trying to validate, whether it be a new feature or the navigation structure. Write out tasks that you’ll have the user go through and create simple metrics (i.e. task completion success, time on task, etc.) that validates the design or you can create a baseline to test against such as having the user go through the same tasks for a competing product and compare from that. I’m a firm believer that testing need not be complicated nor formal such as with expensive labs, the idea is to know what and why you’re testing and be able to determine whether you have enough insight to render the design that you’re testing the best approach to move forward with.
Sketching
The cheapest way to quickly churn out and validate concepts is to sketch. I usually tend to do this first, once I have an understanding of the project at hand and the business requirements and priorities for the particular cycle. I’ll start out with writing out userflows using the UI shorthand method. This gives me a better idea of the users workflow and allows for me to better design solutions that match them. This can also be used to match against user stories and formulate a flow. It’s also good when working with a team and talking about the users step-by-step interaction as it can get everyone on the same page.
Afterwards, I’ll sketch out a high level sitemap to get an overview of what I’m working with in regards to how each screen will connect and get a sense of the hierarchy. The navigation structure comes out of this activity most of the time as well. After the structure is composed I dig into each individual screen and flesh out the details such as layout and UI elements. Again, this is still being sketched. There will be times when you need to communicate and have discussions with your team, I’ll sometimes print out sitemaps created in Sketch and tape them to a wall or whiteboard. I still consider these lo-fidelity as it’s easy to iterate and make changes on the spot by writing on them.
UI Design & Prototyping
To work lean, you need to be proficient in choosing which activities need to be done given the project at hand and the state of the product at that moment in time. Most of the time, time is the constraint, especially in the startup world. The time constraint can apply to existing products and products that have yet to be validated in the marketplace. So let’s assume time is factor numero uno. What tool’s will you pull out of your design toolbox that will allow you to work quickly and still maximize the quality of your designs? I tend to go straight from sketch to medium or high fidelity designs to prototype. This may differ from designer to designer, however, this is where I feel I can work fast and allow for more time testing, validating and iterating on something that is clickable and can also serve as a replacement for the spec/requirements document that development uses to build from.
In regards to tools, I’ve switch from PS to Sketch about 3 months ago and will never turn back. I use Sketch for a majority of the varying fidelity of work I do from sitemaps to wireframes to hi-fidelity UI designs. Art boards, UI templates, asset exporting and Symbols ftw! For prototyping, InVision get’s the job done a majority of the time. On average, I’m usually able to get a fully functioning hi-res prototype built out within a few hours and less than an hour for lower res prototypes. Additionally, InVision has support for collaboration which is great if you do client services.
Keep in mind that you don’t need to be too focused on pixel perfection in the early stages of the prototype. What you should be focusing on is validating the designs and quickly iterating, so expect to have dozens of different versions of your design before you get to something ready to develop.
Getting into a flow
I found that over time, if you can get into a flow where you can quickly get to something clickable and leave room for a few days of the week for testing and discussion, you’ll be in good standing to fit this process into a sprint that can work ahead of development by a sprint or two. This can vary from designer to designer, depending on how much detail they put into the work. With that said, I highly suggest putting focus on validating important aspects of your product such as matching the design to the users current workflow, usability and efficiency. Again, refer to the success criteria that you specify before conducting your tests to help you validate your designs for each test. In the lean UX world, this is considered validating your hypothesis or assumptions that were created early on in the process
Some additional things to consider
One important thing that I didn’t talk about was collaboration. Designers need to get out of the habit of hiding away and magically solving all their companies design problems and bring their team into their process. Yes, expose them to everything that got you the job in the first place! This not only builds a better relationship with your team, it also allows for you to become more efficient and gives you a medium to share your findings (from testing) with everyone. Including engineers in the early stage planning/concept/requirements sessions helps define any technical constraints that may otherwise come up later in the process. It allows for the team as a whole to have a shared understanding of where the product is going, which also means less time in meetings and more time building awesome products. Additionally, it helps foster a more user centered culture within your product team which could result in an organic, wide-spread adoption of the process within other departments. It also gives the team a sense of ownership which in turn outputs better quality products and excitement within the team. Collaboration and communication is huge, especially for UX’ers who typically oversee the whole product development life cycle.
How teams work together ties directly into the culture of the company and varies between organizations. Again, as mentioned in item number one above, you will need to get a grasp of how things currently work within your team and start from there. At the end of the day, you’re there for the user. It’s your job to keep them in mind at all times and to be that window for the team when things go astray or may directly affect the end user (i.e. adding unnecessary features that provide no value to the user).
As with any process, this will likely change and adapt over time, however, it can provide a good foundation that allows you to work fast and flesh out quality work
I’d love to hear how you work within your company! Feel free to leave a comment to discuss