In this era of Big Data where more than 90% of the world’s stored information was created in the past 2 years, there is a challenge that has emerged which we see very frequently.  The problem is “Dark Data” which is data and information that is segregated or hidden within an organization accessible by only a few people.

First, let’s address why Dark Data is a problem at all.  There are countless examples through history where one person or team makes a discovery but a completely different person or team creates a useful application…some that come to mind are ether (for medical anesthesia) and Teflon (for nonstick cooking ware).  With all the data accumulated in research and development today there are even more opportunities for applications resulting from solving the Dark Data puzzle.

At ExtensionEngine, a lot of our work involves solving the Dark Data problem.  For example, we recently completed a project for a large property and casualty insurance company where they had data spread across nearly 30 different regional offices and we were able to aggregate that information into a single data warehouse and then make it accessible throughout their organization, including from executive management to their field sales reps on iPads, and many others in between.  Another Dark Data solution we built and manage is for Harvard Business School professor Noam Wasserman’s research of entrepreneurial organizations and the founders who launch them.  Wasserman’s research was, for many years, “Dark Data” but then through a collaboration (CompStudy) with industry players including Ernst & Young, WilmerHale and Park Square, an executive search firm, we were able to create an application providing compensation benchmarking data for entrepreneurial executives.

Solving the Dark Data puzzle requires addressing the following issues:

• Creating a central data repository. Often times data is spread out across systems and formats.  Bringing it all together with a single ontology is key.
• Managing access.  One of the main legacy reasons for Dark Data is fear of it falling in to the wrong hands.  Designing a process and system to manage and secure access to the data is a top priority.
• Cleaning data.  Even the best systems will have data quality issues and making it easy and quick to ensure dirty data doesn’t get into the system and being able to clean or expunge dirty data that does get in is a must.
• Automatic publishing.  Ultimately, the key to solving the Dark Data problem is creating a way to automatically publish the right data in an informative fashion to the right people.  Often this means publishing using interactive charts and graphs.

Lorem ipsum, that place holder text that you often see in website and other graphic design, has been around since the sixteenth century by some accounts, but became popular in the 60s when Madison Avenue and the golden age of advertising took off.  Its use today in web design, however, is corrupting to the point that it’s become evil.

Do you think Apple uses lorem ipsum?

I can’t tell you the number of websites I’ve seen designed with lorem ipsum (some of those designed by yours truly).  Funny enough, I’ve even seen a few websites or products go live with some of that lorem ipsum placeholder text still there!  The idea that somehow I need to make a good looking website and then figure out what to say is absurd!  I think a lot of people do this because they (1) don’t know how to do graphic design and (2) they don’t know how to program but they do know how to write (or at least they think they do).  So many folks outsource #1 and #2 and put in lorem ipsum as filler until they themselves can come back after they are done and write the real copy.

So by the time a website creator figures out what they want to say, they already have pretty designs, beautiful buttons, cool interactive charts with nifty forms that all tell half a story that is certainly not aligned.  The end result is either a confusing user experience or a lot of wasted time and money spent fixing it.

I suspect the advent of lorem ipsum was for technical reasons.  Before the age of Photoshop, designers would have to actually draw things so it made sense to put in filler text while the actual copy was being worked out.  But today there is no need for that.

So here’s my advice to those planning to build a website.  Start with your message.  Then write a story in words and surround that with whatever the lorem ipsum equivalent of graphics and images is.  Once you’ve nailed your branding, messaging and story to the point where you know exactly the experience you want, only then do you commission expert designers and programmers to manifest your vision.

The last point I will make on this topic is don’t assume you personally know how to write well.  Most of us don’t know how to do that.  There are really talented writers/branding folks out there who for short money can help you craft a killer story.  In fact, folks who write copy are way cheaper than graphic design folks because the buyers of these services value the latter more.  Think of writers as the equivalent of OBP in the world of Moneyball.

For more than 15 years I’ve been on both sides of the table of selecting vendors for outsourced software development.  Most of that time I’ve been on the “buy-side” hiring companies, but for the past few years I’ve been on the “sell-side” here at ExtensionEngine…in total I’ve seen hundreds of projects worth tens of millions of dollars during which I’ve made pretty much every mistake you can imagine.  Based on that, here is my list of  ”how to” tips that hopefully will help you avoid many of my pitfalls and achieve great results for yourself.  If I were tasked with selecting an outsourced development partner, I would:

(10) Define the project. The first step in outsourcing is to define the project or initiative (which I’ll call “projects” here).  The project definition should start with an answer to, “what business metric are you attempting to improve, and how?” followed by more mundane descriptions of scope, schedule, budget, etc.  The more detail you can provide, the better.  Writing a full RFP is the ideal, but an outline will often suffice.  Here is the checklist we use when initially trying to understand the requirements for a project, which gives you an idea of what an outline might look like.

(9) Create the right cohort.  Not every job is a great fit for even the “best” vendor.  I always get a laugh when someone calls in to ExtensionEngine and says they’re sending out a RFP for a project to “their neighbor’s kid,” ExtensionEngine and IBM.  Instead, what you want to do is create a cohort that matches your project on at least two dimensions: (a) size and (b) service offerings.

(a) Size.  To grossly generalize, there are three sizes of projects: small (<$100K), medium ($100K to $1M) and large (>$1M) and similarly there are three sizes of development vendors: “tall” (<100 employees), “grande” (100-1,000 employees) and “venti” (>1,000 employees).  If you have a small project, any type of vendor can do it, but realistically a “venti” vendor has too much overhead to do it practically–generally speaking you should focus on mostly “tall” and maybe one or two “grande” vendors in your cohort.  If you have a medium project, every type of vendor is going to claim you’re in their sweet spot.  That said, you should focus your cohort on “grande” vendors with one or two in the other categories so you have a full spectrum of opportunities.  Lastly, if you have a large project, you should rule out “tall”  vendors and focus on “venti” with one or two “grande”.

(b) Service Offerings.  Outsourced development partners have a wide range of service offerings–you want to make sure there is a match between your needs and the cohort of vendors.  Are you looking for engineering resources only that will be managed by your internal team (a service known in the biz as “staff aug”) or are you also looking for business strategy, user experience, graphics/design, dB/architecture, QA, customer support, engineering maintenance, advertising, etc.?  Make sure vendors you’ll be looking at offer what you need.  This matters most for the smaller vendors who, due to limited resources and specialization do not necessarily have the full breadth of offerings.

Based on the above, you’ll want to create a list of 5-10 vendors that match the general criteria of skills and interest.  Once you have your cohort, you can run them though the paces (including the rest of this list) and ultimately select one.

(8) Don’t ask “where” ask “why”?  Almost every client of mine asks “where” our technical resources are located, but only the savvy ask “why”?  Location has a few tactical implications (e.g. time zone) and every country has its stereotype, but what really matters is the strategic basis of the location.  You want to know how the location decision affects the quality of service, competitive advantage, rate of growth, profitability, etc. for the vendor.    For example, with ExtensionEngine, our technical resources are primarily located in Split (population 500,000), the second largest city in Croatia.  One of our co-founders is originally from Split and after living and working in the US, he recognized the opportunity.  By locating our R&D center in Split, we have the largest independent development firm in the city, providing access to world class talent.  Located on the Adriatic coast, Split is a beautiful place to live and enjoys a 3-to-1 cost advantage over the US.  And with Croatia joining the EU in 2013, we bring stability in terms of currency, intellectual property rights and with respect to international travel.  We’re not competing (yet) with the likes of Google, IBM, Infosys or hot startups which means outstanding talent and low turnover (<5%).  All of this provides a competitive edge the benefits of which inure to our clients.  So bottom line, ask “why” the vendor’s resources are where ever they are.

(7) Probe relevant experience.  I often get asked, “does ExtensionEngine have expertise in Java [or .NET or PHP or Ruby or some other language]?” and I often joke that this is a little bit like asking your auto mechanic whether they use Craftsman or SnapOn tools.  Understanding basic capabilities is important, but what you really want to know, is do they have current, relevant experience.  The first cut at understanding experience is to dive into industry expertise, but even within that, there are many specialties.  For example, “financial services” is really broad so if you have a “mobile banking” project you want to dig deeper.  Sure any shop worth their salt can get up to speed quickly, but I would weight heavily the vendor that has current relevant experience [obviously you need to dig into any competitive issues].

(6) Meet the team.  Everyone knows that when hiring a lawyer, it doesn’t matter whose name is on the door of the office so much as who is the partner working on your account (or the associate, for that matter).  The same goes for selecting an outsourced development partner.  The people that you’re dealing with on the sales process are going to be convincing (that’s why they got that job), but what really matters is who is going to be on your implementation team.  Most vendors won’t be able to tell you the entire team (if any) prior to signing a contract, but some will be able to tell you the “engagement manager” (especially the small and medium sized vendors) who have less bureaucratic staffing processes.  I would go through the entire vetting process (again) with the specific engagement team leader…it’s one thing for a firm to have specific industry experience, for example, but it only really matters if your team has it.  Also, you want to get a measure of their personality…it’s the same sort of process you would go through for a direct hire.  You want to make sure they fit your culture as well as bring the “right stuff.”

(5) Understand their methodology.  For web and mobile applications, almost every vendor will profess some sort of agile development methodology, but in practice I have seen many (especially the large) firms simply call their old waterfall process “agile”…essentially putting lipstick on a pig.  You should probe the vendors on how they manage sprints in terms of people, technology and process.  Ask for samples of burn down charts and velocity reports to see what sort of rigor they employ.

(4) Push them on the approach to your project.  During the vetting process, I’d push the candidate vendors to provide very detailed proposals for how they would approach your project.  Attack their technical recommendations and see how they respond.  Do they have conviction or are they “yes men”?  You’ll learn a lot during this process.  Some vendors will provide valuable insight and others will be going through the motions.  How they respond should factor in somewhat in your ultimate decision.

(3) Leverage intangibles. When negotiating, particularly with the small- and mid-sized firms, you can use “intangibles” to help lower price and align long term incentives.  By intangibles, I mean things like offering to do a case study or be a client reference.  You can offer to participate in one of the vendors webinars or even to make introductions to peers at other organizations, helping with sales leads.  Not only will these kinds of “free” offerings help you win concessions in the contract negotiations, they will also ingratiate you with the vendor and ensure that they keep you happy long term (would you upset a client that is a prominent case study and customer reference?).  I often see clients “hold their referencibility” until some future date thinking that the vendor will work hard to earn it, but my experience is to give it out early and often to get the most out of it.

(2)  Check References.  And I don’t mean ask the potential vendor for 3 client references.  Asking a vendor for references is going through the motions of checking references.  That is actually a waste of time.  You should reach out to clients that the vendor listed and get blind references.  Don’t underestimate the value of LinkedIN in this process.  If you don’t already have a “business” account, you’ll need to upgrade (costs a very reasonable $250).  Then you can search for people who work at the listed clients and reach out to them using INmail.  Messages cost $10 or so each to send, but it’s well worth the time and expense to get some real feedback on the vendor.  Depending upon how much time you have, I would also reach out to former employees of the vendor (an easy advanced search on LinkedIN) and get their unvarnished feedback…you’d be surprised what a former employee would tell you!  The other thing I would do, is to take the feedback from reference checking, particularly the not-so-good stuff and talk with the vendor about it directly.  How do they respond?  Are they defensive or are they thoughtful?

(1) Walk before running.  Lastly, when hiring employees, years of experience have taught me to, “hire slow and fire fast.”  The same advice rings true for vendors as well.  It’s good to be always on the hunt for a talented development partner and it is often possible to bring them into a project gradually.  You should plan, if you can, on having a ramp up period during which time you can see how the relationship is going with a vendor.  Also, by messaging to the vendor that you are easing your way into the relationship and that there is more business to come if they perform, then you’ll get their full attention and, hopefully, the best results.

So that’s it.  That’s my 10 tips for selecting an outsourced development partner.  What do you think…are there other tips you’d like to share?  If so, comment here and I’d love to discuss.

I had the fortune of attending one of Edward Tufte’s one-day seminars in Boston last week. His seminars have become something of a pilgrimage for the data-minded, and whether or not you agree with everything he preaches, there is no questioning the influence he’s had on the science and art that has come to be known as Data Visualization. Tufte has got his presentation down to a science, and even works in some great one-liners (only the software and drug businesses call their customers “users,” and in both cases those users are really only there for one thing – the content).

The course was a full day event, and while not all of it was salient to UI/UX design, he did spend a fair amount of time highlighting some design heuristics that I think apply to what we at ExtensionEngine do for every project.

1. Information is the Interface. When designing for either web or mobile, often the easiest thing to do is to layer on lots of pretty graphics and animations, even if that means you end up “burying the lead” for the user. Especially in cases where you have lots of good data or information to present, design should be the enabler, not the end goal. Tufte cited the fact that corporate websites and presentations often have data broken up across 10 different pages or 10 different slides, making it a chore to consume all of that data at once and make the comparisons our brains want to make. A good counterexample is the sports section – millions of people can look at a table on ESPN.com that might have 10 columns and 30 rows, and not feel overwhelmed. Let the information itself be the interface, and let your users process the data on their own terms.

2. Pick your battles. When everything on a page is emphasized, then effectively nothing is; you’ve just increased the noise level. When you’re designing a homepage, if you highlight and put nice graphics around every page element, it will be difficult for the users to know what they’re supposed to read first, or how they’re supposed to follow your call to action. Instead, draw the users’ eyes to your tagline and the sign-up button. If they really want to get to your Management Background page, they’ll get there on their own.

3. 1+1=3. Two pieces of data means you have one piece of data, a second piece of data, AND the relationship or the space between the two. One of biggest ongoing UI challenges is presenting complex information in an easily digestible manner. When attempting to do so, it’s important to keep in mind not just the individual data points on which you’re reporting, but the relationship between them as well. So in practice, if you’re presenting data on heart disease, and you put the “patient age” and “rate of heart disease” columns next to each other, be aware of the effect that will have on the conclusions your users may draw.

4. Look to maps as the shining example of effective design. Maps are one of the first user interfaces, and are probably the most widely recognized. And generally speaking, maps have got it right. A map of the world can convey thousands of pieces of data, but it’s also easy for any one “user” to find the one piece of data that is most relevant to him. When you look at a map, you know that the lines drawn on it demarcate the boundaries between countries; words with the biggest font represent countries, smaller fonts stand for cities; rivers are blue and mountains are brown (and the little italicizes number is the height; a simple legend tells us how far one map-inch really is.

5. Don’t go bragging about your big swinging terabytes just yet. Designing for “big data” is a real challenge. Doing the same for “lots of data” can be easy – make sure you know the difference. If you’ve taken ten million measurements, it might seem like you have a lot of data, but if you’re just capturing the same variable over and over, you really just have one piece of data. If you’re trying to solve a bank robbery, two cameras trained on exactly the same place won’t give you 2x the number of observations. You need multivariate data – two cameras trained at different angles, plus a sound recording, plus a log of bank activity over the last week, plus some fingerprints – now you’re getting closer to “big data.”

One of the more complex data / visualization projects I’ve worked on is one that I’ve been involved with for a number of years: CompStudy.  CompStudy is a 12+ year-old survey of executive compensation in venture-backed and other high-growth enterprises.  The project is lead by Prof. Noam Wasserman at Harvard Business School in collaboration with a number of professional services firms including Park Square, WilmerHale, Ernst & Young and, of course, ExtensionEngine.  The goal of CompStudy is to advance the theory and practice of entrepreneurship through quantitative and qualitative research.  CompStudy started in 2000 and for years was run with a manual process of capturing survey data, manually processing the data and then physically publishing the results in printed form.  About 4 years ago, ExtensionEngine was tapped to redesign and rebuild the platform from the ground up with seven key drivers of success:

1. Centralized Data Repository.  Aggregate all of the data into one central repository with a single ontology.  The original survey had different data sets for life sciences and high technology for each year (16 data sets at the time of migration).  Simple things like tracking a single company over longitudinally over time was very difficult.  With a central data repository, better and perhaps more interesting analytics would be possible.
2. Easy Data Collection.  The heart of CompStudy is the annual collection, in survey form, of hundreds of bits of information from approximately 1000 companies that fit the target firmographic.  As part of the redesign, we wanted to make it seem (as well as actually be) easier for users to contribute the data.  This involved updating the layout of the survey, improving the branching-logic and re-organizing the questions.  We also wanted to expand the data collection to include not just the US and Canada, but also the UK, Israel, India and China.
3. Rapid Data Cleaning.  In the past, the data was dumped into MS Access and then manually reviewed.  This process could take weeks if not months.  With the new platform, we wanted to have both automated and manual tools to prepare the data for publishing in a matter of days!
4. Publishing data. Publishing the data was the ultimate goal and we wanted to replace the 100+ pages of printed charts and graphs with a simple, interactive online  experience that would allow users to search and find exactly the results they wanted and do it fast.  Since previously the results were published in printed and PDF form, there was a lot of sharing of the data, which we hoped to reduce by publishing online.  We also wanted to tailor the results published for users in different categories (e.g. survey participants would have different data from paid users which is different from investors who had many portfolio companies participate).
5. Deliver with a social wrapper. Ultimately the data are just part of the story, with CompStudy we wanted to interweave that with blog posts, video shorts and user forums and comments to provide qualitative analysis along with the hard numbers.
6. Internationalization.  Historically the survey was only in the United States, but the new site would support surveying in Canada, UK, India, China and Israel as well as the US.  This required not only multi-lingual support, but also multi-currency and localization.
7. Enable Ecommerce.  CompStudy is an expensive endeavor and we wanted to be able to offer the published research to non-participants, but to do that for a fee (to preserve the incentive to participate).

So with this ambitious set of objectives, we set off.  Over a period of about 9 months we created a new survey, consolidated all the legacy data, developed tools to clean and publish the data, not to mention internationalization and setting up ecommerce.

The data cleaning problem was particularly interesting and was divided into two buckets: (a) prevent errors from occurring and (b) find and correct errors after they happen.  For the former, we implemented validation logic where ever possible to prevent errors.  This went beyond simple checks like, “is the input a number” to “does this number make sense?”, e.g. if someone entered that they owned 100% of a company and also that they raised $1 million from investors, we would ask the user, “are you sure?”.  To correct errors after the fact, we built a simple set of tools to allow an administrative user chart, graph, filter and sort data in many different ways.  You can see in the image below, that an admin user can view data and find outliers (in this case a histogram showing gross proceeds from a round of financing and then looking at those with more than $50 million).  Further, the admin user can drill down to the underlying survey data entered by the participant and do things to check, for example, if public records show that company raising the round).  Ultimately, once the “submitted” data is reviewed and checked, then it is published to “live” and that is what is available to users of the site.

One of the coolest results from the new CompStudy was that the time from closing the survey to publishing the results was reduced from several months to just a few days.  This enabled more data to be collected at a cheaper price.

Another interest piece of the project was to build a “social wrapper”.  Not only did we implement discussion forums, comments, ratings and blogs, but also we created a mechanism to distribute video interviews and expert commentary via the CompStudy site (which has both public and private portions).  The end result is that now CompStudy is the undisputed leader in startup executive compensation but also is a platform for further research in and around entrepreneurship.

These two words sound similar and many people even use them interchangeably, however they are quite distinct. In the world of software and IT, every project however big or small requires both product and project management. For the very small projects, however, the same person will typically perform both roles and they often take a small percentage of the overall time invested in that project. But for larger projects these can become full time roles in and of themselves. If misunderstood, a project can become a huge failure, but if understood and executed well, you can achieve a wild success.

But first, some definitions:

Project Management. Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of a specific project. Think of it as keeping the “trains on time.”

Product Management. Product management is the discipline of planning, forecasting and marketing of a product at all stages of the product lifecycle. Think of this as planning the “design of the train, train routes, schedules, ticket pricing, etc.”

You can see from the above definitions, these are very different disciplines.

The Project Manager is primarily interested in and focused on:

• Staffing
• Scope
• Schedule
• Budget
• Quality
• Risk

Open APIs are all the rage now. Businesses are scrambling to put one together as quickly as they can. In fact, research firm Gartner predicts that 75% of the Fortune 1000 firms will have a public API by 2014. Such are the perceived benefits of APIs, or application programming interfaces, in an increasingly inter-connected world of technology in which websites and apps want to talk to one another, and computing becomes ever more pervasive.

In strict business terms, many APIs are simply necessary to outsource and deliver a variety of collaborative services. Sites and businesses as diverse as, for example, Facebook and Amazon have embraced and profited from open APIs. Of course, there is much more to the open APIs in Web 2.0, but there are enough pitfalls, too, in this rush to get one out the door and rake in the millions.

So you have lightning in a bottle and want to share it with the rest of the world. What should you do?

APIs hold exponential power and fit into our worldview of pervasive computing. But good APIs are notoriously difficult to deliver. This is not because programmers don’t know what needs to be done, but rather most APIs fall short because resource starved teams are focused on building the core product and are just trying to check the API box. However it’s not clear a bad API is better than not building one at all. To make the best impression on development partners, API developers need to aim a bit higher than exposing some function calls. Here are a few ground rules to get you started.

#1. Keep it simple. Do whatever it takes to make it easy for developers to implement. There are other rules but whenever in doubt, go back to this one. This is the one that matters most. Would you want to use an API that’s convoluted in its implementation?

#2. Get the big picture. The real trick to a good API is to focus on the complete “developer experience,” rather than focus solely on functions and data. That means surrounding the function calls with sample code, tutorials, forums, blogs, API Explorers, etc., is more important that getting the calls out. Better to have a small library that make’s it super easy to implement than a large library that’s cryptic and has little support.

#3. Think ahead. Just like any product, the initial release of an API is not the end game. An API is a partnership interface that will need to work over time. The function calls are only a minor piece. So, consider such things as access management (e.g. what if I forget my developer key), performance, versioning and metrics when building your API.

#4. Model APIs. If you’re thinking of creating or improving an API it’s a good idea to check some glowing examples out there. I can think of Twilio, GitHub, Twitter and Google Maps. All have solid offerings and serve as model APIs.

#5. REST + JSON + HTTP.  Unless you have a sound reason to use SOAP (e.g., enterprise WSDL requirements), go with REST, which is simpler and near universal. Developers will know what to expect. For responses, you can use XML, which is structured and flexible, or JSON, which is simpler to use in a browser. But if you stick by Rule #1, it’s got to be JSON.

Also use native HTTP. It has REST built in. So instead of using a URL like:

POST /myapp/object/update/{id}

You would instead use:

PUT /myapp/object/{id}

Where POST is used for creation and PUT is for updates. Your code on the backend should know the difference between a POST and a PUT. In addition you can leverage Accept and Content-Type fields to manage versions, request and response types, and multi-language parameters.

#6. Use Standard HTTP Response Codes. This is easy. If the API throws an error don’t return 200 and explain the error in the response body. Just use HTTP standard responses. They can be found here.

#7. Allow Paginated Results. Another easy one. Allow developers to paginate the results. You just need to handle start and limit. Bonus functionality would be providing the URL for previous and next or numbered page increments in your response.

#8. Return Related URLs in Error Response. Since you can return anything in your response how about the URL for the help page associated with an error or function. While not needed in the normal course of application development, it comes in handy when there’s an error.

So, even if you recognize the issues cited above, or go over a more comprehensive API Checklist, you may not have the time or bandwidth to ensure robust management, security and reporting. In that case, you should check out the growing list of API Management (APIM) providers such as Apigee, Mashery, Layer7, 3Scale and Mashape. You could outsource some or all of the API services. Some of the services they offer include:

• Authorization and Management. An APIM provider can manage onboarding of new users, key management, partner filtering, etc.
• API Explorer. Allows developers to enter parameters on a web page and view API responses right on web page. Very cool.
• Documentation. Automated and interactive API documentation. For instance Mashery’s I/O Docs lets a user see the actual response associated with a function right in the documents.
• Security and Load Management. Are you prepared for a DOS attack? API management firms can get robust defense systems up and running quickly. You should pay attention to the provider’s implementation model. Some providers require API users to make calls directly to the provider instead of you. That may make changing providers difficult down the road. Others serve as “Connectors” where API users still connect to your API, but all traffic is routed through the API management provider before it gets to your backend systems.
• Reporting and Analytics. Know how many users are on the system? What’s the growth rate of calls to a particular feature? API management firms can provide a rich reporting suite out of the box.

Some might say that building a robust API is not for the faint of heart, but it’s really not that daunting if you tread carefully. Besides, in today’s world, not developing one could be a bigger risk!

Finally, I would like to include a checklist of best practices for designing, launching and maintaining an open API:

API Checklist

1. Access
1. Developer registration and key management
2. Application registration and key management
3. Authentication and permissioning
4. Partner filtering
5. Security
6. Traffic control
7. Rate limits
8. Encryption logging
2. Getting Started and Documentation
1. Reason to use, benefits
2. Getting started guide
3. Tutorials
4. Sample code
5. Reference documents
6. Blog
7. Forum
8. FAQs
9. Pricing
10. Terms and conditions
3. Performance
1. Concurrency
2. Spikes
3. Reliability
4. SLAs
5. Availability reporting
6. Error tracking
4. Over Time
1. Versioning
2. Communicating your roadmap
3. API Metrics
5. Bonus Points
1. API Explorer
2. End-user on-boarding

The list can be daunting but keep in mind that not all of this needs to implemented up front and there are a number of API management firms that can bridge the gap until you’re ready to build this yourself.

The Internet has profoundly changed our perceptions about a number of things, not least the concept of time. But has it sufficiently changed businesses’ perceptions of its consumers?

Take a simple thing as a website’s look and feel, and consider what it evokes in your users.

People, obviously, have different expectations. Still, most of us think we can gauge user expectations to some measure…the proverbial ‘focus group of one.’ But what we may not recognize is the dynamic nature of these expectations, and the rapidity with which they change over time. Consequently, it is critical that businesses recognize this fundamental dynamic and do so in, shall we say, Internet time.

One of my favorite anecdotes to bring home this point concerns a client of ours. The client offers products and services in the student / educational space and is probably more vulnerable than others because a large proportion of its users are so-called “digital natives” whose online behavior changes faster than most. When we began our “Discovery” process, the company was solidly skeptical about the need to spend money and time on a UX upgrade.

But you would be surprised how quickly the client changed their mind — based on some end-user feedback. Here is the gist of what that student said in a videotaped focus group of the company’s then website:

“It looks dated, old and stuffy…I fear the content might be old as well.”

Such a perception — even if it weren’t true — could be a deathblow to any company. Our client recognized that the perception was real, even if it wasn’t true that its content was not updated. To its credit, it was instantly persuaded, admitting that it hadn’t realized how much impact the look and the feel of a website has on the end user.

What is striking in that user feedback is the intuitive connection users make between a site’s look-and-feel and its content. In the Internet era, old wine in a new bottle is, perhaps, better than old wine in old bottle. Of course, the link between design and content is not the only finding that impacts users. Let me share a few other bits of user feedback on our client’s website that are quite remarkable for what it tells us about user expectations.

“Classy elegant streamlined logo but the rest of it looks like back end search. Definitely be more attractive as a web app.”

“Would like to choose sources to search.”

“I wish I could drag and re-order saved content/searches.”

“If there was a way to work with a team that would be helpful. Like Google Apps’ ability to share.”

The key thing to understand is this:

Users “interact” with any site, and its contents in myriad ways. What’s more, this process itself rapidly changes with technology.

Take, for example, the simple process of search, which has undergone dramatic changes even within the universe of Google. Different users interact differently with different search engines, or when using search features on websites. As is evident from the reactions above, users come to expect many other features seen in other sites. Consequently, businesses need to stay tuned with their users, periodically assess their changing needs and nimbly deliver on their expectations as they evolve.

Our “Discovery” process is geared to do just that and more. In this phase, we gather key information and data, and assess user experience/interface in order to formulate a sound strategy that will, among other things, provide a personalized web experience to users, extend the brand, increase market share, evaluate expansion opportunities and reposition the company to support future growth plans.

Once this preliminary evaluation is completed, extensionEngine’s team will outline a strategy that best fits the client’s need before collaborating in defining the scope of the project, its schedule and budget for development. We believe this will ensure that you will serve new wine in new bottles but at the very least be able to serve old wine in new bottle.