In the 90’s, when ECM solutions were rare, we could get away with designing solely toward requirements, but there is too much at stake nowadays. A recent study sampling various IT projects reported that:
- 62% percent of projects fail to meet their schedules
- 49% are over budget
- 47% have higher than expected maintenance costs
- And get this—25% are canceled before they are ever deployed!
If you’ve been in the software industry long enough, you’ve probably seen all of these things happen. The funny thing is, it doesn’t really come down schedule, cost, or requirements—it comes from bad design. When software companies think design, they’re thinking about contractual obligations and meeting commitments with their stakeholders. Here is a typical scenario:
Company wins contract. Client provides requirements. Company builds a solution, meeting the requirements. Testers validate requirements and application is deployed to a set of users. The users hate it and the client makes new requirements, company builds to those requirements, and the users hate the next iteration…and so on.
This can be resolved by utilizing user-centered design principles in your system development life-cycle. Software is not about code, it’s about people. Instead of our clients telling us what they want, we should be telling them what they need. As engineers, we can do a much better job building solutions then they can—that’s what they hire us for. To be successful, we need to incorporate user research, information architecture, interaction design, and usability testing into our process.
“Iteration 0” – 10 Tasks to Guarantee a Slammin’ User Experience
Let’s start with “Iteration 0”. This sprint is completely devoted to user experience. The point is to get out of habit of thinking of Java Beans and database schemas and start thinking about people. Here are tasks that need to be accomplished:
- Gather assumptions and requirements. Take some time to get acquainted with the requirements and begin to make assumptions based on your experience with the technology.
- Analyze competition. Familiarize yourself with the way your competition handles things. This is not necessarily the solution you should be striving for, but is excellent to have in your back pocket to show how your solution is better or to compare solutions to initiate change.
- Understand goals & tasks. Comprehensive user research, interviews, card sorting exercises, and contextual inquiries help identify user needs
- Develop personas and scenarios. Evangelize these with everyone on your team. They can be in the form of user stories, posters, work-flow diagrams, and profiles.
- Build a content strategy. Find out what content you have, what needs to be developed, what needs to be expanded, and what can be cut. Also create a schedule for delivering those missing gaps.
- Information architecture. It’s more than figuring out what content goes where. It’s also what information is most important to your users. Identify those needs and incorporate them into your design.
- Prioritize features. One of the greatest advantages of user centered design is that you often find some requirements barely impact your users. Those requirements can be re-prioritized so you can focus on what’s really important.
- Build wireframes and interaction designs. Setting expectations on functionality, how it should look, and how it should behave reduces future UI defects.
- Design a prototype. Build something you can take with you to road shows that incorporates both visual and functional design. Update the prototype during future iterations so you always have an accurate portrayal of what the product will look like at launch.
- Validate usability. There are hundreds of techniques, including a usability inspection (or cognitive walkthrough), paper prototyping, and eye tracking, but put something in front of your users frequently.
Points 8, 9, and 10 should be repeated throughout all future iterations until the project’s completion. When user experience drives design, you build products people love to use.
Great blog. Do you know of any standardized personas that can be used consistently across multiple ECM projects? Would you derive those bespoke per project?
Personas are design artifacts based on user research and interviews, so they’re gonna be different depending on the client. The idea is to get everyone on your team thinking about the different kinds of users they support, including their a biography, goals, frustrations, likes, dislikes, experiences, etc. With my most recent personas, I don’t think they could be applied to any other client. Next time you’re in the office, I’ll show you a few!
Got it. So, not really tied to roles or responsibilities. I look forward to seeing them!
These stats on IT projects have remained much the same for the past 30 years not just recently. Why?
Here’s what I have experienced in over 35 years at this stuff – things that cause projects to fail:
1. Lack of upper management support and business ownership, whatever the reasons: Intra-company political rivalries, turf battles, ignorance, naivety, selfish motivation, conflicting business objectives, etc. Be wary of any business that wants to turn over project ownership to the consulting firm or IT (unless it’s an IT project). Run away.
2. Inadequate analysis and requirements gathering; that is, consultants/business analysts without ears. No certification or process can overcome arrogance and stupidity. Listen, listen, listen, and you will win over the customer and get project acceptance.
3. PPP – Pi$$ Poor Planning that no application of process by itself can overcome. Common sense is not.
4. Inadequate resources – a corollary to PPP. (Especially NO training budget.)
5. Not accounting for being human. Nine women cannot have a baby in a month, no matter how much overtime. Had you done something more than PPP you would not be in a schedule crisis. Don’t punish the team for bad planning.
6. Inflexible slaves to the plan – you can plan the bridge but you still have to build the bridge. Be willing to revisit the plan and adapt to conditions as they occur. However, you cannot push everything off to the last day of the project.
7. The Lone Ranger is not a project hero. Project delivery is a team sport.
What I have learned: There are no technical problems that kill projects. They are all people problems.
Great list here and to touch on Jim’s question about scenarios and personas I agree totally – each project will be different and will require custom setups.
I do think though that a generic set of personas can most likely be built as the foundation for projects like we’re building now, such as a Case Management tool. Each client buying this app will have a core set of users that closely resemble core sets in other companies, industries, etc. Having that starting foundation can let you hit the ground running just a bit quicker.
Look forward to meeting you soon,
@Bill Those are really good points. I totally agree, it’s always the people problem!
@Jeff – Creating a generic set of personas is not user-centered design, it’s just guessing–which is what most software companies do when they try to build generic products.
There is certainly nothing wrong with guessing, but I wouldn’t design an entire system without interviewing real users first. Instead, I would hire a research company to conduct focus groups, but that can be kinda pricey.
Do you think you could find a generic set of “users” based on previous projects?
Your blog implies a partnership between the solution provider and the customer. In my experience, where technologists truly partner with our customers (each with skin in the game) to understand their goals, environments, and requirements, and take the lead in developing solutions based on shared understanding, we increase the chances of success. Your observations are right on the mark!
I think the most neglected part is content strategy. Designers tend to stop with the framework (site maps and wireframes) without considering what goes in it. It’s like having a beautiful store with no products in it. Have you had that experience, too?
@Cindy – That has been my experience too. I think content strategy is something every UX/IA person should learn. It’s a great way to balance user needs, business/marketing needs, search engine optimization, and advertising. Did you know that Google severely penalizes its PPC customers for promoting websites that aren’t relevant to what the users are searching for? Advertisers pay up to 10 times more for irrelevancy. Other advertising methods, like CPA (cost per acquisition) also reward for providing a positive content experience. Content strategy is the difference between making a sale and loosing a lead, but can also be the difference between life and death depending on the context. I think it’s a huge risk to not employ someone with content strategy experience.
Myself and my dad ended up speaking this yesterday. Thanks for the proof that I had been correct and after this I can relating to this!
Dude.. I’m not much into studying, however one way or the other I received to read a lot of articles on your blog. Its amazing how fascinating it is for me to go to you very often.