nForm Blogtag:nform.ca,2014:/blog//72014-03-21T22:14:35ZMovable Type 3.32Save the Date: Better Intranets Conference on June 12tag:nform.ca,2014:/blog//7.3402014-03-21T22:04:28Z2014-03-21T22:14:35ZWe’re bringing people together to talk about intranets. What’s working? What challenges are others facing? What have they done to improve things? At nForm’s Better Intranets conference you’ll hear case studies from successful Intranet projects and straight talk from Intranet...Dennis Breen/about-us/dennis-breen
<p>We’re bringing people together to talk about intranets. What’s working? What challenges are others facing? What have they done to improve things? At nForm’s Better Intranets conference you’ll hear case studies from successful Intranet projects and straight talk from Intranet managers about their experiences and challenges.</p>
<h2>Who should attend:</h2>
<ul><li>Intranet managers</li>
<li>IT managers responsible for intranets, SharePoint and collaboration</li>
<li>Internal communication managers</li>
<li>Intranet content owners</li>
<li>Department heads who want to learn more about intranets</li></ul>
<h2>Event Details</h2>
<p>Better Intranets</p>
<p>Smart people. Real stories. Proven strategies to improve your intranet.</p>
<p><strong>Thursday, June 12</strong></p>
<p>Art Gallery of Alberta</p>
<h2>Morning Conference</h2>
<p><strong>8 a.m. – 12 p.m.</strong></p>
<p>Ledcor Theatre (Lower Level)</p>
<p>Learn from your peers as our guest speakers share their strategies and experiences. You can also take part in the discussion as there will be plenty of time to ask questions.</p>
<h2>Afternoon Workshop</h2>
<p><strong>1 p.m. – 4:30 p.m.</strong></p>
<p>Allan E. Scott Boardroom (Level Four)</p>
<p>Are you interested in learning more? Delve in deeper as our experts provide personalized advise on how to improve your intranet.</p>
<p><i>Note: There are only 20 spots available for the afternoon workshop. Must attend the morning conference to attend in the afternoon.</i></p>
<p>Mark June 12 in your calendars as this is an event you won’t want to miss. Ticket information will be available in the coming weeks.</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/L0giv4nLajQ" height="1" width="1" alt=""/>We're Hiring a UX Designertag:nform.ca,2014:/blog//7.3372014-03-18T18:33:54Z2014-03-18T18:43:32ZWe're hiring a user experience designer to work out of our Edmonton office. If you're interested and you meet the requirements, please get in touch--we'd love to talk with you! Not in Edmonton? Don’t be shy. If you’re just the...Dennis Breen/about-us/dennis-breen
<p>We're hiring a user experience designer to work out of our Edmonton office. If you're interested and you meet the requirements, please get in touch--we'd love to talk with you! Not in Edmonton? Don’t be shy. If you’re just the person we need, we’ll offer a moving allowance to get you here.</p>
<h2>Job Duties</h2>
<ul><li>Collaborate with clients, analysts and other designers to identify the best solutions to a problem</li>
<li>Create intuitive and usable interfaces for web sites, web applications, mobile apps and other systems</li>
<li>Create clear and effective design documentation, such as user scenarios, personas and wireframes</li>
<li>Create diagrams or illustrations to communicate complex ideas in a simple format
Build prototypes of your designs, including using HTML/CSS/JavaScript</li></ul>
<h2>Ideal Requirements</h2>
<ul><li>Two years experience as a user experience designer, visual designer, front-end developer working on web sites, web applications, mobile applications or related products</li>
<li>General understanding of user experience design processes and methods</li>
<li>An up-to-date portfolio that shows your skills in interface/interaction design and includes examples of the artifacts you create while working toward a finished product (e.g. sketches, wireframes, mock-ups, prototypes)</li>
<li>An interest in working from research and evaluating your design ideas</li>
<li>An interest in working on complex design problems that cover web, mobile and sometimes physical experiences</li>
<li>A curious mind and a questioning disposition</li>
<li>Fluent in Adobe Creative Suite, Omnigraffle (or Visio), Microsoft Office, Sharpies and post-it notes</li>
<li>A bit of Bootstrap, WordPress, or Foundation skill isn’t required, but sure couldn’t hurt</li>
<li>Some under-the-hood knowledge (e.g. HTML,CSS,PHP,Ruby, etc.)</li>
<li>Able to travel occasionally</li>
<li>Degree or diploma in visual design or a related field</li></ul>
<h2>What We Offer</h2>
<ul><li>Competitive salary based on your experience</li>
<li>Fully-paid benefits package, including RRSP plan with matching funds from the company</li>
<li>Paid holidays and personal time</li>
<li>Professional development opportunities</li>
<li>Work-life balance</li>
<li>A supportive team that's passionate about design and user experience (because that's all we do!)</li></ul>
<h2>How to Apply</h2>
Email careers [at] nform.com with your resume, a cover letter and a link to your portfolio before March 31, 2014. No calls, please.
<img src="http://feeds.feedburner.com/~r/nform/~4/VyDevtGno5A" height="1" width="1" alt=""/>We're Hiring an Office Administrator tag:nform.ca,2014:/blog//7.3342014-02-06T16:55:31Z2014-02-06T17:55:30ZWe are hiring an office administrator for a one-year maternity leave position starting in late March 2014. We're a small-but-busy design consulting firm with a beautiful office on 104 street that's close to transit and other downtown amenities. Great benefits...Kerryn Northkerryn.north
<p>We are hiring an office administrator for a one-year maternity leave position starting in late March 2014. We're a small-but-busy design consulting firm with a beautiful office on 104 street that's close to transit and other downtown amenities. Great benefits and pay, a fun and challenging work environment, passionate team members, and impactful projects are just part of what we offer. Interested? Read on...</p>
<p><br />
<p>The ideal candidate would need to have three or more years of experience in an administrative position and at least two years of experience using QuickBooks. We are looking for a flexible and ambitious individual who possesses initiative, creativity and is very detail orientated. Work will be in a team environment and will involve a supporting role to management, analysts and design consultants.</p></p>
<p>Job Duties:</p>
<p><br />
<ul></p>
<p><li>Bookkeeping (using QuickBooks)</li><br />
<li>Assisting with completion of all necessary contracts and paperwork in a timely manner</li><br />
<li>Basic office administration duties such as answering phones, communicating with suppliers, filing, etc</li><br />
<li>Order and maintain office supplies, service office equipment</li><br />
<li>Coordinate office maintenance</li><br />
<li>Arrange travel and book accommodations</li><br />
<li>Assist with projects as needed</li><br />
<li>Main contact for vendors</li><br />
<li>Other various administrative tasks and project assistance as necessary</li><br />
</ul></p>
<p>Job Requirements:</p>
<ul>
<p><li>Certificate from an accredited community college or university in Office Administration or an equivalent combination of education and/or experience</li><br />
<li>2-3 years experience using QuickBooks</li><br />
<li>Exceptional organizational skills and attention to detail</li><br />
<li>A working knowledge of Microsoft Office programs</li><br />
<li>Excellent communication and interpersonal skills</li><br />
<li>A quick learner with the ability to work independently as well as in a team environment</li><br />
<li>Completes tasks in a professional and timely manner</li><br />
<li>Ability to manage time and handle multiple projects concurrently</li><br />
<li>Able to work under pressure and can meet deadlines</li></p>
</ul>
<p><br />
<p>Other details about the position:</p></p>
<ul>
<p><li>Salary is negotiable based on experience</li><br />
<li>We offer a fully paid benefits package and a group RRSP program (with matching contributions)</li><br />
<li>In addition to two weeks vacation, we close our office over the holiday season</li><br />
<li>We can accommodate most requests for flexible hours (e.g. if you need to drop your kids at daycare in the morning)</li><br />
<li>We work in a relaxed office environment--business casual attire is okay most days</li></p>
<p><br />
<p>If you are interested in this opportunity please email you resume in word format to <a href="mailto:better@nform.ca">better@nform.ca</a>. While all applications are accepted only those being considered for the role will be contacted.</p></p>
<img src="http://feeds.feedburner.com/~r/nform/~4/2pytjUPZdWA" height="1" width="1" alt=""/>We’re at the IA Summit This Yeartag:nform.ca,2014:/blog//7.3332014-02-03T22:11:03Z2014-02-03T23:24:14ZIn just a couple of months, two of our own will be speaking at the IA Summit 2014 in San Diego. The opportunity to present at The Summit is a big honour; it’s the premier gathering place for people and...Kerryn Northkerryn.north
<p>In just a couple of months, two of our own will be speaking at the <a href="http://2014.iasummit.org">IA Summit 2014</a> in San Diego. The opportunity to present at The Summit is a big honour; it’s the premier gathering place for people and ideas in information architecture and user experience. We are very excited to have this opportunity to share our knowledge and experience with other professionals working in the industry. </p>
<p>If you’re attending The Summit this year, you can catch Gene and Andrew’s presentations on the Sunday. Gene will be making his 7th IA Summit presentation, discussing <a href="http://2014.iasummit.org/stakeholer-mapping/">Stakeholder Mapping</a>. He’ll discuss everything from creating stakeholder maps and how to use them to how to identify high-risk stakeholders. Andrew will bring insight and understanding to the subject of <a href="http://2014.iasummit.org/ux-debt-creating-awareness-and-acting-on-missed-opportunities/">UX Debt: Creating Awareness and Acting on Missed Opportunities</a>. His presentation will cover how to identify, track and manage UX debt as well as how to improve user experience.</p>
<p>The theme for this year is “The Path Ahead” and there are some really impressive speakers attending. Both Gene and Andrew are looking forward to sharing ideas and connecting with people in the community. <br />
</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/gkMfuvqK-70" height="1" width="1" alt=""/>A More Natural Approach to Usability Testingtag:nform.ca,2013:/blog//7.3322013-09-04T22:11:03Z2013-09-05T21:05:33ZOften in usability tests, we ask participants to go to the homepage of the website under evaluation and navigate around. The problem is that people do not use the web like this... at least not anymore.Dylan Rogowsky
<p>Often in usability tests, we ask participants to go to the homepage of the website under evaluation and navigate around. The problem is that people do not use the web like this... at least not anymore. People are more inclined to search for what they are looking for and enter a website already on the page they need. This got us thinking: <em>How can we let users act naturally on a usability test?</em> The answer is to 'fake' Google.
<p><img src="http://farm3.staticflickr.com/2892/9675948584_95c8f39278.jpg" width="500" height="300" alt="Fake Google Usability Test"></p>
<p>Several months ago, we tried out a BYOD (bring your own device) usability testing session at the office, which Lisa wrote about in an <a href="http://nform.com/blog/2013/07/6-lessons-we-learned-while-doi" target="_blank">earlier blog post</a>. It was a way to capture quickly a wide range of feedback, as well as observe how participants interacted with the site on their preferred devices. We thought it would be the perfect opportunity to try out 'Fake Google' with actual participants.</p>
<p><strong>Redirecting Users to ‘Fake Google’</strong></p>
<p>The devices that participants brought covered a wide spectrum, from Mac and Windows-based laptops, to Android handhelds, iPhones and iPads, and an off-brand, feature-reduced tablet. All of the devices could connect to the internet using Wi-Fi.</p>
<p>Tech Alert: The next paragraph gets a bit technical. Basically, we configured a wireless router to send Google searches to our server instead of Google's servers. The participant did not have to enter a special website address or change any settings on their device. This allowed the participant to proceed with the task how they would outside of the usability testing session, rather than from a prescribed starting point.</p>
<p>For the technophiles, we had a spare <a href="http://www.netgear.com/home/products/wirelessrouters/high-performance/WNDR3700.aspx" target="_blank">NETGEAR WNDR3700</a> wireless router that was flashed with the <a href="http://www.dd-wrt.com" target="_blank">DD-WRT</a> firmware and created a guest network for the participants to connect to. The DD-WRT firmware has a built-in DNS server, enabling us to intercept and modify traffic before it leaves the local network. The DNS server was configured so that a participant who went to google.com or submitted a search query from their browser’s search bar was actually sent to our local server while still maintaining Google’s URL structure.</p>
<p><strong>Manipulating the Search Results</strong></p>
<p>The site that participants would be redirected to looked exactly like the Google experience they were accustomed to on their handheld or laptop device. The site would capture the participant’s search query and get actual results from Google in the background. We manipulated the results before displaying them, redirecting results for the site we were evaluating to the redesigned version on the test server. Additional relevant results were also inserted as the top three results, allowing titles and descriptions to be tested with participants. The page titles and breadcrumb of the injected results matched the format of the redesigned website, and the descriptions contained phrases from the usability test task.</p>
<p><strong>Benefits and Observations</strong></p>
<p>By manipulating search results, participants could interact with the site how they would if they were at home or work. Not only were participants more at ease, the observations were more representative of the real world.</p>
<p>One of the more surprising findings is that not all of the additional search results we inserted at the top of the list resonated as the most appropriate result. Some participants indicated the titles or summary did not appear authentic, despite containing keywords from their query. In the future, injected results should look more realistic and less like a word-for-word match to the usability test task, which may have contributed to the links being perceived as <a href="http://en.wikipedia.org/wiki/Spamdexing" target="_blank">search engine spam</a>.</p>
<p>With the technical aspects figured out, 'Fake Google’ can easily be adjusted to work with any other site or search engine, and is a great tool when conducting BYOD testing with more of a real world process.</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/vsslDh1sQ9w" height="1" width="1" alt=""/>An alternative to post-it notes and sharpies: Using butcher paper and pre-printed sticky labels for workshop facilitation and analysistag:nform.ca,2013:/blog//7.3312013-08-09T18:27:19Z2013-08-09T18:38:21ZThere have historically been three sure things in IA – post-it notes, sharpies and the Polar Bear Book. We’ve recently expanded our IA toolkit to include a roll of butcher paper and a stock of Avery mailing labels. Having used these somewhat unconventional supplies several times over the last few months, we are pleased with the results.Johanna Dietrich
<p>There have historically been three sure things in IA – post-it notes, sharpies and the Polar Bear Book. We&rsquo;ve recently expanded our IA toolkit to include a roll of butcher paper and a stock of Avery mailing labels. Having used these somewhat unconventional supplies several times over the last few months, we are pleased with the results.</p>
<p>The advantages are many:</p>
<ul>
<li><strong>Convenience.</strong> You can print card labels or interview notes and observations directly from your computer to the Avery labels instead of writing down your ideas by hand. This saves both time and energy, and is a lot easier to read! </li>
<li><strong>Volume and Type of Printing.</strong> You can more easily print large volumes of data; use standard mailing labels (Avery #48160) for a more traditional card sort or the full sheet labels (Avery #05165) to accommodate interview notes of varying lengths. </li>
<li><strong>Portability.</strong> When used on wax paper or butcher paper, Avery labels function just as sticky notes do on a wall or paper, but will stick for longer. This means that you can roll up the paper and transport it back to the office for analysis without concern that the sticky notes will fall off or stick to something else and obscure the groupings.</li>
<li><strong>Flexibility.</strong> You can change your mind over and over again. Avery labels can be grouped, ungrouped, moved, removed and grouped many times without losing stickiness.</li>
</ul>
<p>We&rsquo;ve found that the combination of butcher paper and Avery labels works best in fairly specific situations, although we&rsquo;d be interesting in hearing if you have successes in other applications.</p>
<p><strong>Situation 1: Large volume of data; small group of stakeholders.</strong></p>
<p>We printed 200 metadata topics onto standard mailing labels for a workshop on grouping the terms. We used 16-inch lengths of wax paper as the foundations on which the stakeholders (approximately five people) grouped similar terms together and permanent marker to label the groups directly on the wax paper (although you could use additional blank labels as well). We transported the wax paper sheets back to the office in a laptop bag and split up the transcription work.</p>
<p><a href="http://www.flickr.com/photos/nform/9471604347/" title="Wax Paper Sheets by nform, on Flickr"><img src="http://farm6.staticflickr.com/5454/9471604347_68c67d7c5d.jpg" width="500" height="330" alt="Wax Paper Sheets"></a></p>
<p><strong>Situation 2: Small data set; large group of stakeholders</strong>. </p>
<p>Often we hold workshops during which a group of stakeholders will work through activities designed to elicit conversations about organizational structures or processes. We recently printed a set of 24 high-level concepts onto medium-sized Avery labels (#05392) for use in a more traditional facilitated card sort. Large pieces of butcher paper covered the tabletops as participants stuck the labels together into logical groups. They labelled the groups using sticky notes and additional labels. As in the previous example, we were easily able to transport the groups&rsquo; findings to the office for analysis. </p>
<p><strong>Situation 3: Internal analysis.</strong></p>
<p>We often gather large volumes of data using various consultative methods, including interviews, and need to collect them in one place to facilitate analysis by several members of our team. We&rsquo;ve traditionally used handwritten sticky notes on the wall or whiteboard as a way to collect findings. Once again, however, our new go-to approach includes using butcher paper and Avery labels. </p>
<p>Here are the specifics: Gather electronic observations (interview or meeting notes, etc.) and consolidate into a Word document set to two columns with expanded margins. Separate each observation from the next with a couple of extra paragraph breaks. Feel free to include some contextual information that might be helpful in understanding the comment or quote. Underline the key points if you think that would be helpful. Don&rsquo;t worry that they observations aren&rsquo;t all the same length – you will be cutting the labels based on the amount of information printed on each one.</p>
<p>When you&rsquo;re ready, print the document on full-sheet Avery labels (#05165). Cut the label sheets in half down the centre. Tip: To facilitate easy peeling and sticking, peel up 1/8&rdquo; of the outside edge of the sticker and fold it onto itself to form a &ldquo;tab&rdquo; that you can easily grab when you&rsquo;re ready to peel the label off the backing. Use coloured highlighters to identify different &ldquo;sources&rdquo; of your observations (e.g. add a strip of colour for each group of stakeholders or personas to the stickers). </p>
<p><a href="http://www.flickr.com/photos/nform/9471604325/" title="Butcher Paper by nform, on Flickr"><img src="http://farm3.staticflickr.com/2893/9471604325_e7f75c173a.jpg" width="500" height="374" alt="Butcher Paper"></a></p>
<p>Post large sheets of butcher paper on the wall. Use the custom-cut labels as &ldquo;cards&rdquo; and group similar observations together (this can be done at a desk or table before you unpeel the backing). When you have a few broad groups identified, stick your labels to the butcher paper. Leave room to expand your groups and add labels. We&rsquo;ve found this method works well for projects that involve several team members. </p>
<p>We bought our 24-foot roll of butcher paper from a local butcher supply store for less than $60. Special thanks to Lisa Farlow for helping to refine these methods. </p>
<img src="http://feeds.feedburner.com/~r/nform/~4/4xdr1v3oX9g" height="1" width="1" alt=""/>6 Lessons We Learned While Doing BYODevice Usability Testingtag:nform.ca,2013:/blog//7.3302013-07-29T17:49:24Z2013-08-09T18:38:21ZA couple of months ago, we tried out a BYOD (bring your own device) quick-and-dirty usability testing blitz at the office. The idea appealed to us and our client as a way to quickly get a wide range of feedback. Some things we did right, and some things we’ll have to change the next time we run a night like this. Here are six lessons we learned for next time.Lisa Farlow
<p><a href="http://www.flickr.com/photos/nform/9394829100/" title="byodbattersbox by nform, on Flickr"><img src="http://farm4.staticflickr.com/3798/9394829100_1e02bf5856.jpg" width="500" height="374" alt="byodbattersbox"></a><br/><br />
<label>The Batters' Box</label><br />
<br/><br />
<br/><br />
<p>A couple of months ago, we tried out a BYOD (bring your own device) quick-and-dirty usability testing blitz at the office. The idea appealed to us and our client as a way to quickly get a wide range of feedback. The clients came in for the evening and we interviewed 11 participants, taking notes on the fly. We held a workshop the very next morning, and then the project was done!</p><br />
<p>Some things we did right, and some things we’ll have to change the next time we run a night like this. Here are six lessons we learned for next time:</p></p>
<h2>1. Make stage directions</h2>
<p>Long before testing day, we brainstormed a list of what needed to be done on test night and created a set of stage directions to plan out the order and time in which everything needed to happen. We all memorized our own tasks and were familiar enough with others’ tasks to step in if needed. Knowing exactly what needed to be done and where everything was kept the mood from ever becoming frenetic.</p>
<p><em>Next time:</em> Make a detailed list of instructions. Do some walkthroughs with somebody in the office pretending to be a participant. Try to think of everything that could happen. What if somebody is late or early? What if somebody forgets his or her device? What if somebody brings a kid? What if somebody is an especially loud talker and can be heard outside the testing room? Plan for everything.</p>
<h2>2. The more variety, the better</h2>
<p>We had a real hodgepodge of laptops, Androids, iPhones and iPads, and one off-brand tablet none of us had ever seen before. The large variety of devices that showed up at our BYOD testing sessions provided interesting insights that may not have come up had we only tested on one device.</p>
<p><em>Next time:</em> Set some minimums (e.g., let’s recruit at least four tablet users) and some maximums (e.g., no more than two users with iPhone 5s) when recruiting.</p>
<h2>3.BYOD… heavy on the YO</h2>
<p>The best part of having people test on a device they are comfortable with is that it eliminates the guesswork about whether their struggles were due to low familiarity with their device or poor UX on our test site. Or at least, in theory…</p>
<p>In our recruiting, we asked participants to bring a device that they own, but we failed to specify that we wanted them to bring a device that they own and use regularly. This led to a few participants bringing in devices with which they weren’t totally familiar. One participant brought in a tablet that he only uses while on vacation, and he hadn’t vacationed in quite a while. Another brought in a laptop that he had purchased for his child. While technically “his”, he had never used it and was unfamiliar with many of the settings and customizations.</p>
<p><em>Next time:</em> Ask users to bring in a device that they use at least two or three times per week.</p>
<h2>4. BYO--fully charged--D</h2>
<p>One participant brought a device that was almost out of batteries and she didn’t have the charger with her, so we had to have her perform the test on one of our laptops in the office.</p>
<p><em>Next time:</em> Ask participants to fully charge their device beforehand and to bring the charger with them as well.
</p>
<h2>5. Make a few different batters’ boxes</h2>
<p>We had nearly too many clients for everybody to observe the sessions directly, so we wanted to stream the sessions to clients who were observing in another room. We taped off a box area on the desk, pointed cameras to be looking down on that area, and asked users to hold their devices within the box. But we learned:</p>
<ul>
<li>The slightest glare made the screens hard to view even when devices were positioned at a perfect angle to the camera,</li>
<li>A “perfect angle” was really only even possible to maintain with a laptop, as some tablet and all phone users moved their devices around quite a bit, and</li>
<li>Zooming in and out to accommodate different device sizes is tricky on-the-fly.</li>
</ul>
<p><em>Next time:</em> set up three different batter’s boxes for each type of device in order to be ready for different screen-holding angles and levels of zoom. Observe sunlight and glare the evening before to set up our stations to be facing away from the worst light sources.</p>
<h2>6. Leave time between interviews </h2>
<p>We ran concurrent sessions, each planned to be half an hour long, 45 minutes apart. Most sessions ended up going a little long, but the break allowed us time to reset our stations, add to our notes, and never fall behind schedule for the next participant.</p>
<p><em>Next time:</em> leave 15 or 20 minutes between interviews</p>
<p>In summary, we think that BYOD testing is a great method for fast, diverse testing and we'll definitely do it again in the future.</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/brkiBZ0ZtNY" height="1" width="1" alt=""/>We're Hiring a Project Managertag:nform.ca,2013:/blog//7.3282013-06-10T21:57:21Z2013-08-09T18:38:21ZWe are a busy design/consulting firm with clients in Alberta, B.C. and Ontario. We're looking for a project manager to help keep our projects on track, our budgets under control, and our clients happy. Ideal Candidate As our ideal candidate,...Gene Smith/about-us/gene-smith
<p>We are a busy design/consulting firm with clients in Alberta, B.C. and Ontario. We're looking for a project manager to help keep our projects on track, our budgets under control, and our clients happy.
</p>
<h2>Ideal Candidate</h2>
<p>As our ideal candidate, you...</p>
<ul>
<li>love working with people</li>
<li>take pride in keeping things organized and moving forward</li>
<li>are good with numbers, spreadsheets, plans and schedules</li>
<li>can communicate clearly and effectively, in writing and in a meeting</li>
</ul>
<h2>Job Duties</h2>
<ul>
<li>Manage schedules and workflow for projects</li>
<li>Work with the project team to define project schedules</li>
<li>Create plans, status reports, and other project deliverables</li>
<li>Monitor project budgets throughout the project lifecycle</li>
<li>Plan and organize events</li>
<li>Assist with proposals, marketing, social media and other promotional activities</li>
</ul>
<h2>Other Requirements</h2>
<ul>
<li>College or university degree</li>
<li>Highly organized and able to see the big picture</li>
<li>Strong written and verbal communication skills</li>
<li>Strong grasp of web and mobile technologies</li>
<li>Excellent problem-solving skills</li>
<li>2 - 3 years experience managing interactive projects in an agency, marketing department, consulting firm or similar environment
</li>
<li>Able to work from our downtown Edmonton office</li>
</ul>
<h2>What We Offer</h2>
<ul>
<li>competitive salary</li>
<li>company smartphone (or equivalent allowance if you already have your own)</li>
<li>fully-paid health benefits package for you and your family</li>
<li>creative and flexible work environment</li>
<li>unique opportunity to work with interesting clients on challenging projects</li>
</ul>
<h2>How to Apply</h2>
<p>Send your resume and a cover letter outlining your skills and experience to careers [at] nform.com. Be sure to include links to your blog, online portfolio, twitter and/or tumblr accounts if they're relevant. No calls, please.</p>
<p> <br />
</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/uetphbVn-jQ" height="1" width="1" alt=""/>Five Keys to Visual Business Analysistag:nform.ca,2013:/blog//7.3272013-06-10T14:11:06Z2013-08-09T18:38:21ZBack in January I shared some thinking on what we've called Visual Business Analysis. That post argued that holistic visualizations of the system are necessary during requirements gathering because a coherent picture changes how people think about requirements. In effect,...Dennis Breen/about-us/dennis-breen
<p>Back in January I shared some thinking on what we've called <a href="http://nform.com/blog/2013/01/visual-business-analysis">Visual Business Analysis</a>. That post argued that holistic visualizations of the system are necessary during requirements gathering because a coherent picture changes how people think about requirements. In effect, requirements are never complete without a picture of how the pieces come together. And visualizations provide the common language that allows a team of people with different skills and perspectives to debate and iterate towards a good solution.</p>
<p><a href="http://www.flickr.com/photos/nform/9007403282/" title="Visual BA by nform, on Flickr"><img src="http://farm9.staticflickr.com/8533/9007403282_50c35f9ff5_o.png" width="500" height="604" alt="Visual BA"></a></p>
<p>One common response to the post could be summarized as: "Interesting. What's the process? What are the deliverables?" I have to confess that I'm the prototypical "it depends" designer. Each project has it's own particular context, but I think there are five critical components in Visual BA.</p>
<p><strong>1. Involve the designer in research. </strong><br />
It's critical for designers to have direct contact with business stakeholders and end users. Broadly speaking, business analysts are oriented toward documenting processes and business rules. This is a critical skill, but it tends to focus on system and process as abstract things, not as places inhabited by human beings.</p>
<p>Experienced designers, on the other hand, are able to focus on how process and rules affect the people in the system. Scrutinizing pain points and building a picture of how users understand the domain creates insight that is key when exploring options for a future state. Designers search for opportunities to transform processes to better fit the people and context. </p>
<p><strong>2. Model the big picture as soon as possible.</strong><br />
BA documentation tends to be text heavy, and after a relatively small set of user stories it's easy to lose the thread of how all the pieces might come together. As stories accumulate they become harder to use as a common reference. Subject matter experts, being unfamiliar with development processes and deliverables, often struggle to understand the big picture. This can create an unintentional power imbalance, with BAs and developers having greater influence over decisions.</p>
<p>Visualizations of screens and flows level the playing field, allowing subject matter experts to contribute on an equal footing. It's important to get to this common language quickly so that expert knowledge and experience can be used effectively. My experience is that, while user stories initially lead the design, there comes a point where the thinking that is embodied in the visuals starts to lead. When that happens, user stories start to be generated from the visuals.</p>
<p><strong>3. Get sketchy – and fast.</strong><br />
Confession: I'm still learning to do this. As one who comes from a visual design background, I care (too much) about the quality of the visuals I produce. Designers tend to want to their work to be polished, with well-considered layouts and thoughtful typography. But the early business analysis stage of the project is not the time for such precision. </p>
<p>Early on, the visual business analyst's job is to help the team build a common understanding of the problem space and to explore possibilities for solutions. Because these represent uncharted territory, you need to move quickly and iteratively to figure out where you are and where you want to go. A visual business analyst needs to dedicate energy to understanding the problem and exploring multiple solutions, not to aligning elements on a grid. Designers need to think of their work as visual conversation starters rather than deliverables. </p>
<p><strong>4. Include the entire team.</strong><br />
The challenge of teamwork, as noted above, is that people with different experience and skill-sets lack a common language for discussing problems and solutions. The power and beauty of teamwork is that focusing a variety of skills and perspectives on a problem leads to both richer and more realistic solutions. </p>
<p>Depending on the process you follow, there may be a tendency to leave technical people out of early business process discussions. Or to leave subject matter experts out of conversations on technical constraints. But this would be a mistake. The more developers understand the business problem, the better technical advice they can offer. The more business people understand the technical landscape, including constraints, the more they're able to adjust their approach and expectations. </p>
<p>When people understand problems and issues outside of their area of expertise they're able to leverage that expertise in service of the big picture. It takes a village to raise a complex system. Invite them all. </p>
<p><strong>5. Throw away your work early and often. </strong><br />
This is much easier to do if you stick to point 3. Sketchier work is usually viewed as less complete, so easier to critique. The whole point of visuals as business analysis tools is that they are used to explore the problem and possible solutions. They're sometimes meant as a question – "Is this how we all see the situation?" They're sometimes meant as a provocation – "What if we thought of it this way?" But they're never intended as a declaration of what the final design should be – at least not in the early going.</p>
<p>This might be a different way for designers to think about their work – especially if they're used to taking mockups through to final visual design. It may also be a different way for team members to think of a designer's contribution. But in order to build a culture of critique within project teams it's important that design artifacts not be treated with undue reverence.</p>
<p>While these points may not satisfy anyone looking for the Visual BA "process" (and heaven knows we don't need any more prescriptive processes), they are key markers on the road to understanding problems and defining better solutions.</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/FC064HNXh64" height="1" width="1" alt=""/>The Experience Gap (UX Camp Edmonton Presentation)tag:nform.ca,2013:/blog//7.3232013-05-13T19:00:57Z2013-08-09T18:38:21ZI wanted to share the slides from my UX Camp Edmonton talk this weekend. The presentation is called "The Experience Gap," and its core idea is that there's a growing gap between the best experiences people have with technology and...Gene Smith/about-us/gene-smith
<p>I wanted to share the slides from my UX Camp Edmonton talk this weekend. The presentation is called "The Experience Gap," and its core idea is that there's a growing gap between the best experiences people have with technology and the ordinary ones created by most organizations. In that gap there are interesting opportunities for UX professionals, especially in places like enterprise software development.</p>
<p><iframe src="http://www.slideshare.net/slideshow/embed_code/21108264" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px" allowfullscreen webkitallowfullscreen mozallowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="http://www.slideshare.net/nform/uxcamp-2013-ss" title="The Experience Gap (UX Camp Edmonton)" target="_blank">The Experience Gap (UX Camp Edmonton)</a> </strong> from <strong><a href="http://www.slideshare.net/nform" target="_blank">nForm User Experience</a></strong> </div></p>
<p>(One of these days I'll pull together my complete notes to post too.)</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/5UzhjMwWqys" height="1" width="1" alt=""/>User Experience Debttag:nform.ca,2013:/blog//7.3222013-05-07T20:37:31Z2013-08-09T18:38:22ZUX debt is real and every digital product has some to repay. Some of this debt is incurred intentionally because tough decisions have to be made. Some of this debt is incurred unintentionally because assumptions about end-users go unchecked. It's time to start paying attention to the I.O.U.'s we're writing to our users.Andrew Wright
<p>Have you ever borrowed something from a friend and written them an “I.O.U.”? I have. But have you ever written one to the people that use your website, your application, or your online services? No? I didn’t think so*.</p>
<p>Most digital products – like websites, apps, and online services – are designed and built with the best intentions. But something happens between identifying a need and delivering a solution. That “something” is an accumulation of User Experience debt, or “UX debt”, and it is something of an I.O.U. to your users.</>
<h2>A Brief History of the Term</h2>
<p>The term "UX Debt" stems from another financial analogy called <a href="http://c2.com/cgi/wiki?WardExplainsDebtMetaphor" title="Technical Debt">Technical Debt</a> coined by Ward Cunningham to describe the hidden, future costs of cleaning up sloppy code and repairing unstable components of software because corners were cut during development. Ward Cunningham also described repaying this debt in terms of refactoring code to align with increased understanding of how the software ‘should’ function. We’re going to apply a User Experience perspective to this concept.</p>
<h2>What is UX debt?</h2>
<p>UX debt is the quality gap between the experience your digital product delivers now and the improved experience it could offer given the necessary time and resources. Put another way, UX debt measures the number and magnitude of potential product enhancements that would improve the user experience.</p>
<p>In his book <a href="http://www.abookapart.com/products/designing-for-emotion" title="Designing for Emotion by Aarron Walter">Designing for Emotion</a>, Aarron Walter remapped Maslow's Hierarchy of needs to the needs of our users. To paraphrase Mr. Walter: for a user's needs to be met at the most basic level, an interface must be functional. If you can't complete your task, you won't stick around long. Each level of the “functional, reliable, usable, pleasurable” pyramid satisfies different user needs and increases a user’s satisfaction with a digital product. UX debt is measured as the distance between the current quality of experience and the target quality.</p>
<p>In talking about UX debt, it’s important to acknowledge that it only exists if you believe digital products should be more than just functional; more than just reliable; and maybe even more than usable. While the target quality can vary based on the perspectives of the users, the business, and the project team, I believe it should skew towards user expectations and their desired quality of experience. For now, we’ll assume that all perspectives agree on a target quality of “usable”.</p>
<a href="http://www.flickr.com/photos/nform/8715916524/" title="User Experience (UX) Debt by nform, on Flickr"><img src="http://farm8.staticflickr.com/7287/8715916524_144a3243a8.jpg" width="500" height="370" alt="User Experience (UX) Debt"></a>
<h2>Classifying UX Debt</h2>
<p>UX debt can be classified into two categories: <em>intentional</em> and <em>unintentional</em>. Intentional UX debt is the result of project constraints and deliberate corner-cutting. Unintentional UX debt, on the other hand, is less obvious than intentional UX debt and results from misconceptions about users’ needs or users’ comfort with technology.</p>
<h3>Intentional UX Debt</h3>
<p>Intentional UX debt is a result of decisions made based on project constraints. It is common that budget, time, or resource constraints determine which features are included in a digital product.</p>
<p>Sometimes, interaction along critical task-flows goes unimproved because "it works" and there are other, less-critical features to squeeze in before the deadline (that’s an I.O.U.). Sometimes, design ideas that simplify user interactions are sacrificed because they are viewed as too complex to implement in the time-frame (that’s an I.O.U.). Or, an organizational mantra, like “no customization” or “keep it vanilla,” prevents the team from even considering those improvements in the first place (a wicked I.O.U.).</p>
<p>These are realities of the software world. It sucks, but it happens. Priorities are measured and choices are made. When those choices compromise the user experience, the result is UX debt.</p>
<p>There's another form of intentional UX debt that can be harder to spot. It comes from cutting corners and taking the easy way out of design problems. Whether it's an individual or a team, sometimes people look for the fastest solution to an otherwise interesting design problem. They know there are better solutions that will meet the needs of the users more closely, but they would have to work harder for them (that’s an I.O.U.). UX debt is created when we take the easy path to avoid the effort required of a better solution.</p>
<p>In both situations – for whatever reason – there is intent to omit a higher quality experience.</p>
<p><strong>Pro-tip</strong>: When you hear "<a href="http://nform.com/blog/2013/04/training-vs-design" title="Training vs. Design">we can train them on it</a>,” you’re incurring UX debt.</p>
<h3>Unintentional UX debt</h3>
<p>Acquiring unintentional UX debt is easiest when you assume you know your users and can design a product or service without confirming your assumptions about them. For example, when someone says "Why don't we just design it for Joe Public / the average user / my mom and that'll be fine, right?" I cringe, bite my lip, breathe three times, and proceed to politely discuss alternatives to their suggestion. Without understanding the people a digital product or service is being designed for, you may be designing yourself straight into the depths of UX debt (and that’s a BIG I.O.U.).</p>
<p>The forgivable way to incur unintentional UX debt is when your understanding of the needs, abilities, or characteristics of a product's users change. For example, let's say your app is designed and built based on what your team knows today. This app delivers a high quality experience that aligns with users' needs and wants. But, over time, users are exposed to more complex interaction patterns in other digital products and their comfort level with technology increases. As this happens, people begin to perceive your app as less usable than, say, a competitor's product which has already adapted to this shift (and that’s an I.O.U.). Your users have raised the bar, thereby increasing your UX debt.</p>
<p>Accruing <em>some</em> unintentional UX debt is unavoidable and, perhaps, inevitable as we learn more about how people use our digital products. But there is a risk that these mounting I.O.U.’s will lead to project failure or user rebellion if they go unchecked. The risk increases as more time and resources are invested without some kind of user validation. Fortunately, the threat of UX debt can be reduced with the appropriate research into understanding the people that will be, and are currently, using our digital products.</p>
<h2>Summary</h2>
<p>UX debt is real and every digital product has some to repay. Some of this debt is incurred intentionally because tough decisions have to be made. Some of this debt is incurred unintentionally because assumptions about end-users go unchecked or there are unpredictable changes in the ecosystem.</p>
<p>The important difference between websites, apps, and online services we perceive as usable and those which are not, is that usable digital products have less UX debt than the products surrounding them. They’ve put in the effort to repay their UX debt and can happily tear up settled I.O.U.’s.</p>
<p>In a future post, I’ll discuss some ideas around tracking UX debt and how to transform it into opportunity.</p>
<p>* If you have written an I.O.U. to your customers or end-users, I’d love to hear your story and what came of it! Continue the conversation on Twitter using the hashtag <a href="https://twitter.com/intent/tweet?hashtags=uxdebt&text=@andrewjwright">#uxdebt</a> or drop me an email at andrew&lt;dot&gt;wright&lt;at&gt;nform&lt;dot&gt;com.</p>
<h3>Further Reading</h3>
<ol>
<li><a href="http://tlclabs.co/index.php/2012/09/on-uxdebt-nature-nuance-in-product-design/">On UXDebt: Nature & Nuance in Product Design</a> by Will Evans</li>
<li><a href="http://www.construx.com/10x_Software_Development/Technical_Debt/">Technical Debt</a> (a thorough classification) by Steve McConnell</li>
<li><a href="http://asinthecity.com/2011/05/23/ux-design-debt/">UX Design Debt</a> by Ben Melbourne</li>
<li><a href="http://commadot.com/the-ux-of-technical-debt/">The UX of Technical Debt</a> by Glen Lipka</li>
</ol>
<img src="http://feeds.feedburner.com/~r/nform/~4/_zq6FhqcwV8" height="1" width="1" alt=""/>Training vs. Designtag:nform.ca,2013:/blog//7.3202013-04-10T15:06:06Z2013-08-09T18:38:22ZSome thoughts on when to invest in design versus training.Gene Smith/about-us/gene-smith
<p>A friend of mine, a mid-level manager in a large company, recently told me about his employer's new expense tracking system. Like many big organizations, my friend’s firm designs and builds many of its internal applications. While rolling out the application, this company asked its employees to take a two-hour training session to teach them how to enter their expenses.</p>
<p>To say my friend is busy would be an amusing understatement. Naturally he was frustrated with the time commitment for training on such a mundane activity. I agreed that a two-hour lecture on logging receipts seemed excessive. But I was also astounded at his employer’s financial investment in training. If you count the costs for developing the training materials, delivering the sessions and the staff time, this organization probably spent well into the seven figures on training alone.</p>
<p>That's a lot of money, right? You'd expect to see some serious results with that kind of investment. But my friend reports that the next time he went to enter his expenses--probably a few weeks after his training session--he was pounding his keyboard in frustration.</p>
<p>Was he the only one? No, in fact, almost *everyone* who had to do expenses regularly felt this way.</p>
<p>This story encapsulates a common problem we see in enterprise application development projects: spending a lot of money on training instead of making a small investment in design.</p>
<h2>The Economic Consequences of Ignoring Design</h2>
<p>There's a simple and compelling economic argument in favour of design over training: design is a one-time investment; training is an ongoing investment over the life the product. </p>
<p>Not only do you incur training costs at least once for every user, the worse your user experience, the more likely you will incur those costs multiple times for every user (in the form of retraining and peer support).</p>
<p>Let's go back to my expense-tracking friend. His company has already spent over a million dollars (by my estimation) on training to roll out their new system—but realistically they're just getting started. Every new employee will need training at least once, and there will be support costs and lost time due to preventable errors. And let's not forget intangibles like the unnecessary frustration and the lost goodwill of employees.</p>
<p>Most importantly, no amount of training will ever fix the design flaws in this system.</p>
<p>A better approach would've been to do some prototyping and evaluation of the application--iterative design, in other words—-prior to the build. But for a variety of reasons—-sometimes it’s organizational culture, sometimes it’s ignorance of iterative design methods—-we see organizations trying to correct their user experience problems with training.</p>
<h2>What's the Problem?</h2>
<p>We’ve noticed three related issues that contribute to this problem:</p>
<ol>
<li>Training is disconnected from application development. It happens at the end of a project, the costs are often distinct from development, and the trainer is engaged when the product is finished.</li>
<p><li>Training is actively used to compensate for poor or just unconsidered design. More than once we’ve heard “we can train them on it” as a way to justify confusing design choices.</li></p>
<p><li>Ongoing training, user frustration and preventable errors are negative externalities--they’re not accounted for in project budgets or in application operating costs so project managers are often free to ignore them.</li><br />
</ol></p>
<h2>What Can We Do Instead?</h2>
<p>The first thing we should do is recognize that there are different kinds of training.</p>
<p><a href="http://www.flickr.com/photos/nform/8610310673/"><img src="http://farm9.staticflickr.com/8104/8610310673_c8ec45cd23.jpg" alt="The Training Pyramid" width="500" /></a></p>
<ul>
<li>People need to acquire domain knowledge about the system and how it fits into their work. Someone who’s never worked in a large organization might need to know what kinds of things (e.g., meals, mileage, office supplies) she can expense.</li>
<p><li>People need to understand the business processes and policies that govern the system. This could mean anything from the approval process for expenses, to the time required to process a claim, to the deposit dates for direct payments.</li></p>
<p><li>In our experience, much training focuses on “how to” information--the key tasks and procedures that people need to complete when using the system. This is tricky because procedural knowledge is hard to learn and recall without practice.</li></p>
<p><li>Finally, people will train each other informally on how to use systems effectively. For software that isn’t intentionally designed to be usable, a significant amount of time can be sunk into peer support (“hey Sally, can you show me how to upload my receipts?”) or sharing workarounds (“if you open the expense codes in a separate tab you can cut and paste them easily”). <br />
</li><br />
</ul></p>
<p>Generally speaking, domain knowledge is easier to acquire and share while procedural knowledge requires some practice to master.</p>
<p>The key thing to recognize is that good design can reduce the need for formal training by anticipating people's most important tasks and guiding them through them. In the case of expense tracking, an occasional-use application for most people, thoughtful design will help people do the right things at the right time without much training at all.</p>
<p>Good design should also eliminate the need for informal training through research (looking at the workarounds people currently use and designing the system to accommodate those) and evaluation (testing prototypes to ensure people don’t need to resort to workarounds to complete a task).</p>
<h2>How Do We Fix This?</h2>
<p>There’s a difference between knowing that design can reduce training costs and doing something about it. So how do we address the three core problems I mentioned earlier? Here are some suggestions:</p>
<h3>Redeploy your training budget</h3>
<p>If you’re not already doing design work in the early phases of a project, you should redeploy a portion of your training budget to design work in the requirements phase (or inception phase if you’re doing an agile project).
Focus on using your design efforts to improve the learnability, memorability. efficiency and error rates for the application. These are standard <a href="http://www.nngroup.com/articles/usability-101-introduction-to-usability/">usability quality components</a>, but it’s important to call them out specifically because they all impact the need for training.</p>
<p>This redistribution of funds will pay off over the life of the application. Remember, design is a one-time investment; training is forever.</p>
<p>How much should you move from training to design? We think it depends on whether or not your users need to master the application. For expense tracking, mastery is not required, so a large portion of the training budget (perhaps 80% or more) could potentially move to design.</p>
<p>For systems that require mastery (anything from air-traffic control software to everyday point-of-sale systems) you will still need training as well as practice time for your users. But if you’re not doing design work you’ll get value from spending some of your training budget on design. I can’t give you an estimate for how much to spend--it could be 10% or 50% or more depending on how complex and critical the application is. The key is to assess how much a one-time investment in improving efficiency or reducing error rates could reduce lifetime training costs.</p>
<h3>Iterate</h3>
<p>Use an iterative design process so you can improve the application’s design quickly and cheaply as early as possible. Iterative design means you produce at least one prototype of the system, test it with real users, and make changes. Many of our projects involve three iterations of the application; some involve more. And our experience has been that sketches, wireframes and small-scale interactive prototypes are the best tools for working through design options.
(Side note: Agile projects are only iterative if the team revisits and improves features in future sprints. Most agile enterprise application development projects we encounter are not iterative.)</p>
<h3>After Launch: Fix the Simplest Non-functional Problems First</h3>
<p>These two approaches above are great at the start of the project, but what about after an application has launched? The development and training budget are spent, but your organization is probably still absorbing the hidden costs (frustration, support and peer training).</p>
<p>One approach that’s worked for us is focusing on small non-functional changes to the most problematic features. On a recent project we worked with the application developer on minor adjustments--such as relabelling confusing fields and allowing users to move directly between two screens they often needed in sequence instead of closing one then manually opening another. These changes improved user performance and satisfaction but didn’t require major effort or any functional changes.</p>
<p>Depending on your organization you might be able to do guerilla redesigns or <a href="http://nform.com/cards/cafe-test">cafe testing</a> as well.</p>
<h3>Quantify the Negative Externalities</h3>
<p>Another approach that might be useful is estimating the costs of ongoing training, peer support, frustration and preventable errors (the consequences of ignoring design that aren’t factored into project budgets or operating costs).
UIE has a helpful article on the <a href="http://www.uie.com/articles/cost_of_frustration/">Cost of Frustration</a> that provides several ideas for how you might quantify these things. Here are two we like:</p>
<ul>
<li>Rather than trying to establish a dollar cost for frustration, talk about what people could do with their time instead.</li>
<p><li>Trace the pain and find allies who can support your cause. For an expense tracking system, for example, a finance manager may spend more time than they want on fixing errors or taking support calls.</li><br />
</ul></p>
<p>This approach won’t yield immediate results, but it can help create a culture where design is valued because it contributes to the organization’s success. It also makes an explicit connection between doing iterative design and employee satisfaction, cost avoidance and project success. Then, the next time a big internal systems projects comes around, the project manager will be more likely to do a couple of rounds of design and prototyping early (and will have a way to justify the costs since it can come out of the training budget).</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/LhzaCMXuRLA" height="1" width="1" alt=""/>Event: Content Strategy for the Public Sector (April 11)tag:nform.ca,2013:/blog//7.3192013-04-02T16:26:06Z2013-08-09T18:38:22ZBefore I started consulting 10 years ago I worked in the public sector in a variety of communications and web management roles. Talking with clients over the past year I've realized that many of them still suffer from the same...Gene Smith/about-us/gene-smith
<p>Before I started consulting 10 years ago I worked in the public sector in a variety of communications and web management roles. Talking with clients over the past year I've realized that many of them still suffer from the same frustrations I had as a public-sector web manager--especially around content creation, management and governance.</p>
<p>We decided to put to together a talk on content strategy for the public sector to share some of our ideas (as well as the best ideas we've heard from our clients and industry) about content. If you work in the public sector and you deal with content creation or publishing we think you'll enjoy this event.</p>
<p>Details and a registration form are below. As always, tickets are free but attendance is capped. We'll provide coffee and a light breakfast as well.</p>
<p><br />
<h2>Event Details</h2></p>
<p><strong>Content Strategy for the Public Sector</strong><br />
Thursday, April 11, 8:30 a.m. to 10 a.m.<br />
Matrix Hotel<br />
10640 - 100 Avenue<br />
Edmonton, Alberta<br />
<a href="http://nform-csps.eventbrite.com/">View this on Eventbrite</a></p>
<h2>Session Description</h2>
<p>For many of our public sector clients, delivering relevant, compelling and findable content is a common challenge. They wrestle with diverse stakeholders and audiences, complex programs and policies, clunky content management systems, and limited resources for content creation. And yet, the content created by public sector organizations is highly valued and trusted by users, and is often people's first stop on their way toward accessing programs and services.</p>
<p>In this talk, we'll share insights about content strategy from our last decade of work with government, municipal, health and education clients. You'll hear about:</p>
<ul>
<li>What we've learned about how people use web content, social media and online services</li>
<li>Governance, leadership and other factors that contribute to successful teams</li>
<li>Making a business case for investing in content development and building strong editorial teams</li>
<li>Essential strategies to get you through the next few years of shrinking budgets, rapid technological change and growing user expectations</li>
</ul>
<h2>Speaker Bio</h2>
<p>Gene Smith is the president and owner of nForm. He's worked with a variety of Canadian public and private sector organizations on user experience strategy for their websites, Intranets and business applications.</p>
<h2>Registration</h2>
<div style="width:100%; text-align:left;" ><iframe src="http://www.eventbrite.com/tickets-external?eid=5954308497&ref=etckt&v=2" frameborder="0" height="214" width="100%" vspace="0" hspace="0" marginheight="5" marginwidth="5" scrolling="auto" allowtransparency="true"></iframe><div style="font-family:Helvetica, Arial; font-size:10px; padding:5px 0 5px; margin:2px; width:100%; text-align:left;" ><a style="color:#ddd; text-decoration:none;" target="_blank" href="http://www.eventbrite.com/r/etckt">Event Registration Online</a><span style="color:#ddd;"> for </span><a style="color:#ddd; text-decoration:none;" target="_blank" href="http://nform-csps.eventbrite.com?ref=etckt">Content Strategy for the Public Sector</a> <span style="color:#ddd;">powered by</span> <a style="color:#ddd; text-decoration:none;" target="_blank" href="http://www.eventbrite.com?ref=etckt">Eventbrite</a></div></div>
<img src="http://feeds.feedburner.com/~r/nform/~4/2_o79UI-Fm0" height="1" width="1" alt=""/>When to apply UX effort in agiletag:nform.ca,2013:/blog//7.3172013-02-21T19:15:02Z2013-08-09T18:38:22ZWhen should you apply UX effort on an agile project to get the most out of it? Well, UX design skills are most valuable to agile processes at three key points: during modeling, during evaluation, and for facilitating day-to-day design activities.Andrew Wright
<p>
Over the past two years, I've been the user experience designer on a number of projects with teams that are adopting <a href="http://en.wikipedia.org/wiki/Agile_software_development">agile</a> as their chosen methodology (it usually comes in <a href="http://en.wikipedia.org/wiki/Scrum_(development)">scrum</a> flavour). Some teams were more experienced with the methodology and its practices; other teams were less experienced. I was learning with them.
</p>
<p>
My experience has been that UX design skills are most valuable to agile processes at three key points:
</p>
<ol>
<li>during modeling,</li>
<li>during evaluation, and</li>
<li>for facilitating day-to-day design activities.</li>
</ol>
<p><br/><br />
<a href="http://www.flickr.com/photos/nform/8494392743/" title="When to Apply UX in Agile by nform, on Flickr"><img src="http://farm9.staticflickr.com/8506/8494392743_2bc86b4025.jpg" width="500" height="171" alt="When to Apply UX in Agile"></a><br />
<br/></p>
<h2>1. Modeling</h2>
<p>
The first way that UX designers benefit an agile project is by modeling the system. The term <a href="http://en.wikipedia.org/wiki/Architectural_model"><em>modeling</em></a> is borrowed from the world of architecture, but I’ve drafted a simplified version of this definition that works for application development projects:
</p>
<blockquote>
"A model is a representation of a system – including its processes, interaction channels, and its users – created to study aspects of the design or to communicate design ideas to clients, committees, and team members."
</blockquote>
<p>
Or put another way: modeling is the synthesis of details into something tangible that people can talk about.
</p>
<p>
Scenarios, experience maps, task flows, personas, and other storytelling tools are used to improve team members’ understanding of the business processes, the channels and modes of interaction, and the users’ behaviours and attitudes. These living documents also serve as focal points for design discussions and are pivotal in <a href="http://nform.com/blog/2013/01/visual-business-analysis">Visual Business Analysis</a>.
</p>
<p>
Modeling should happen at the start of an agile project during iteration 0 or inception. It's important to note, too, that modeling is not about gathering or defining "requirements"; it's about creating hooks on which to hang questions so you can explore them properly later. It’s like saying: “This is how we understand it right now. Let’s use this to ask and answer our questions.”
</p>
<p>
The benefits of creating models like this are threefold:
<ol>
<li>models put everyone on the same page</li>
<li>models provide a solid foundation for design and development thinking</li>
<li>models simplify decision-making later because you’ve outlined the big picture better</li>
</ol>
</p>
<p>
Austin Govella sums it up nicely:
"these kinds of models frame how the team thinks about how to solve its various problems." (<a href="http://thinkingandmaking.com/ux-lab/93/agile-ux-six-strategies-for-more-agile-user-experience">source</a>)
</p>
<h2>2. Evaluation</h2>
<p>
Evaluation is the second place where UX designers bring value to an agile project. As a UX designer, I am thrilled (and you should be, too!) that agile has evaluation built into each iteration.
</p>
<p>
Agile evaluation is slightly different from traditional <a href="http://nform.com/cards/usability-testing">usability testing</a>. In addition to investigating issues of labeling, interaction, and navigation, agile evaluation aims to test <a href="http://vimeo.com/38132933">hypotheses</a> and validate design decisions. At a high-level, you’re, at least, trying to answer these questions:
</p>
<ul>
<li>Are we headed in the right direction with these designs?</li>
<li>What can we improve upon within this release cycle?</li>
<li>Does the system model align with the user’s mental model?</li>
</ul>
<p>
Each evaluation and planning phase is a critical point for a UX designer and/or researcher to contribute to the process. They have experience planning and facilitating usability tests to maximize the return for their time and effort. Because agile cycles move quickly, it’s important to be efficient with evaluations. Not asking good questions and not knowing what to evaluate means you miss opportunities to improve the product. Asking good questions helps validate and clarify requirements, and helps identify details that improve the models.
</p>
<p>
Additionally, evaluation findings enable the agile team to validate the current project trajectory or to correct course by using the findings to inform planning for the next iteration.
</p>
<p>
Using a UX designer’s skills to conduct efficient evaluations at regular intervals lets the team test and validate ideas while there is still time to make adjustments. This inevitably leads to a better product than if you wait until Release 1 to do evaluation.
</p>
<h2>3. Facilitation (Daily)</h2>
<p>
The third area, and a bonus opportunity, where UX designers can provide added value is in day-to-day activities.
</p>
<p>
Daily UX involvement in agile should focus on facilitation. Agile methodologies champion collaboration and encourage design contributions from all team members. That doesn't just happen magically. You know this. I'm sure everyone's seen a brainstorming session, or similar exercise, spiral out of control because no one was steering.
</p>
<p>
A UX designer can help everyone understand one another using pictures, diagrams, role-playing, whatever. Project teams include developers, designers, product owners, stakeholders, and many other voices; and they all think differently than one another. Each of these perspectives brings something valuable to the table, but they need someone to help them lay it all out and make sense of it, and they need that help daily.
</p>
<p>
By leading regular group design activities, like <a href="http://vimeo.com/37861987">Design Studios</a>, a UX designer can:
</p>
<ul>
<li>help team members foster a sense of ownership for their ideas and for project outcomes;</li>
<li>create sketches, wireframes, prototypes, and other design artifacts that become the project’s Rosetta Stone—the common reference point that helps the different stakeholders communicate and understand each other;</li>
<li>they can be available to answer developer's questions that invariably come up when implementing an idea; and,</li>
<li>they can continuously improve and adapt the models as new information arrives from research and evaluation.</li>
</ul>
<p>
At any point in the project, a UX designer can be called upon to lead a focused conversation about the design and how to prioritize the next steps.
</p>
<h2>Summary</h2>
<p>
In summary, when a UX designer is integrated into an agile team and helps model the business processes, interaction channels, and user behaviours at the start of a project, it gives everyone a clear, common vision of what they're working with, and it provides a foundation to build upon going forward. When a UX designer asks the right questions during evaluation, the models evolve, the requirements become clearer, and "bad ideas" are caught before it's too late. And, when a UX designer facilitates group thinking and collaboration on a daily basis, design decisions get made faster and team members have a stronger sense of ownership of the final product.
</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/-bfLMz38tds" height="1" width="1" alt=""/>Experience Maps: A Case Studytag:nform.ca,2013:/blog//7.3162013-02-12T20:34:58Z2013-08-09T18:38:22ZLast summer I received an email from Kent Grayson, a marketing professor at the Kellogg School of Management at Northwestern University. Kent had seen the experience maps we created for Comcast and was interested in writing a case study about...Gene Smith/about-us/gene-smith
<p>Last summer I received an email from <a href="http://www.kellogg.northwestern.edu/Faculty/Directory/Grayson_Kent.aspx">Kent Grayson</a>, a marketing professor at the Kellogg School of Management at Northwestern University. Kent had seen the <a href="http://nform.com/blog/2010/02/experience-maps-cross-channel-experiences-deliverable-for-gamers">experience maps we created for Comcast</a> and was interested in writing a case study about them.</p>
<p>In Kent's words, "the case would inspire [MBA] students not only about the benefits of experience maps but also the more general principle of how beneficial it is to deeply understand the customer experience." </p>
<p>Last summer Kent wrote up the case study, I provided some details on how we developed the experience maps, and late last year it was published. You can <a href="http://cb.hbsp.harvard.edu/cb/web/product_detail.seam;jsessionid=00547A94761133A1CDFAD70CEBF82964?E=4718395&R=KEL675-PDF-ENG&conversationId=517547">get a copy</a> for a mere $6.95 from the Harvard Business School website.</p>
<p>Harvard Business School is the leading source of these case studies worldwide, which means that in the next couple of years hundreds of business school students could read this and start to apply user experience research and design practices in their work. Exciting!</p>
<img src="http://feeds.feedburner.com/~r/nform/~4/xb1U0GTskQE" height="1" width="1" alt=""/>