You are currently browsing the category archive for the ‘Management’ category.
The big divide at work (for me at least) is between the hacker coding style of development and object oriented engineering. I’m in the OO camp, and my two superiors are in the hacker style camp. I’ve been working on the hard sell of trying to change how we develop as a team, and frustratingly enough, I don’t seem to be making much progress. Good thing I’m stubborn.
What I call hacker style is a method of development where getting things to work and out the door is the primary goal. Time spent thinking and planning development is limited to small scale, low level, single function planning. Nothing is really orchestrated, and the “system” is more of a patchwork of processes that when run in the right order, perform the overall tasks as though it were actually a whole. The focus is on speed, and being able to do new things.
Now, I don’t have any problem with that in general as there’s a trade off when moving to a more thoughtful, and deliberate OO style of development, which can have a real positive or negative impact on business. And for startup companies, hacker style is the preferred and probably optimal style of development. Business demands require speed and getting things out the door, so you can finally have a proof of concept that generates real revenue. Spending extra time to choreograph the whole system is money lost that’s hard to replace when you’re already on a shoe string budget.
Admittedly, I work for a startup, but it’s a startup with real revenue (million of dollars of revenue a year for multiple years with continued growth), and I’d says it’s in a transition between the “we’re still a startup” and the “we’ve got revenue streams to worry about” stage. The engineering team to date has done a great job doing what needed to be done. That’s something to be proud of, but now the code base is old and messy.
If there’s anything to be said about my last job, it’s that I’m experience in old and messy code (I’d include my time at Citigroup too, but the code was just old, not as much messy). And I’m definitely experienced in leading a development team to a more appropriate style of development. I personally prefer a more deliberate OO style of development, but my last job needed more hackers. Still, OO can be implemented with great successful if you have the right experience in earlier stages of the game. With this my new company, which is a little bigger, they’re about at the end of the hacker stage as I see it, but they’re holding on tight.
With a team of good developers, how do you transition them from being hackers to engineers, and what is the benefit of an OO approach to engineering as well as the business? As your code base grows, its complexity grows. Maintenance, scalability, adaptability, once corner stones of the hacker style, now become elusive and out of reach. Even with well build systems, things get old and messy. From my experience, most systems only last 4-5 years before needing a good overhaul, or the business risks losing it’s ability to change and respond to new situations. Developer time gets lost to fixing bugs and time gets eaten up by the many workarounds that inevitably happen when implementing additional functions and features.
The ultimate goal of OO design is building an intelligent code base. Intelligence is not a measure of behavior like most people think. Intelligent is an understanding that allows one to predict future events. A code base can “predict” future events by understanding what is likely to change in the future, and having that part designed in a way that makes changing it easy. You don’t make everything easy to change, but that which is likely to change. You need to manage the complexity of your code or it’ll blow up in your face.
People who aren’t familiar with OO design, or aren’t experienced with good OO design (it’s easy to screw up if you don’t know what you’re doing), they may see OO as more complex and slower to implement. When transitioning between development styles, in the short term that may well be the case, which is why startups generally don’t do OO design unless they’ve got some special previous knowledge in the matter. But as complexity grows, patchwork systems lead to more bugs and a more complex interaction that will drag down a development team, and in the extreme, can cripple a business’ ability to react.
One of the main pieces missing when doing hacker style development is a big picture view of the system and the various interactions. As the system was developed in pieces, the patchwork of functions were developed with limited consideration of other existing functions, and usually no consideration for upcoming functions. Without a big picture view, you can’t pull yourself out of that patchwork. You need a guide to get yourself to a better position.
There’s an additional drawback to the patchwork (utility class) design. Because it focuses more around processes and less around object relationships, it’s impossible to discuss the parts of the system. Engineers will be forced to learn from the code instead of other engineers. Additionally, as the code base is process focused, you’re code will give as much if not more weight to dealing with edge cases. This is part of the reason why engineers have a tough time discussing such existing code because you can’t generalize and talk about the overall interactions, but instead are caught up mulling over special cases.
The benefits of OO engineering range from greater ability to react as system complexity grows to better team communication as you move away from process acted upon multiple complex objects to relationships between a common set of objects. Getting a team to handle this change properly requires a map, but also vision and a mission.
Businesses have two functions. Marketing (PR, advertising, sales), and invention (engineering). The marketing side of the business will most certainly have a set of ideals such as VMOS (there are many varieties of this), vision (the dream), mission (what you’re trying to do in the next couple years), objectives (focus or important metrics for accomplishing the mission), strategy (lines of action for meeting your objects). The highest level long view down to actionable strategies. Engineering needs a similar plan that describes how they’ll implement the business’ VMOS. The engineering VMOS will reflect the business’ VMOS, but translated for engineers and around the act of inventing instead of marketing.
Somewhere in the objectives and strategy level, you can setup a diagram of your system. Not how it is today, but how it should be tomorrow. This’ll be constantly changing, but it gives engineering a way to communication, and a guide for how to develop. Where do you spend the extra time planning? What is really an at risk area? What functions are important to keep on the radar?
OO engineering can easily break down without a plan, but also without a leader. Just as the graphic design team will have a head designer who will pull together the design and keep it looking like one common design, engineering needs a head engineer to pull together overall development as though it was actually done by one person. Since any problem can be solved in 20 different ways, you need someone to short cut the discussions, and make a decision even if it doesn’t look like the best choice to everyone. Just because you’re given more room to plan and think deliberately, doesn’t mean you can waste valuable time not getting code out the door (I’m not advocating a waterfall approach mind you).
This gives the engineers the tools to both communicate and predict. With the high level ideals defined, you can develop a plan for transitioning. How do you meet business demands and still maintain and improve the code base? It’s laid out in the engineering VMOS. Without this, all you can do is react to the nearest term demands and situations, which becomes tougher and tougher the more patchwork and complex the code. The engineers are the protectors of the code, and they must always be mindful of that while they get pressure for more from the business, so you can’t let the marketing side make all the plans and call all of the shots.
Wrapping this up, both styles work with the variety of agile development approaches. Both styles have value for a business at different stages in it’s life. Both can be good or bad if you go too far to an extreme. Balance is key as is so much in life. In the case with my current job, moving to OO engineering removes much current and future complexity.
I recently posted some thoughts about P&L and my own version of P&L, productivity and learning. I’ve been asked to shed some more light on the subject of productivity, so I’m delving into the topics of capability and capacity. In my previous piece, I argue that productivity is made up of a few components, and capability and capacity are two of the tangible elements at play (other intangible elements would include level of challenge of assignments and happiness with work). I also note quality as a key component in the piece, but more as a component of learning, and less as a direct component, although still influential, with productivity.
Estimating capability and capacity judges readiness and ability to adapt. This allows you to highlight potential problem areas. The method won’t give you a number. It defines the boundaries of your team.
With this understanding, you can then see how your team’s characteristics match your overall functional priorities, and from that point, you can develop plans for getting or keeping your team aligned with your overall goals. In terms of measuring results, you want to measure based on primary goals, and not based on lower level components such as capability or capacity, or you greatly risk managing by misdirection (for instance, increasing productivity may have in impact on revenue, but could instruct people to push out crap instead of better satisfying the real goal). If you do develop a means of measuring sub-components of your team (for the purpose of reviews, and ultimately, effecting compensation), then it should always be understood in relation to the overall impact on the overall goals.
Capability is another way of saying, what does your team know? In understanding your team, you’ll want to map out the Domain of Knowledge that your interested in. You first break it down into a set of business or functional categories. Such as software engineers obviously need to know about writing code, but also potentially about the subject matter of the business itself like advertising, or farming, or insurance. You may think of 3 or 4 different areas of interest even if the primary area, engineering, is the main area of concern as understanding finance or marketing or design may play a smaller, but still consequential role in the team makeup.
Then see how your team stacks up against that breakdown showing you obvious holes. Both specific expertise and broad knowledge individuals are useful. Typically people with a broader knowledge base will be less of an expert in any one area, but could be just what you need. You have to understand the daily and weekly demands, and make sure that you team can meet those needs, but also the growing needs of an evolving business. People who are experts in a small area provide a lot of value immediately, but lose a lot of value if you go away from that area giving you potential incentive to not chance when you might need to.
Nothing mind blowing there, but if you don’t take the time to think about what you need and what you have, and how that aligns with your overall goals, it’s impossible to fix a problem when it arrives. And, if you’re lucky, you might be able to cut off some problem areas before they become a problem, or at least plan for a known gap.
Capacity can be variable based on your own ability, not experienced or skilled enough, but also extremely open to external pressure such as being set up with inappropriately short deadlines or simply too much work no matter how good you are. For a normal week, though, no work should require overtime*. If the normal operating procedure includes overtime like normally working 12 hours a day or working 6 days a week, then there’s probably something wrong with the system, and it should be investigated, and plans should be developed to fix that problem. Otherwise, the cost of abnormal pressure will become too much, and you’re out of room to be agile or adapt to changing situations, nor will you likely have time to innovate.
*I understand that some people will be exempt salaried and therefore not receive overtime, but I’m using overtime to mean anyone working more than 8 hours a day regardless of whether they explicitly get paid for it or not.
You’re able to handle a week’s worth of work, 40 hours, in less than a week’s time, something like 30 hours or less. You have time to optimize what you do, and research better ways of doing what you do, which would bring you up to 40 hours of work a week. If there’s a sudden increase in critical, time restricted work, then you probably won’t have to do any overtime to absorb the increase. This should be the standard for any given work week.
You’re able to handle a week’s worth of work, 40 hours, in a week’s time, 40 hours or less time. If you have a sudden increase in critical, time restricted work, you can still make a weekly deliverable with some minimal overtime, less than a total of 48 hours. Essentially, you can handle the work you’re given, and don’t have to push yourself to get it done in time. You can stay ahead of the curve.
You have to push to keep up, or barely keeping up with current workloads. Getting head of the curve is a problem. Probably have to work overtime more regularly to keep up with everything. You’re probably in over your head either because there’s just too much to do, or you’re not experienced/skilled enough to do the required work in the required time. Anything over 48 hours instantly puts you in this spot if not verging on an F.
There is no D. You’re either barely keeping up, or you’re behind and failing. This doesn’t mean you’ve missed deadlines, but it means you’re probably in risk of missing deadlines, if you have already.
Bringing these two components together, you can get a sense of how productive your team can be. Improving productivity would then generally be matter of realigning your team’s knowledge around the domain of knowledge, or fixing capacity problems that are causing even your best employees to have productivity pains.
I don’t like thinking of number of widgets produced as productivity, but instead as a combination of factors including capability and capacity. You can increase the number of widget your team produces without really improving the status of your team. And as a member of the team yourself, there are some good selfish reasons to keep your team running smoothly.
By mapping out the domain of knowledge, and having a standard metric for measuring capacity, you can approach someone with the power to fix the problem, if that not be yourself. Increasing hours is always a very short term solution that has major long term impacts on the intangible attributes of productivity if not kept to the short term. Rapid increases in productivity general come in the form of re-engineered processes, and not re-engineered people. People take time to improve either through on the job experience, or in the class education. If you’re not fundamentally addressing capability or capacity, then you’re not really dealing with productivity.
P&L is a common concept for managing and running a business. It’s the bottom line as they call it. If your profits exceed your losses, then you’re making a net return and that means you can stay in business. However, while this is a simple yet good tool for broadly measuring a business’s operations, it’s a horrible tool for managers understanding employees. And yet, this is what most managers worry about measuring. Instead, the real P&L measure that holds value is measuring productivity and learning.
I recently quit my job, and one of the fundamental reasons for leaving my position as Software Engineering and Design Manager was a conflict with my boss, the President, as he didn’t seem to view business and management as I did. As one of two owners, he viewed the business through the normal P&L lens. Nothing wrong with that, but he then applied pressure on the rest of the staff based on profit measurements and not productivity and quality (learning) measurements. Don’t misunderstand me, you should try and align your staff with how your business makes money, but as Product manager my ability to influence profits depended on my ability to increase productivity and quality of deliverables.
Misunderstanding this is a fundamental misunderstanding of how people operate, and that ultimately determines how a business functions. Every person strives to find flow in what they do. Most people find the most flow during work hours in contrast with leisure time which is sometimes more enjoyable and relaxing, but often lacking in flow, which is itself a sign of high enjoyment.
Finding flow is a balancing act that is different for every person and every team. Balancing the line between boredom and anxiety, or too little work with too much work, and not challenging enough with too much challenge is key to building a team that’s both productive and capable of streamlining the current business model. However, productivity is only worth so much. For example, China might produce a ton of widgets, appearing highly productive, but is the quality of each widget good enough. Americans might not produce as many widgets, but if you look at both quantity and quality, then you can get a true value of productivity and in turn Americans might be more productive.
After you measure productive, from a business perspective, cost then becomes a differentiating factor making up your standard P&L measurement. Of course, there a many factors beyond price that differentiate a business from its competitors, but often times, this seems to be where people stop, and that gets handed down from the top to senior, mid, and other levels of managers and employees.
To see the flaws in this mode of operating, consider my situation as the engineering manager. When managing you have to worry about capacity and capability of your team. Your team might only be capable of doing low level work, but they have the capacity to do a whole lot of it. Or, they might be capable of doing high level work, system architecture or feature design, but therefore have a lower capacity for that work (although, many times higher capable people also have high capacities for doing work). You need people at all levels to make a business function.
My team was mostly low capable staff, but they had decent capacity for work. My problem was that I lacked staff capable of doing high level work. So, I needed to incorporate a level of learning for the staff I had. Either through traditional learning like going to school, or I needed to figure out a way to do training through work, which usually means giving a person a task just beyond their threshold of knowledge or experience. Establishing this struggle generally encourages growth, and as the person internalized what they’ve learned, their quality generally increases with the challenges they overcome.
However, that’s only the case if that person has time to internalize what they’ve done. And this is where the traditional P&L causes conflict. Generally speaking, it assumes that more challenges overcome means more profits earned. In software development, losses are generally fixed in payroll, so increased quantity increases profits. However, there are losses involved in this process that tend to go unmeasured, or at least unmeasured as a real expense to the business. If quality is low, then work usually breaks and has to be reworked adding cost at a future date. The earlier you fix a problem, the less it’ll cost to fix, so high quality to start is a way of reducing future expenses.
You don’t improve quality without incorporating a training program for staff. If people aren’t learning and growing, then they aren’t going to produce quality outcomes or increase current levels of quality. In my job, the President was pushing the staff beyond capability and capacity, and because of this, quality was dropping and problems weren’t getting solved adequately. Additionally, there was not chance of learning from the challenges because there was no chance for internalization, or true learning and understanding. Staff wasn’t getting any more capable and yet demand was increasing.
To the owners, who only appeared to see profits and losses, they couldn’t reconcile my requests to alleviate problems with capacity and capability, which in turn is a function of productivity and learning. Clients were happy for the time being, but internally there was struggle that would only come out in time having a negative impact on clients. It’s a very serious challenge, and sometimes it’s OK to sacrifice a little of one for the other (keep clients happy to keep the cash coming in, but reducing your ability to respond and increasing maintenance costs internally). However, you have to have a long term plan of how to get out of that situation as any business should ultimate find a happy medium between challenges and ease. Flow is key in every business, and you destroy flow as my previous company did without an active, achievable plan for resolving the real underlying problems.
What does all of that mean? If you want to be a good manager, you need to worry about productivity and learning, or capability, capacity, and quality. Productivity is a measure of current capability and capacity, and learning is a method for increasing future capability and capacity (as well as establishing a environment for flow). And not to forget, quality hangs as an umbrella over this whole picture as a shield from future expenses, but also as a result from learning.
This is a continuation from Programming is absolute. Design is proportional. (Part 1). I apologize if the start is rough, I’ve basically cut up a large piece of work into smaller, easier-to-consume parts for internet reading. Still, I’m not that accommodating as I’d like to just get this out there.
The hardest part with going from programming to designing is that no one tells you how to program, but everyone tells you what’s good design. Programming conflicts are generally internal conflicts while design conflicts are generally external conflicts. If you’re used to the one, then dealing the other is like a punch in the face.
In a programmer’s world, clients don’t interact with code; they interact with results. Clients also don’t think they can or want to critique the inner workings of the software; it either works as requested within certain performance requirements, or it doesn’t. Life is simple in that sense. You can write test scripts (automatic and human run) that confirm a function works as it should.
This is tough for a designer because you’re being told where to start, where to finish, and how long that should take to do. Basically, the problem is solved, and it just needs to get itself done. This is typically why so many people fail to see how truly and abundantly creative programming really is. They can’t see where creativity plays a role, and assume a senior developer isn’t much more than a code monkey (or they can’t tell the difference).
In a designer’s world, clients interact with your design (your code). They care about their relationship with the product. You have freedom of creativity (relatively speaking) to get their message out. They tell you what they’d like to say, and you show them the best way of doing that. The challenge, though, is that clients think that because they’ve read a magazine, or used Microsoft Office, they have the appropriate tools for determining what’s right and wrong, good and bad about an interface or interaction. Clients will generally have an intuitive sense for good and bad, so you must always be open to listening (at the very least to not piss them off), but they rarely understand why they think something is off, and they most certainly can’t tell you how to appropriately fix that problem within the world of relationships and interactions this is the current design.
For a programmer, this is an affront to your work. You’ve never been given an opinion like this, and as the expert, how dare they have an opinion on how you accomplished the goal. They had a message. You designed an interface for them that expresses their message. End of story, right? You got from point A to B, and it’s done. They shouldn’t question it, but they do. Repeatedly. And the more people on the client’s team, the more conflicting opinions on what’s right and wrong that you have to negotiate and deal with. This is unthinkable in the programmer’s world, but a daily situation for a designer, and this is where creativity helps and inspires a designer.
Working Together: Programmers and Designers Holding Hands
Historically, I don’t believe designers ever really want to be programmers, but programmers tend to want to be designers. In today’s work web-based world, designers are being pushed to be programmers (or at least have some basics down), and programmers still want to design. The lines between these two worlds is blurring, but I see segregation (of work, not physical space) as being key. Separate, but equal in my book.
If you didn’t have deliverables and deadlines, then maybe you can get away with combining the two worlds, but an efficient worker is a person who can focus on relate-able tasks. As previously explained, design work and programming don’t relate well. However, you can create an efficient flow between the two.
Designers should typically start the process. A user’s experience begins and ends with the interface. Deadwebs, pages that look like they’re functional, but just static HTML and CSS, maybe with some JS if special additions are needed, but few moving parts. The designer should not care about what can technically be done. He should go ahead with an optimal plan, and basically say to the developers, “here’s what I need to do, now tell me you know how to do it.”
Now, this is where designers benefit from understanding the technology and understanding coding from at least a beginners perspective. Different media have different optimal formats, and are capable of different layouts. A designer who’s capable of understanding some of what a programmer has to go through will smooth over the process because the programmers will look at a design, and respond with what’s possible, what’s hard, but still doable, and what’s beyond being doable.
The factors the make something doable or not will change depending on the project and company. If you’re working on an established product with an established code base, then you might be limited based on original and on going technical decisions. Still, a good system should be architectured for the designer, allowing them as much flexibility as they could dream of (which is why I don’t like many of today’s frameworks such as JSF, and my team wrote our own framework that caters more to the designers while still upholding strong middle-tier and backend techniques).
This is where having programmers understand design helps create such a code base. Being familiar not only with basic composition and layout concerns, but also with designer tools such as HTML and CSS, (not just know about them, but how they’re supposed to be used) is becoming more and more desirable. Still, knowing this stuff that doesn’t mean a programmer is a capable designer, which in my book is someone who can go above and beyond, optimize and make efficient.
Don’t misunderstand what I’ve written about segregation by what I’m saying about knowing some of what the other does. Being able to do something isn’t the same as being able to do it well. If you can’t get in the zone with the work you’re doing, then someone’s planned something poorly. Either your manager isn’t planning the distribution of tasks properly (which can be caused by poor scheduling putting pressure on getting things done versus getting thing done right), or you accepting more than you should, and trying to do more than you can.
For each type of job, you need someone who’s capable. In my book, mediocre isn’t capable. I consider a person to be not-good-enough, mediocre, good (capable), and exceptional. What it takes to be considered any of these depends on the skill required for a task, but the different between mediocre and good is someone who can do a job and someone who can do a job effectively. Simply being able to do something isn’t good enough. You need to be able to do it well, having room to spare.
I don’t look highly upon someone how can do the work given, but has to work 12 hours a day to do it. You’re over your head. You have no flexibility. There is no long-term viability at that level because if more success comes from the current work, then you’re out of capacity already. A good worker is someone who can do a given 8 hour task in 7 hours (so just because a junior developer can do something in 16 hours, doesn’t mean he should being doing it. It takes experience, though, knowing the difference between an 8 hour task and a 16 hour task, and those marks lines are always moving). Anything worse that and you’re mediocre in my book, and in many cases that means that average ability isn’t good enough. I want to excel in what I do, and you can’t excel if others don’t have the capacity or ability to excel.
As far as skill sets, I don’t look down on programmers who can’t compose a page to save their life, but I would look down on a programmer who uses deprecated HTML tags and uses inline style attributes instead of CSS classes. In today’s world, this isn’t even at the mediocre level, this is at the not-good-enough level. As far as designers go, photoshop skills is OK, but no HTML, CSS, or JS deadwebbing skills is not-good-enough. Photoshop is fantasy land, and in the real world, usable results matter, and you can’t give a programmer a photoshop image and expect them to do it, or for that to work in the media environment that you’re working in.
In the Zone
Having these knowledge overlaps allows both designers and programmers to work together effectively. Segregating the work allows each person, though, to focus on what they know best, and get in the zone doing that allowing for optimized and efficient deliverables. By having the designers start the process, you can get the project off on the right foot, but it needs to be in a consumable format that the programmers can immediate run with such as a deadweb, and not just a photoshopped image. From there, the tasks require a back and forth, “hot potato,” process that keeps the work moving, yet located with the appropriate individual as someone who is capable of doing the work optimally, and not just capable of doing the work given the time.
This is how you build exceptional products, and keep your users and clients more than happy.
I’ve started writing about the differences between programming and designing for an application, cataloging the challenges and differences between the two, and how to manage both worlds from both the perspective of a manager and a worker. Because this has become fairly long, I’m posting it in parts in what so far looks like it’ll be a 2 or 3 part series on programming and design.
Programming is absolute; it’s about results. Designing is proportional; it’s about interactions. I do and have done both types of work for years, so I’m well aware of the challenges in each. Switching between a functional programming task and user interface design task, though, is like trying to play two different sports at the same time. It’s very taxing and mentally fatiguing even if you enjoy both individually.
Because of my experience, I’m well aware of the differences between each. Additionally, as the engineering and design team manager, I know what to expect from different types of people, and I experience the IT axiom that programmers make bad designers (and designers can’t code) on a daily basis. However, it’s not really anyone’s fault. It’s inherently different work, but there are methods for smoothing over the development process between these two worlds, so let me describe both worlds, how they’re different, and what you can do in smoothing over the interaction between each. Smoothing over the rough spots will make work easier, but also increase job happiness as it’s more fun for people when they’re in a groove, and really able to focus and excel at what they enjoy doing most.
The Binary Stroke
Programming is like traveling. You have a task that requires you to get from point A to point B. There are many possible roads, some better than others, some more interesting than others, and some with more existing infrastructure. There’s a predetermined destination (although not always well known or understood), and a set starting point. What you do in between, how you get to point B, is up to you.
However, as with any problem, there are always conflicting values that require compromise. In programming, you typically resolve conflicts between performance and process. You need to make a function that is fast enough, but handles many variables and lots of data at the same time. The more variables and more data, the more processing, the longer it takes. Or you might be fighting with memory and disk space (typically because of performance requirements) where memory is faster, but because there’s much less of it, it’s more valuable and easily consumed, and disk space is abundant, but slower.
Of course, you also can’t forget that in the real world there’s always an conflict with time. You might have to cut back on overall functionality in order to make deadlines and deliverables. You might not have time for all the polishing and perfecting that you’d like. Or possibly, everything else gets pushed back until you’re truly ready. Time can turn even a simple problem into a rough and raging Nile River.
Dealing with those kinds of problems is like coming to a river without an obvious crossing. You can search along the river for an existing bridge (search for solutions to this or similar problems by others), or find a low spot for easier forging (pick the low hanging fruit and find a way of solving the bare minimum as quickly as possible). You can build your own bridge for more appropriate crossing (write code that’s reusable with potential long-term returns), try a simply rope line (quick hack), or a setup a wooden foot bridge (non-reusable, but maintainable solution). Still at the end of the day, you know if you’re on the other side or not, and you know that you’re at a river when you come to it.
A good programmer will spend her time learning about coding principles and techniques. She’ll have an interest in new technologies that are just interesting in themselves, or useful in her own work like a new and helpful open source reporting package. She’ll try and stay up to date on changes in tools and emerging concepts while making sure the app server or JDK that you’re using isn’t totally out of date. And generally, she’ll enjoy geeking out with most anything technology.
Shining a Spotlight in Dark Alleys
If programming is like traveling, and problems are rivers and solutions are bridges, then design is like being a cop, and problems are criminals and solutions are tickets. Keeping the peace is a matter of keeping unruly people in line (fixing bad layouts and user interactions), and building relationships within a community that strengthens that community (setting up look and feel standards that enhance the important messages while still functioning in the face of conflicting messages). However, you’re not the judge or the jury (someone else will eventually tell you if it looks good and feels right). You’re given a list of potential crimes and criminals, and you enforce them based on the rules of the system.
Compromise is a given as a designer. If you think you can become a designer and be as creative as you like and call it a day, then those with the message (and the paycheck) will quickly set you straight on what your boundaries really are. A designer’s job is that of appropriately, consistently, and clearly getting a message out; someone else’s message normally. And when it’s someone else’s message, then it’s their ability to be creative or accept creativity that limits your work.
The most important concept in design and usability, and where true conflict occurs, is consistency. As I said earlier, design is proportional and about relationships and interactions. In code, you can break an application by setting a variable equal to 2 instead of 1. In design, changing the color of a button doesn’t break the application, but it could build inconsistency. Sometimes, in the right special cases, inconsistency enhances the message and design. In most cases, inconsistency harms the design, but you don’t feel the effects until you reach a breaking point.
One visual element interactions with all other visual elements. The more inconsistency, the more visual conflict. Our brains can deal with a lot of inconsistent design, bad layouts and interactions. However, it builds up proportionally, so a designer has a margin of error to work with, but there is a breaking point, and in all designs there will be conflicting messages on a page. A designer must find a way of enforcing the rules of the system and getting the unruly elements to still work together nicely. What most people don’t understand about design is that while one change is minor, 5 minor changes huge overall impact. This is even more challenging if you’re designing an application that has hundreds of interactions across multiple pages. Keeping cross page interactions and designs consistent is as important as single page consistency where changes on a single page actually effect the whole of the application.
A good designer will spend her time learning about design principles and new techniques for enhancing a process (like how to improve a signup form). She’ll have an interest in new, compelling, and provocative design. Some of it may immediately help in her daily job, but most of it will probably help indirectly by association as much as practical application. Still, she’ll have a desire for turning the good design she sees into something applicable to her own job, and not just depend on osmosis for her education and career improvement. She’ll have an interest in the latest trends (and historic trends) as a way of keeping designs culturally relevant while still being exploratory in what she does.
Waiting for more
This may be an abrupt ending. I’ve basically cut this first part out of a longer piece for ease of internet reading, but this topic will continue shortly in part 2.