Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have volunteered to give a one hour lunchtime briefing at my workplace to our user experience team. I have a passion and love for human factors and user interface design and have had my hand in it for entire (albeit short) career.
The problem I am having is it has been very difficult for me to decide how to focus this discussion so that I can convey some good information but within the one hour time limit. I was hoping to get input from SO on what you would be interested in hearing about that can also be contained within one hour. Here is what I have so far:
Introduction to Human Factors
Psychology Behind Human Factors
UID Principles
Usability Testing
Standards
Everything at this point is very high level. I am not sure if I should cut down the topics and dive in deeper, or if it would be better just to give an entire high-level presentation and encourage individuals to come talk to me for more information.
Update About Audience
The audience (the User Experience team) is made up of a number of individuals who already have a high-level understanding of what user experience entails. Many of the individuals are software developers and some are designers. However, not all the individuals are trained designers and it may be necessary to re-hit some high points. There are areas I see for improvement (which I could talk to). Unfortunately, I am not directly part of the group, so I don't know about the internal workings of the team (which would also help me better focus this presentation).
The scenario sounds a bit worrying to me. You have a UX team, yet they aren't that hot on UX. And you've got one hour to deliver stuff like an intro to human factors?
Find out where each of their weaknesses are send them on training courses. One hour is going to achieve very little.
Given your audience already has some background in UX, I’d use the time to present one to three case studies and lessons learned from your personal work experience. Describe a design or user performance problem, how you dealt with it, and what the outcome was. Select cases without easy answers, such as one where compliance with standards conflicts with usability test results, or where a general human factors design principle conflicts with theoretical or formal analysis (e.g., GOMS).
For each case, try to engage the audience to discuss the problem and how it can be resolved. Get them to identify the pros and cons of each solution, and see if they can come up with one that addresses all issues, for example how the design can comply with standards yet still achieve high performance in testing. It’s okay to present a case where you’re not confident in the actual implemented solution. The point is the get your audience thinking about usability and design.
By working with concrete examples, you provide the audience a chance to exercise the high level stuff it already knows. This approach will cover the basics but keep you from boring individuals that already know them at a theoretical level. If the case studies serve as good illustrations of areas you think the team can improve, so much the better. If it allows you to present a new principle or process beyond the basics, that’s good too.
In other words, treat your audience more as peers, like an academic presenting a paper at a conference, rather than like a professor lecturing to undergraduates.
I'd be sure to include examples of what you're talking about as it applies to your primary product(s). High-level for part of it is fine, but examples make it real.
Also show how human factors can aid in readhing the UE teams goals faster (X% customer satisfaction, faster time to market, etc.) Whet their appetite by giving them solutions to their challenges.
I'd suggest having a progressive customer viewpoint of the user experience in terms of
Basic Features (Must-Have)
Add-ons/Enhancements
Simplicity & Convenience
How to indicate the experience is Risk free (Security)
Coolness
Green factor
If this is for you UX team, I would think they have at least the 10000 foot overview already. If this is going to be a series of lunch-and-learn talks, then do the basics first and dive into specifics in subsequent talks.
If this is stand alone, I would hit the highlights fast (5 - 10 minutes) and then choose a specific topic.
I think a lots of DOs and Dont's is both usefull and fun to see.
Related
I often read about the importance of readability and maintainability. Or, I read very strong opinions about which syntax features are bad or good. Or discussions about the values of certain paradigms, like OOP.
Aside from that, this same question floats about in my mind whenever I read debates on SO or Meta about subjective questions. Or read questions about best practices and sometimes find myself or others disagreeing.
What role does subjectiveness play within the programming realm?
Sometimes I think it plays a large role. Software developers are engineers in a way, but also people. A large part of programming is dealing with code that's human readable. This is very different from Math or Physics or other disciplines with very exact and structured rules. Here the exact structure and rules are largely up in the air, changeable on a whim, and hence the amount of languages in existence. And one person may find one language very readable, and another person may find their own language the most comforting.
The same with practices. One person may not like certain accepted practices. I myself find splitting classes into different files very unreadable, for instance.
But, I can't say rules haven't helped in general. Certain practices have and do make life easier. And new languages have given rise to syntax and structure that make life easier. There's certainly been a progression towards code that is easier to read and maintain even given a largely diverse group of people. So maybe these things aren't as subjective as I thought.
It reminds me, in a way, of UI design. Certainly it's subjective, but then there's an entire discipline involved in crafting good UI and it tends to work.
Is there something non-subjective about the ideas behind maintainability, readability, and other best practices? Is there something tangible to grasp when one develops a new language or thinks of new practices?
Arguably your question is really about the distinction between programming, which is mathematical, algorithmic and scientific, and software engineering, which is subjective, variable and human-focused.
Great programmers are not necessarily great software engineers, and vice versa. The two skillsets, while not exclusive by any means, have less overlap than they appear at first. Their relative importance depends a lot on the project: a brilliant programmer working alone can turn out amazing examples of technical genius, and it doesn't matter that nobody else can understand or maintain it, because he's not going to share the code anyway. But move into an enterprise environment -- like corporate in-house software development -- and I'll gladly trade you ten "cave troll" geniuses for a mediocre programmer who understands the importance of readability and documentation.
It's been my experience that the world needs great software engineers more than it needs great programmers. Relatively few people in this day and age are writing software which is truly performance-critical (OS kernels, compilers, graphics engines, realtime embedded systems, etc), and the Internet allows mediocre programmers to quickly grab algorithmic solutions for problems they couldn't solve alone. But nearly everyone writing professional code has to work within a team. And team productivity rises and falls dramatically on the ability of its members to communicate effectively and distribute workload efficiently, two skills which are highly subjective and impossible to prove by rigid formula.
Most software engineering principles are built on experience rather than objective law. Much like the social sciences, we study, learn, adapt and apply -- but with no real guarantees of outcome. All we can say is that some things seem to work better than others in most groups.
I think, a lot of it is necessarily determined by how much our mind is able to process at one time. So it comes down to how much the language and tools enable a team or a developer to break down the problem into chunks that are meaningful by themselves, but not so large that it becomes too hard to grasp them. The common theme is the art of organizing information (in this case, the code, the logic, ...) But that's not so different from Maths or Physics, by the way.
Just as the best authors borrow from many styles, the best programmers keep a huge range of patterns in their mental arsenal. Slavishly following a few patterns and adhering to some absolute truth is both lazy and dangerous.
Put it another way, the day we rely on robots for code review is the day I quit.
It all depends on your point of view :-)
But to answer your questions, I think one way to view subjectivity is to recognize that software languages, tools, and best practices are a shared means of communication among individuals. Yes, a programming language is a formal way of instructing a computer how to behave, but a programming language may also be viewed as a way to define and communicate specifications to a high level of detail (the code is the ultimate spec, is it not?).
So as far as we may want to concern ourselves with the degree of subjectivity in software languages, tools, and best practices, I would say that the lack of subjectivity may indicate how well communication is facilitated.
Yes, individuals have certain proclivities that are expressed in their habits and tendencies, but that should not ultimately matter too much in the perfect platform for development.
Turning to my Maths PhD wife I asked if there's any subjectivity in mathematics. Her answer is yes there is, mainly in the way we as humans achieve the answer.
If a mathematical proof is the result, how you get to that result can vary. If the dataset is large you may need to use a computer, which can introduce errors, and thus debated about whether that is the right approach. Or sometimes mathematicians can disagree on the theory - one is trying to prove that x is true while the other is trying to prove that x is false.
I think the same thing exists in computer science. A correct answer is a program that runs correctly, but that definition of correct may be different for each project. Sometimes correct means no bugs. Sometimes it means running efficiently.
From here programmers can argue how best to achieve the "correct" result. A good example of this is is the FizzBuzz application. A simple answer would be just a for loop, but Enterprise FizzBuzz is also "correct" in that it produces the correct answer, but is generally laughed at as "bad" engineering due to its overcomplication of the idea (it was a joke app after all).
How large a role does subjectiveness play in programming? I'd say it's a very large part of what we do, simply because we are human, and because there are multiple ways of getting the "correct" answer so there is disagreement over which way is the best.
Studies have been done showing that certain practices reduce defect rates in software. For instance, a study found a strong correlation between cyclomatic complexity and the probability of being fault-prone. Other studies show the average effectiveness of design and code inspections are 55 and 60 percent. So it appears to be in our best interests to favor simplicity, check metrics, and do code reviews.
We're talking probabilities here, though. If I review your code, I'm not guaranteed to find 60% of your bugs. There are also few absolutes in software development; experienced developers know that the correct answer is generally "it depends." That said, there are a number of practices with objective data in their favor.
We are hiring a UX consultant, had a broadstrokes session with the company, liked their work, think the candidates are ok and now want a more concentrated interview with the specific UX consultant that will be embedded into the scrum team.
What questions should be asking that could weed out any dead weight candidates.
Thanks.
Ask Tog has a good Quiz. I'd also ask stuff on the Gestalt principles, but that's probably because I have a masters degree in HCI (as in that might be a bit academic). That said Gestalt principles are very important especially for things like Form design.
I guess also you could ask them what their favourite book on UX design are, if they can't list any that would be very odd to me.
Personal Experience A good UX practitioner should be taking an interest in the things they use personally. I would ask them what they use personally - obvious technology items like phone and websites, and also less obvious things like kitchen appliances and vending machines. If a UX candidate can't tell me what they observed in their day so far (e.g. the car or public transport they used to get to the interview), that's a good way to weed out the dead weight right there.
Practical Problems As with programming, the best way to assess someone is give them a real-world problem you're facing (or faced) and see how they deal with it. Their thought processes are more important than the answer.
I am a UI Designer/Developer and once I gave an interview to Verizon for UX Designer position. By the way, it was a phone interview. I never worked as UX Designer before. The person who interviewed me asked me about my past work experiences, skill sets and asked me if have contributed as UX designer before. With regards to technical question, he actually sent me a document which had some brief information (part of an application) and then a small interface (it was like a table with some graphic based information, and based on this information, the call center people would respond to user request). I was asked to study this table carefully and then i was given 24 hour timefame to suggest a changed table/design and was asked to explain why would i suggest those changes. Just by looking at that single page document, I didn't understand the problem itself and didn't know what to suggest. I spent 23 hours just looking at the problem and on the 24th hour I did make a suggestion and send them my reply. But didn't work ..... i never heard back from Verizon.
As a UI Designer, I have worked wiith lots of UX Designer and all I know about UX design is that you have to understand the problem very carefully. You need to look for all posible solutions and use the one that would best satisfies the usesr needs. And then you must know how to create wireframes.
Ask them how they would go about designing the UI for some system. Tell them to design a solution for some domain which you know well (for example one of your recent projects), so that in the interview you can take the role of the user. Then the UX consultant will need to dig the necessary requirements from you, find out what is the problem that needs to be solved, and then designing and testing a solution.
Or if you want to make it easier/quicker, use a domain that everybody knows, so that he doesn't need to dig the requirements from you. For example design a system for finding out in which of the nearby restaurants you would like to eat a dinner. In one hour you should get some understanding of what the consultant is like.
Give them some screenshots* of example pages from a selection of sites, some of which you consider good, some bad, and in varying degrees. Ask them to point out good and bad features in each (and there is some good and bad in every site) and explain their thinking. If they fail to spot something obvious, prompt them with a neutral "what about X?" and see how they analyse it.
* finding these isn't hard, but a little time consuming possibly. Even better if you can give them access to an actual browser so you can go over the "live" elements
UX work is made up of two parts: Research and Design. You need to be clear which you want most emphasis on: someone who can grok out massive taxonomies and build wireframes in their sleep, vs someone who has hundreds of hours of usability lab experience. (You can find people who have both areas of expertise, but people often lean in one direction).
Beware of UX consultants who have never been embedded in a scrum team before. They will need some bedding in time. If they are used to working agency-side rather than client-side, they will be used to doing shortish research projects and then leaving. This kind of "skirmish" is quite different to the long-view you have to take when working client side.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We're a medium sized engineering shop (10-20). We are great at prioritizing and structuring work on our user facing stories and making customers happy. But the cobbler's children have no shoes. If it isn't about customers, we have 0 process.
I'm looking for systems to ensure we correctly prioritize and accomplish the non user facing work to keep a dev shop running: QA environments (pretty heavy, in our case), continuous integration systems, the packaging, and so forth.
Now, resources are always limited. We don't want to give the cobblers children 10 pair of the fanciest shoes, and specialized bike shoes to boot. We want to do the right, necessary work, with the same scrummy discipline that is applied to the rest of our development.
Tell me what system works for you: how to you prioritize and organize non-user facing work ? I want systems that are simple and integrate smoothly with scrum.
(I'm aware of a red box at the top of this text, indicating that Stack Overflow's automated question parser thinks this is a subjective question that can't be answered - I think there are likely 2 or 3 excellent answers that can be or have been proven viable - and process is integral to programming. So here is some psuedocode representing our process. Fix this algorithym).
IBacklog GetBacklogForWork(IWork requestedWork)
{
if(requestedWork.IsUserFacing) return new PrioritizedBacklogRepository();
// Everything else. Priority largely based on spare time and who thinks its a neat idea
return new RandomizedPriorityRepository();
}
void HandleIncomingSuggestionsForWork(IEnumerable(IWork) ideas)
{
foreach(work in ideas) GetBacklogForWork(work).Insert(work);
}
Someone involved is using and depending on the results of the project. This is necessarily true; if it weren't true, why would you be doing it?
When you identify the person who most depends upon, or cares most about, the results of the project, you have the "user" that your project is facing. Make that person the customer.
IMO something like "QA environments" is, in a sense, user-facing work.
Quality is admittedly a "non-functional" requirement (so there isn't necessarily an associated "story"). But, you may have a non-functional requirement like "the software must be tested before it's shipped". You can assign a relative priority to such a requirement ("how important is it that software be tested?"), and then execute as usual (decide how to implement that requirement, estimate how long it will take to implement, schedule the implementation, assign the implementation, etc.).
What we do where I work is to have a percentage, right now around 15% give or take a few percent, that is spent on internal tasks that are non-user facing work. This way the technical debt is handled and if the task backlog becomes rather large then a sprint may be spent on it instead of new functionality. The way that last one would get pitched to the user or customer is that there will be a time where just maintenance and preventive work is done so there aren't any new functions coming after the next sprint.
That's one idea that can be tweaked a bit though it isn't necessarily fully flushed out yet.
The way I've seen it work more or less ok is to try to do as much as possible of the non-functional/non-user-facing as PART of a related user-facing activity, or the first user-facing activity that requires it.
This is the easiest to cope with, as it just reflects the needs of the development organization in order to maintain sustainable velocity moving forward.
Additional work which cannot be related will be done using a percentage as described by JB King.
The alternative of pitching it as an investment with such and such ROI to the PO is a theoretically sexy concept, but with real life POs I've seen it rarely works.
Its very hard to get POs to understand the investment, not to mention actually being strong enough to delay functionality for it.
Its sometimes the difficult role of the development teams to be the guys that "slow things down" in order to keep a sustainable situation.
Dev managers sometimes feel really bad about this whole sitation, regardless of the chosen approach. My recommendation both as someone who's been in that spot, as well as an Agile coach, is that as long as you feel you are doing the right thing for the business, focusing on non-functional work that is required NOW and has a relatively quick ROI, you should feel ok about this.
Cautionary note: This is an area where self-organization is really put to the challenge. Organization needs to trust the team to do the right thing, and the team needs to earn and not abuse that trust. Its a sign of maturity for an individual or a team to know the right balance.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose you're working on an enterprise project in which you have to get management signoff in order for you to develop a new feature set. Usually your management has no problem signing off on some bright shiny new UI feature. Unfortunately they have a hard time appreciating some behind-the-scenes issues that are crucial to the application's well-being such as transactions, data integrity, workflow routing, configurability, security, etc. Since they're non-technical and these issues are not immediately visible, it's not obvious to them that this is crucial.
How have you convinced them that these infrastructural issues have to be dealt with and that it is important to their business process?
Every craft has its unsexy sides. Things that HAVE to be done, but nobody notices them directly. In a grocery store somebody has to organize how and when to fill the grocery shelves so they always look fresh. In a laundry you need somebody who thinks about how the processes should be optimized so that the customer gets his clothes in time.
The tricky part is: The customer won't notice when these subtle things have been done right UNTIL HE NOTICES THEY ARE MISSING! Like when the laundry is not ready on time but two days late, or the veggies in the super market have brown spots and look terrible.
Same goes for IT. You don't notice good transactions until your major customer knocks on your door and tells you that an important and expensive project has failed because the database entries of your product were mysteriously mixed up. You don't notice good security until customer credit card information shows up in Elbonia (and soon after word is in the national newspapers warning customers of your company).
The thing you really have to hammer in again and again and again is that software is NOT static. It has to be cared for even after its initial development phase is over. It is not just a product you buy once and forget about. Every car manufacturer knows that services is of prime importance to the products they build, simply because things WILL occur that have to be fixed and improved. It's the same with software.
So make a presentation, visualize, verbalize, translate your technical information into benefits. Business people don't care about your wish for code aesthetics in a refactoring project, but they WILL understand that your changes will help the product to become more reliable, gain a better reputation and reduce the amount of future service requests. Make them understand by showing them the benefits!
Same thing folks have been doing for thousands of years: draw pictures. Diagram the problems, use visual metaphors familiar to your audience, drag the problem into their territory.
Assuming they're not being intentionally obtuse...
A big +1 for analogies and metaphors. If possible, find one that will resonate with the personal interests of your audience (if it's 1-2 people). For general metaphors, I often find myself using commuter traffic or subways, for some reason.
e.g. We are currently migrating an app from an OODB to Postgres/Hibernate: the bulk of this work is done in Release '4'. Many domain experts have been asking why there are so few user-facing features in R4. I regularly tell them that we have been 'tearing up the city to put in a subway. It is very expensive and undeniably risky, but once it is done, the benefits in R5+ will be astounding, truly.' The true conversation is more involved, but I can return to this theme again and again, well after R4. Months from now, I hope to say "You asked for X and it is now very easy -- precisely because you let us put in that subway back in R4".
The surest way to get upper level management to buy off on development work is to present it in a quantifiable way. Ideally this quantifiable measure is in $$. You need to explain to them the consequences of skimping on data integrity, security, transactions, etc. and how that will affect the customer\user community and eventually the bottom line. You should be careful in these situations because sometimes management expects these non-functional requirements to "just work." If this is the case, you should either estimate high and work on these items alongside the visible UI work (ignorance is bliss) or you need to document these areas of need as you communicate with management so if things do go bad as you anticipate, it's not your job that is on the line.
Unfortunately, it usually takes a disaster or two before this stuff gets the attention it deserves.
It really depends what your management is like, but I've had luck with good old honest-to-goodness fearmongering. If you go through a couple of disaster scenarios, and point out someone's going to get blamed if they occur, that can be enough to make their arsecovering instincts kick in and finally pay attention :)
Car analogies.
Everybody knows that 'system' and it's sufficiently complex to depict the dire situation.
I'm battling with essentially the same kind of situation. Whether it is sign-off by management or acceptance by a user/sponsor, the problem remains one of different vocabularies, priorities and perspectives. I asked a simmilar question here.
I also got diverse answers, tantalizingly close to useful, but not quite definitive enough. Browsing and searching SO using relevant keywords led me to find usable insights in various answers spread out over many unrelated questions. To find and extract these gems led me to pose this question on site-mining.
It would have been useful to be able to flag the various answers and see them all in a single list, but alas, that functionality is not yet available in SO. I suggested it on uservoice.
Hope you find something you can use from the references I gave.
The right kind of countering question is the secret.
Is it okay to crash every 5 web pages?
Do we have to protect the credit card numbers?
Is is okay to have to pay contractors to deploy a patch every weekend?
Did you want it now or did you want it to work?
Robustness. When it comes down to it, you need to talk their language, which is how it affects their bottom line. If its a security or correctness issue, you need to tell them that customers aren't going to want incorrectly acting products, no matter how nice they look.
I like the idea of Technical Debt, because it enables technical issues to be translated (albeit loosely) into money issues -- and money is something most managers do understand.
Although the idea of technical debt was originally applied to architectural issues, it can be used more broadly for any type of situation where there is pressure to take a shortcut -- that is, go into technical debt -- rather than do it right the first time. (Doing it right is the equivalent to saving up to buy something -- it takes time -- rather than buying it on credit and going into debt.)
Just as debts can be good (e.g. home loans) and bad (e.g. credit cards), so technical debt can be good and bad. I won't try to characterise the differences completely, but good technical debt can be tracked accurately, so that you know how much in debt you are.
So, try to explain your important, non-UI problem in terms of technical debt, and the cost of not fixing it in terms of paying interest on that debt.
A descriptive picture really helps non-technical people understand what you are talking about. For example, below is an example from Sun describing how information is processed in one of their somewhat complex applications.
(source: sun.com)
Trying to explain this application in words would be impossible to a non-techy. Pointing at the diagram and say look, this part is our weak point, we need to improve it. That will make sense to them. If they feel like they have some understanding of what you are doing, they will be far more willing to support your request.