Any designer worth their salt knows that borrowing shamelessly or outright stealing are often touted as key skills. In the spirit of that concept (without outright endorsement) I'm going to apply that type of thinking to a post one of peers created recently. Which relates some of which we know about baseball and assessing skills to concepts around software architecture.
You can read this great post here and I'll pull Larry's concepts on baseball which are great guidance for anyone. (Well done Larry and thanks for the photo!).
Updates. You'll notice I only have FOUR for a designer. Are there more?
From Larry's blog:
This series was inspired by the book Management by Baseball.
In baseball scouting one of the biggest compliments that a player can receive is to be called a "5 tool player". This is a reference to the skills that make up a good, all around baseball player:
- Hitting for power: When at the plate the player can hit the ball with a lot of power, home runs and doubles are very common. Runs Batted In (RBI) and Total Bases (TB) are common stats to measure the power that a player shows.
- Hitting for average: Hitting for power is only one dimension of the performance at the plate (sometimes a player that hits for power will strike out a lot). When a player hits for average, that means that they reach base more often when they have a plate appearance. Batting Average (BA) and On Base Percentage (OBP) are common stats to measure how well the player does in this skill.
- Base running skills: How well does the player handle himself when they reach base. The obvious thought is how fast the player is in running between bases, but many of the best base runners are not the fastest, they are smart about the leads they take and are effective at breaking up a double play. Stolen Bases (SB) is the most common stat for this skill.
- Fielding: Good fielding is essential for a team to succeed. Sometimes players can be great at the plate, but will be called a "defensive liability" meaning their fielding is sub-par. Fielding Percentage and errors are 2 stats to measure this tool.
- Throwing: how well does the player execute throws once they have fielded the ball. Double plays turned (for infielders) and Assists (for outfielders) are stats for this skill.
So...how can we apply this to the 'design' process of software or experiences? Here are the skills I think are important. Everyone can practice these skills but professional designers have had some kind of formal grounding or education and experience in these areas. I've got four. What do you think?
Understanding of Visual Fundamentals. Much of software design is about how things look, how they feel, how they flow and how they are organized. A grounding in the fundamentals of visual design serves software designers well. Common areas of focus here include understanding how color, composition and typography influence the understanding and flow of an interface.
Being Contextually Aware. Do people use an application using one hand? Do they use it in a noisy environment. Do they have vision problems? What's their level of focus or attention when using an application? There are many ways to learn these things or make educated guesses about what they are but sadly they are seldom applied to the work we do with software design. Common areas of focus here include an understanding how to create a research plan, execute contextual research that plan and know which frameworks and principals are appropriate to analyze and synthesize concepts into models and requirements that are contextual relevant for the task at hand. But I digress, the simple way to say this is that you need to be curious. Some of the best designers I've met--the naturals--are those that have an innate sense of curiosity. Those designers that don't have that engrained get better by collaborating with those that do or developing those muscles so they can use them more naturally.
Knowledge of Craft. In the world of software architecture and development we tend to specialize in specific technology and platforms (.NET, Flash, Web Standards). This is often done to a point where our knowledge is so detailed in a specialized area that we're largely ignorant of the capabilities of other technologies or platforms. Some of the most effective designers I've seen today in terms of long-term vitality are those that remain agnostic and try to become T-shaped at any specific point in their careers--or fuzzy in the words of David Armano. This means having broad knowledge of what is possible in ALL solution spaces but also having a focus area--which can change as you go through your career. It's pretty hard for example, to focus effectively on the Web today without having a base understanding of how form (HTML), style (CSS) and Javascript (behavior) work together. But those that lack an understanding of the power that MVC or managed code frameworks can bring to, or can extend, Web experiences do so at their peril--or at are peril because they create experiences where the potential of the technology is left on the table. Designers are in a tough spot today in this space Many of us, including myself, start much of our design production process in tools like Adobe Photoshop that are so far removed from the process of modern development and production that it's akin to (showing my Chicago roots) "Bringing a knife to a gunfight." What happens to those designers when others move on to tools like Blend, Flash, Flex Builder or tools designeed for the standards-based Web?
Ability to communicate. Larry calls this out for the architect role and it's probably a universal truth for all roles in software or Web design but in the context of designer communication skills mean specific things that many professional designers are not good at. Namely, communicating the value of their efforts and communicating a narrative that can provide validity for the choices they have made. This is critical for designers because we work in a cognitive space that is different from our development peers and that space is called relativism. We defend and prove things by looking at what the potential of something is versus looking into the pass for predictive evidence that something will work (which is how the rest of the world works).
Recent Comments