Rails conference 2016 building applications better the first time
- 1. Jessica Roper Senior Software Developer at Spiceworks https://www.linkedin.com/in/jessica-roper-97123915 jessica@spiceworks.com Building Applications Better the First Time WHO ARE YOU? 5+ years working on products (some more successful than others). (*which you really want when you have to see your customers everyday) AUDIENCE: This talks is geared for early career developers
- 2. What I’ll cover • Setting expectations and timelines to inject a dose of reality • How to identify highest priority features to mitigate feature creep • Iterating quickly with designs to shorten the design cycle jessica@spiceworks.comjessica@spiceworks.com INTRO: COMMON PROBLEMS TALK ADDRESSES: • Feature creep • managing expectations - everyone understanding what is being worked on and timelines they will be completed • Long design iterations Over the years I’ve developed a lot of these guidelines for myself after failing to use them and seeing PITFALLS such as: • Delivery dates extended months past deadline, • poor project manager satisfaction • spending extra time on features no one ever used. There are of course dozens of other tricks and tools out there Covering those that helped me most to: • prioritize features to focus on • iterate through design process quickly • how to set expectations NOTE: All tips can be used by a group of any size. I use most of these tips in all my projects, whether working alone or with a group of 5 or more other developers
- 3. Goal: Enable sales team with a tool to determine possible audience sizes based on demographics and network inventory. Example Project: Sales audience-sizing tool jessica@spiceworks.com Goal Gauge usage of products for an audience Tool for sales (AMs and AEs) AUDIENCE – We target emails and some advertising based on demographic data and some emails are targeted by the products users have Flow we were automating: Sales reps give requests to Business analysts (our data analysts who work with the data to answer technical questions about it)
- 4. • Determine focus and scope of product • Defines end user • Goal: agree who the end user is and what problem is being solved for them? Jessica@spiceworks 1: Define the problem clearly jessica@spiceworks.comjessica@spiceworks.com Before you get started on a new feature or product: Get everyone focused on same problem Goal: agree who the end user is and what problem is being solved for them? This leads to asking (and answering) questions like: • Can prior knowledge be required? (think CAD-like products) ** HIT ENTER HERE • Do other products will need to integrate with the tool? • What expectations/designs are they “used to” (EX: outlook for windows vs. Mac vs. web - ppl expect they will all work exactly the same, but that is not the reality) In example project STEP 1 led us to: • Must assume no prior knowledge of data • Must be fast (while on a call) • Must be easy to get number • Must allow for non-network targeting • OK Require short training session to use • ID other data sources they were familiar with TIP THAT HELPS: write down what was agreed upon, dates, features and ‘extras’ -‐-‐ You’d be amazed how easy it is to not all actually hear the same things This gives opportunity for others to speak up/clarify I don’t require sign off on my products because we all work together, but do: • ask for them to be reviewed • frequently review notes in later meeCngs and check-‐ins.
- 5. • Understand - Workflows - Thought processes - Cognitively difficult tasks • Observe details - Day-to-day - Other applications • Can’t observe directly? - Observe behavior - Google Analytics, pageview data, abandonment trends Jessica@spiceworks 2: Observe the user jessica@spiceworks.comjessica@spiceworks.com Another helpful tool before starting development in the research and planning phase is OBSERVE THE USER. Natural environment == see other factors that affect them EX: how interrupted/day-to-day, other related applications and products they use, etc) They won’t remember everything they do, or leave out information they think is irrelevant but gives insights into their problems CAN’T OBSERVE YOUR USER? Use any data available to observe their behaviour • Do users abandon process/product around same steps? (ID features that are confusing or may need reworked) • What do they do? (features and pieces they fully understand to help compare to what they don’t do) • What do they never do? (determine features they might not know about or might not find useful) In sample project: Sales rep -> BA. We were creating a tool for sales rep, but focused on the person we were automating. we observed our Business Analyst, the person doing the work we automated When a sales rep is Looking they just want to ask, what comes back when I search for something? Then they might want to apply filters, but a BA wants all the filters etc first and would do the digging later as needed.
- 6. “Starfleet captains are like children. They want everything right now and they want it their way. But the secret is only give them what they need, not what they want.” -Scotty Jessica@spiceworks 3: Focus on the majority jessica@spiceworks.comjessica@spiceworks.com Focus on the majority: In this quote from Scotty (from Star Trek) you can replace star-fleet captains with Users, Clients, etc… Still applies! Goal: which feature should be first? How do I know what’s important? -> ID/rank by highest impact • Spiceworks: 80% rule - What is really needed? What does everyone need? Sales Audience Sizing tool EXAMPLE: How many customer accounts could use data from X? (most only applied to 1-2 accounts) • Required closely working with those who delivered data manually • Manually surveying accounts and meeting with sales reps Prevents building a feature someone thought “would be cool” But then even THEY never used it :( OTHER OPTIONS Don’t know what they all do? • What features are most used? • What is the page/place that has highest drop off? • Research the industry as a whole – What do other products/market research show?
- 7. Techniques utilized for: • Design planning • Early Feedback • Efficient iterations on designs Different Types for different goals around: • functionality • flow • aesthetics “The ultimate Guide to Prototyping: The best prototyping methods, tools and processes”. http://studio.uxpin.com/ebooks/guide-to-prototyping/. Jessica@spiceworks 4: Prototype with users jessica@spiceworks.comjessica@spiceworks.com It’s tempting to jump right into development and not “waiste time” iterating on designs, but in practice I’ve found this to be much faster and less of a waste. Prototyping => Important technique for planning and get feedback early More efficient and less costly to iterate on than final product. We use different types of prototypes to solve different problems and also though out the development process All can be used to help set expectations about: • functionality • flow • aesthetics Good Rule of thumb: test with 5 it users, take feedback, iterate Don’t have to test with real users, can be anyone In the project paper prototyping would have quickly led us to realize our flow was reversed instead of finding that out after building the product and having to restructure everything later (which extended our timelines by quite a bit)
- 8. • Ex: Paper prototypes • Focus: Key elements of flow • What % screen space, general colors, location of elements, wording • Fast to iterate Jessica@spiceworks 4: Prototype with users: Low-fidelity, low-functioning jessica@spiceworks.comjessica@spiceworks.com At the time of the sample project we didn’t fully use this concept, but now for products we frequently use it to understand optimal design and flow Low-fidelity, low-functioning Very low cost Very rapid iterations PROCESS: each interaction change the page they see or add and remove elements. This can be done for ex with sticky notes Focus: Key elements of flow. • Not about shade of color or size, but how much of the screen does it take up, what general color makes sense? • Where should a button be? • What should it say? EXAMPLE Paper prototype • Paper • Pen • sticky notes • maybe scissors or cut outs? Great to test with, after a few users can create new one in minutes! Was able to use to quickly iterate on design and determine if a new type of data should be a filter versus a drop down versus a new page and test out those different flows within a few hours
- 9. • Ex: Wire frames • Focus: Interactions and usability - Testing usability, proof of concepts • It’s a skeletal framework Jessica@spiceworks 4: Prototype with users: Low-fidelity, high-functioning jessica@spiceworks.comjessica@spiceworks.com Focus: Interaction design over visual aesthetics. Get a gut reaction to the flows • Testing usability • Proof of concepts • Can be supplemental documentation for developers on design • Do they understand how to do the next desired action? • Are there any elements they don’t use at all? • Is there a time when they know what action they want to take, but don’t know how to do it? EXAMPLE Skeletal framework: • Boxes and shapes laid out to show concrete locations of layout • Functional flows built in. PROCESS: Interactions and buttons should mimic true events Used this to test with our users the new product to ensure the interactions made sense. With this we discovered names that were confusing and cases where we needed to add more help and text
- 10. • Ex: mock-ups • Focus: Finalize visual decisions - Exact colors, spacing, etc. 4: Prototype with users: high-fidelity, low-functioning Focus: finalize visual decisions • Provide limited interactivity • Allow for design to be scrutinized. • What exact color should the button be? • How exactly do all elements look on a page? • Spacing between components EXAMPLE Mock-ups • Includes real icons, buttons, colors. • Hint of flows that exist PROCESS: Focus on look and spacing and information/labels etc. Flow is frequently shown by displaying all mock ups in a row to be reviewed helpful for the Steve Jobs of the world
- 11. • Ex: Javascript/HTML • Focus: Finalized design and flows Jessica@spiceworks 4: Prototype with users: High-fidelity, high-functioning Just shy of the real thing Focus: Finalized product design including • flow • sizes • color • functionality Common use cases • Tweaking existing designs • Testing with non technical users • Working with outsourced programmers PROCESS: Interaction and view is closely mimic the true process and look and feel (but no lower layers are implemented)
- 12. Q: “Have you always multiplied your repair estimates by a factor of four?” A: “Certainly Sir. How else can I keep my reputation as a miracle worker?” – Scotty Jessica@spiceworks 5: Under-promise, over-deliver jessica@spiceworks.comjessica@spiceworks.com Star Trek: Video with captain: captain has an emergency and needs repairs. Scotty tells him it will take 8 weeks, but he doesn’t have time for that so he’ll do it in 2. https://www.youtube.com/watch?v=t9SVhg6ZENw BE LIKE SCOTTY – BE THE “MIRACLE WORKER” Clients always want to know how long it’s going to take?? Dev good rule of thumb - 2X expected dev time (account for testing, extra design iterations, bugs, etc.) WHY? • Due to overhead • Rework/refactoring not included in optimistic estimates Don’t want every development hour planned to build the product and have to work like a maniac when something isn’t perfect the first try Best case: Extra Cme to add a ‘bonus-‐feature’ (determined by priority/impact & Cme leK to develop/test etc) SAMPLE PROJECT: Discovered data issue at end, that caused several extra days of work and re-‐running processes
- 13. • Measure success • Further identify features and development needed Jessica@spiceworks 6: Create a feedback loop jessica@spiceworks.com This is something we do a lot of the time at the end of the project You can collect feedback from • usage data • Google Analytics to track user flows • good old feedback forms and online forums. Can also pre-create with something like a feature request voting system. SAMPLE PROJECT We track each page view and filter information from users and also have feedback forms Discovered through this tracking that training needed to be altered to cover more in depth how to use searching (EX: users use quotes and the AND keyword) NOTE: LAST TIP! NEXT SLIDE ->
- 14. Summary • Set expectations and timelines with help from tips… 1. Define the problem clearly (and write it down) 5. Under-promise, Over-deliver (2X dev rule) • Identify highest priority features with help from tips… 2. Observer the user 3. Focus on the Majority 6. Create a feedback loop • Iterate quickly on designs with help from tips… 4. Prototyping (also 2. Observer the user) jessica@spiceworks.comjessica@spiceworks.com PROBLEMS TALK ADDRESSED: • Feature creep • managing expectations - everyone understanding what is being worked on and timelines they will be completed • Long design iterations PITFALLS: • Delivery dates extended months past deadline, • poor project manager satisfaction • spending extra time on features no one ever used.
- 15. jessica@spiceworks.com Certainly not an inclusive list, but covers the tips I’ve found to be most valuable to include in my development process to: • improved timelines • how to determine which features/products should be priority • set reasonable expectations for time to complete for - managers - testers - any stakeholders in the product.
- 16. Questions? jessica@spiceworks.com Any Questions? Anyone have other tips/tricks/input they’d like to share with the group?
- 17. Send resume and feedback to jessica@spiceworks.com Check out #OurSpicyLife Need more info? www.spiceworks.com/jobs Jessica@spiceworks We’re Hiring! jessica@spiceworks.com