#...without being told to refactor the ENTIRE project

[iobartach]

[hub-pub-bub]

For a while now, this has been the most common question I get:

How do I convince people in my organization to take user experience seriously? I’ve tried giving brown-bag sessions on the importance of UX, but nothing has happened.

They’ve shared every case study they could find. Nothing changed.

I tell them that I’ve never had success with brown-bag intro sessions either. But there is a way to get user experience taken seriously.

When pressed for time, I often give the short answer:

You don’t have to. There’s a high likelihood there’s someone important in your organization who already takes it seriously. They just don’t know it yet.

However, there’s a more helpful, albeit longer answer. And it goes something like this…

Step 1: Start With Frustrations Caused By Poor Experiences

Organizations that aren’t fixated on creating great user experiences are usually saddled with poor user experiences. A great user experience only comes about through constant diligence and attention. If the organization isn’t paying attention, it’s unlikely they stumbled on one by chance.

We can measure the experience that comes from a product or service’s design on a scale that ranges from extreme frustration to extreme delight. At any given moment, the design is either frustrating or delighting the person using it. By definition, a user experience is good when it delights its users and poor when it frustrates them.

Yet, it might not be the direct users — those people who interact with the product or service directly — that a poor design might be frustrating. There are indirect users, often within the organization, that find the design frustrating. Here are some common examples we’ve seen:

Salespeople trying to sell a product that is hard to demonstrate or explain. The salesforce is trying to get prospects to fall in love with the idea of a purchase. If a competitor looks simpler or the prospect doesn’t understand how the product or service helps them, they won’t want to sign up. A salesperson, looking to meet their sales goals, would find the product extremely frustrating if it’s causing them to lose sales.

Call-center management responding to a poor design that generates support calls. A product with a poor user experience might put an excessive burden on the call center team. The manager of the call center, always trying to keep their costs down, may very well be frustrated by the increased call volume, even when the answers are easy to dispatch. (“Have you turned it off and on again?”)

Production managers dealing with lost worker productivity. An internal application (such as a case management system) that has too many steps or is poorly integrated with other tools will force production work to take longer. This creates backlogs and slows down overall productivity.

Development managers watching their teams rewriting the interface code. When the developers get the user interface wrong the first time, they spend time refactoring it to be easier to use. A better informed design process could’ve gotten closer in the first release.

Development managers learning that built-out features aren’t ever used. It was a waste of resources to build functionality into a product that customers aren’t using, either because the feature wasn’t wanted or the product was too complicated for the users to take advantage of the features.

In organizations with a history of producing poor designs with frustrating user experiences, it’s usually not hard to find frustrated indirect users like these. If the designs are frustrating enough (and they often are), the indirect users can become the key to build awareness in the organization.

Step 2: Identify The Frustration Costs

Almost always, when there is extreme frustration coming from a product or service’s design, that frustration shows itself somewhere on the organization’s bottom line:

Frustration costs due to lost sales revenue. Sales are going to competitors, the salesforce is discounting to compensate, or customers are taking a long time to sign up.

Frustration costs due to increased support costs. Call-center representatives are spending time answering calls that come from the user’s poor experience.

Frustration costs due to lost productivity costs. Backlogs are requiring more working hours or preventing the organization from being efficient.

Frustration costs due to wasted development rewrites. Development costs are higher because the team rewrites the same code multiple times.

Frustration costs due to unused feature development. Development costs for never-used features is a resource that could’ve been used to build something else.

With a little digging, we can calculate these costs. If the problem is lost sales, we can ask the salesforce to estimate the size of the sales they’ve lost. Or if the sales team is discounting to win against a competitor with a more delightful design, we can add up the discounts they have to give out to win the business.

If the frustration costs are coming from support calls, we’ll calculate how much those calls cost. We find out the budget for the call center, then divide that by the overall number of calls they get. That gives us the average cost for each call. When we multiply that average by the number of calls needed to deal with frustrating user experience features, we have the cost of that frustration.

We can do something similar with the lost productivity numbers: Figure out how much those personnel are paid and calculate how much time is spent dealing with the waste from the frustrating user experiences, either working with it (production workers) or creating it (developers). Multiply the percentage of time by the total personnel costs and you have a rough estimate.

Often, these rough estimates are all that’s necessary to get someone’s attention. After all, if this is the first time the organization is thinking about user experience, it’s likely the costs are pretty high. In one instance, we found that the costs of handling password resets at a large bank were costing the call-center support team $75,000,000 each year. That large number was enough to quickly get the attention of senior bank management.

Step 3: Find the Person In Charge Of Reducing Those Costs

This is where luck plays in our favor. In most organizations, especially large ones, there is already someone in charge of dealing with the costs of frustration. However, they may not realize it yet.

It’s very likely there’s someone already assigned to increasing sales. There’s someone in charge of reducing support costs. There’s someone with the job of making the production work more efficient. There’s someone who is very interested in making developers more efficient.

These people are often easy to find. And they’re rarely in the design team’s direct chain of management. They are often in parallel organizations, outside the design organization.

Once we find them, they’ll probably be surprised that we are thinking about their problem. It’s likely they’ve never thought about how the product or service’s user experience is a root cause of their issue. They’ve either never noticed the frustration, or if they have, they didn’t think anything could be done about it. (Or they were told it was too hard to fix.)

Yet, now we have numbers. An estimate of what this is actually costing the organization. And because our number is focused directly on their charter, they often have the role power and the political influence to make something happen. Suddenly, UX is important.

Step 4: Ask The New UX Champion To Sponsor A Lean UX Project

Chapter 3 of Jeff Gothelf and Josh Seiden’s seminal book, Lean UX: Designing great products with Agile teams, is called “Driving Vision with Outcomes.” They talk about how product and service teams have traditionally focused on features, by driving projects with requirements and deliverables. They suggest there’s another way.

“Lean UX radically shifts the way we frame our work by introducing back the strategic context for our feature and design choices and, more important, how we — the entire team, not just the design department — define success. Our goal is not to create a deliverable or a feature: It’s to positively affect customer behavior or change in the world — to create an outcome.”

Reducing frustration costs are an ideal outcome. And with our new UX champion, we can get support for a pilot project.

Lean UX is an ideal approach. We can start by testing the hypothesis that our rough estimates are close to correct.

We’ll ask our new UX champion for help putting together a multidisciplinary team to uncover where the frustration is coming from. By assembling a small task force with members from all over the organization, we can collect more accurate data about the frustration and ideas about how to start to whittle those costs down.

Calculating the cost of the frustration, wherever it’s coming from, is an ideal metric to drive the project and create a measurable approach to valuing design efforts. By finding a high-ranking champion outside the design team, we get exposure at a key part of the organization. And without wasting a minute in a brown-bag lunch lecturing on the importance of good user experience, we’ve shown the organization how good design can make us more profitable.

[ryadel]

Visual Studio - ASP.NET Web Site Project vs Web Application Project

When you start a new ASP.NET project in Visual Studio, you have the chance to create a new ASP.NET Web Site project or a ASP.NET Web Application project. This is true since Visual Studio 2008, being it the first VS installment where the ASP.NET Web Application Project template was introduced. What are the differences between these two project templates? Should you choose the ASP.NET Web Site or should you go with the ASP.NET Web Application instead? The answer can be easily inferred from the following article from the official MS knowledge base, which clearly explains the differences between these two project templates and emphasize the pros and cons of each choice: ASP.NET - Difference between Web Site and Web Application Project However, for the sake of convenience, we'll briefly summarize the gist in this post.

ASP.NET Web Site

The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing. If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name, which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be extremely popular. Key factors Provides the same Web project semantics as Visual Studio .NET 2003 Web projects. Has a project file (structure based on project files). Build model - all code in the project is compiled into a single assembly. Supports both IIS and the built-in ASP.NET Development Server. Supports all the features of Visual Studio 2005 (refactoring, generics, etc.) and of ASP.NET 2.0 (master pages, membership and login, site navigation, themes, etc). Using FrontPage Server Extensions (FPSE) are no longer a requirement.

ASP.NET Web Application

The Web Application Project was created as an add-in and now exists as part of SP 1 for Visual Studio 2005. The main differences are the Web Application Project was designed to work similar to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build time. In order to update the project, it must be recompiled and the DLL file published for changes to occur. Another nice feature of the Web Application project is it's much easier to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an excluded keyword in the filename. In the Web Application Project, the project just keeps track of which files to include/exclude from the project view without renaming them, making things much tidier. Key factors No project file (based on file system). New compilation model (read here or here for more details) Dynamic compilation and working on pages without building entire site on each page view. Supports both IIS and the built-in ASP.NET Development Server. Each page has it's own assembly. Defferent code model (read here for more details).

What should you choose?

If you still got doubts, we strongly suggest to take a look at this excellent post which gives reasons on why to use one and not the other. Here's an excerpt of it: You need to migrate large Visual Studio .NET 2003 applications to VS 2005? Use the Web Application project. You want to open and edit any directory as a Web project without creating a project file? Use Web Site project. You need to add pre-build and post-build steps during compilation? Use Web Application project. You need to build a Web application using multiple Web projects? Use Web Application project. You want to generate one assembly for each page? Use Web Site project. You prefer dynamic compilation and working on pages without building entire site on each page view? Use Web Site project. You prefer single-page code model to code-behind model? Use Web Site project.

Conclusions

That's about it: I hope this post will allow you to have clearer ideas on these two project templates, allowing you to make the choice that best suits your needs.   Read the full article

[topicprinter]

Hey Reddit,​I wrote this post for my blog, but thought you might all find it interesting. Happy to answer any questions!​--​Last week we crossed $15 million in annual recurring revenue (ARR) for ConvertKit, my email marketing company. My original dream was to get to $600,000 in ARR, so I'm pretty thrilled! Over the last six years I've learned and written about quite a few lessons, but it's always fun to reminisce on the highlights, that oddly enough mostly come from the hardest times.1. Focus is everythingIt's fine to start something on the side, but if you want to turn it something real it needs to move to the center of your focus. Years ago I decided to go all in on ConvertKit, moving it from a side project to my only project.Without that decision ConvertKit wouldn't be here today.Anytime someone brags about how many businesses they run I cringe. I'd far rather take one thing and do it really well. I'll leave the serial entrepreneurship for the scattered, the wannabes, or those who are truly far more talented than I am.A friend told me the other day that he was surprised I still only did ConvertKit. At this point we have an incredible team, available capital, and the leverage of an audience. Why not start something else and run it in parallel?Because I know myself.Focus is where I thrive. Focus is where I get results. Focus is everything.2. Choose a nicheChoosing a niche is the easiest advice to give and the hardest advice to take. When you don't have traction, it feels like choosing a niche will exclude the few people who are coming in the door. In reality when we chose "email marketing for professional bloggers" everything changed.Messaging became clear, the product roadmap was trimmed, and the prospect lists practically wrote itself.Without that change—without excluding everyone who didn't fit into the blogger bucket—it would have been incredibly hard to get off the ground.We eventually expanded to "email marketing for creators," which now includes podcasters, actors, YouTubers, authors, artists, musicians, and so many more. Even with growing into that larger audience we are still so much more focused than our competitors who target all small-businesses.3. Use sales to kickstart word-of-mouthWord-of-mouth is the best way to grow a company, but you need traction for the referrals to start. That's where direct sales come in. By choosing a niche, listing out your prospects, and getting in touch directly you no longer have to wait for them to come to you.Each conversation—even though most end in rejection—will teach you so much. At first it's one customer. Then five. Then ten.Immediately you'll notice something crucial: the customers you recruit are higher quality than the ones who just walk in the door. Why would you leave the future of your product up to just anyone who stumbles across what you create?Instead go out and sell to the customers you want. Then ask them for referrals. Finally, when the word-of-mouth referrals kick in, they will be to the right people.4. Do the hard work that doesn't scaleEach sales call would end the same way: "I love what you're doing and I'd love to switch...but it's too much work. Sorry."Ouch. No matter how much convincing I did I wasn't able to overcome that objection. That is until I offered to do the full switch for them for free.That meant getting their account access, moving every form, copying and pasting every sequence email, exporting and importing their subscribers, and so much more! It was terribly unprofitable to do that for a $79/month customer. But early on that was how we got momentum. Every customer matters.So many people told me that wasn't scalable. I needed to use paid ads, SEO, or some other scalable way to acquire customers. That's great if you can make them work, but many can't. So I did the work that no one else was willing to do.John and Patrick Collison famously did this with Stripe. Rather than waiting to follow-up after a promising conversation, they would migrate other startups to Stripe on the spot.Don't wait for the follow-up or have the customer do all the work. Do the hard work that doesn't scale.Today we still offer a free concierge migration for anyone over 5,000 email subscribers. Many of our competitors have copied it and offer it as well.It feels good to make them react to us.5. Find what works and repeat itWebinars were the first scalable growth channel we found that really worked. My first thought was to do those and keep searching for the next thing...but then I realized that we should focus on what's working. We test and iterate like crazy, but then once it pays off we go all in.Over the last three years we've done hundreds of webinars with an incredible number of affiliate partners. They are hard, time consuming, and exhausting. But they work.Run all the experiments. Test. Analyze the data. The when you find something that works be prepared to go all in.6. Building infrastructure to support growth will take far longer than estimatedWe spent our first company retreat fighting fires and rebuilding our server infrastructure. What was supposed to be a time to just connect, plan, and get to know each other turned into an all hands on deck fight to keep our product online.I thought we'd spend nearly all our time building cool new features for customers. But instead the work was in doing what customers care about most: making sure the basics work well. Emails need to send on time and subscriptions need to work flawlessly.There's a lot of software that when it goes down, you just work on something else. Not email marketing. It's core to the entire business and reliability is everything.The infrastructure that was built to support 1,000 customers will break at 10,000. It's crucial to dedicate time to support the growth.7. Funding is optionalRight about now we should be raising a $25 million series A. Or at least that's what our peers are doing. Instead we haven't raised a single dime of outside capital. I put in $5,000 to kick things off, then another $50,000 when I doubled down on ConvertKit.Getting rejected by venture capitalists is one of the best things that's ever happened to me.We built ConvertKit our way, at our pace, and with our values. Every line of code is funded by the creators we serve. I wouldn't have it any other way.8. It's possible with a smaller team than most people thinkToday at ConvertKit we have 38 amazing team members. At $15 million ARR that is nearly $400,000 per team member! A much higher ratio than any of our peers. At this stage 75 employees would be normal.Instead of hiring as quickly as possible to solve every pain, we are deliberate about working on the right things. The constraint requires us to say no, not spread ourselves thin, and only do the highest leverage work.It also means that we can invest in each team member more and carefully craft the culture we want, rather than simply focus on reaching headcount goals.There are always tradeoffs, maybe we could move faster, build more, or support customers better. So we are still striving to find the right balance between team size, efficiency, and total output.9. Culture is everything—and it's not what you thinkWe have so many weird habits as a team at ConvertKit: talking about someone in the third person as if they're not there, long walks in pairs where only one person is allowed to talk, starting meetings by asking, "red, yellow, or green?" and diving directly into the hard conversations.That's because to us culture isn't bean bag chairs and free lunch, but instead an environment where conflict is kind and direct, expectations are clear, and trust is most important.Our version of culture has turned ConvertKit into a place that we all want to come to work.10. Share the profitsThere are two important factors for running ConvertKit as a financially efficient company:Transparent financials. Every dollar spent is visible to the entire company through our open books.Profit sharing. We share more than 50% of the profit in the company with the entire team.The result is that everyone is incentivized to spend money efficiently.We once asked the team: "would you rather go to San Diego or Costa Rica for the next team retreat?"Everyone said Costa Rica.So we did the research and found that Costa Rica would cost about 50% more because of higher housing costs and additional travel logistics. With the complete picture we asked the team again.This time San Diego won by a landslide.That attitude carries over to everyone when they use their company credit card. It's not just the company's money, it's their money. And they spend it accordingly.In the last few years we've distributed over $1,000,000 to the team in profit sharing. All while spending aggressively on growth. That's a number I'm really proud of!11. Always pay your debtsNo, I'm not talking about Game of Thrones, or even financial debt. There's another kind of debt more devastating to software companies: technical debt.The code that worked fine at $15,000 in revenue looks like a joke at $15 million. Not to say you should have spent the time to build it perfectly from the beginning—that's a fools game to try—but instead that every shortcut you take is building more debt. The longer you wait the more interest accrues.We've had to spend a significant of time and money refactoring all of that old code. It's part of scaling. Every software company has to do it, but it would be so frustrating if we didn't expect it and have a plan to pay it back systematically.12. As you grow, your company’s name builds equity. Don’t take that for granted.For years I've wanted to build ConvertKit into a global brand and I thought that meant changing the name to something more brandable. While being focused on this new change I completely missed the trust, care, and love our customers had for the name ConvertKit.You just quietly enjoy the status quo. People only talk about what they want to change. It would be weird to send an email to Patagonia saying, "I really love your name, please don't change it."So when we would receive emails every month from creators who thought ConvertKit was too salesy and they didn't want to be associated with the brand, that wasn't balanced by all the people who had quietly grown to love our name and the brand it represented.Ultimately we decided to stay as ConvertKit, which is a long story that I promise I'll write in full at some point.13. You don’t have to be an asshole to build a successful companyBeing an asshole is one way some entrepreneurs have been able to build big companies. Assholes are often loud about their own success, so we hear about them more than we should. But there are a bunch of good people building exciting companies too. Good people who care for their team, their family, and their customers.Ignore the entrepreneur media.Don’t be an asshole and don’t settle for working for one.14. Surprise launches aren't worth itA surprise launch or release is fun for you… until it isn’t.I love having my Steve Jobs moment by unveiling a new feature to the applause of a crowd. I've done it the last two years at our conference, Craft + Commerce. But behind each of those moments is weeks or months of pushing hard to make a deadline. Trimming the project scope, reprioritizing backlogs, and hoping that everything goes well in the live demo.But that's only part of it. What follows is releasing to customers, which is really painful if you missed the mark on any of your designs, planning, or timelines. That means a ton of tickets in the support queue, frustrated users, and losing confidence in the product.Now we've moved away from launching these big surprises. Instead we work with smaller groups of customers to understand how a new product or change will affect them. Then we use that information to build a smarter launch and rollout plan. A plan that usually involves methodically rolling out to a few features at once.We're still be able to make a splash, but we are able to do it with more confidence and a lot less stress.15. I felt most successful after the hardest decisionsWhile skiing a few weeks ago my friend Anthony asked the group, "do you feel successful?" It was a great question to reflect on while riding the chairlift. I'm always striving to learn more and grow the company, so it's foreign to pause and feel success. That feels like settling when I know I'm capable of more.Overall, I do feel successful, but I was surprised to realize the moments I felt most successful weren't after hitting a major revenue milestone or landing a famous customer.In hindsight, the times I felt most successful were when I leaned on my principles to make the right decision, even though it was incredibly hard.Letting a senior leader go. Rolling back a name change I'd worked on for two years. Restructuring the company.I wrestled with each one. Struggling to have the courage to make the decision I knew was right. But with principles to guide me I could make the decision with confidence.To me success knows that I've built the courage to make the right decision, especially when it is painful and expensive.​--Drop any questions in the comments! Particularly if they relate to software, bootstrapping, and more!

[programmingmadness]

I am currently in school for computer Science, but being honest I am terrible at school. I learn on my own so much better and faster, and I actually have flunked out several times before. I know computer Science is one field that it is possible (not easy, but possible) to get a job without a degree if you can prove you know what you're doing, but I'm also not sure when I can stop saying "I'm learning to program." and start saying, "I'm a programmer. Hire me." How will I know when I'm ready?

Hey!

I don’t know a whole lot about getting a job without a degree, but I’ll try to give you some tips.

Apart from a degree, companies look at the experience an applicant has. This means internships, projects, volunteer work, etc. So what you’ll need to do is build up your résumé. If you have the time, try to get an internship at a software company that’ll let you actually write some code - the more time you’re there, the better. Also try to join a/a few open source projects. This is probably most helpful, as a) your code will be publicly available for people to look at, b) large projects that go on for a longer period of time teach you so much, like refactoring your code once your architecture changes, e.g. Volunteering should be the easiest to actually get (if you’re not too shy to ask). Maybe your local church needs something to organise staff and boom, your CV has one more entry.

I don’t actually know when you’re supposed to be “good enough”. The handy thing with a degree is that at one point, you’re just finished and thus must be “good enough”. On the other hand, companies have told me that they don’t expect graduates to actually know all that they’re looking for, they’re more interested in their ability to learn new things and their basic understanding of computer science principles. I do know, though, that some of the job offers I applied to actually said that you can apply when you’re self-taught, so just keep on trying. If you can, I’d suggest not giving up on school entirely, because if you do make it, you’ll probably have it a lot easier. But you’ll have to decide for yourself if the effort is worth the potential benefit.

All the best of luck to you!