One recurring theme as I watch the way our team works: the fine balance of design philosophy (why) vs. Get-Shit-Done attitude (how):
Are we just copying what we see? As designers, are we more often emulating what we see around us rather than “designing” or creating something new. Is it the job of the Artist to be “original” and the designer to emulate? or does the designer constantly look for opportunity and create smaller shifts as they observe. If an artist is large jumps, is “design” a series of smaller responses and shifts over time? Would a client understand something they’d never seen before… something without visual roots or a comparison… “Microsoft is using flat design, so can we”? or to truly change the landscape, it it a series of small moves, tied to a known history that allows designers to be original… And do we really understand what we’re doing?
In some ways this conversation is half in my head, and fragmented between many good conversations on our team. A little bigger than the response to skeuomorphism in the current design trend in flat design. The internet makes it too easy to borrow when convenient and trendy. Guess it’s a good thing I like most things (except the color-blind colors :/ ) about the current design trends. No one trend or concept stands alone without perspective.
One thought that brought me back to this subject this morning while reading an article by John Maeda:
Ultimately, good design will be born from consideration of multiple perspectives. It should be something we haven’t even dreamed of yet.
How do you create “successful” software ?
The first ingredient is having a vision. Something you’re passionate about. And how that vision is vetted, digested and eventually executed on. Digesting that idea into its essence and creating a minimum-viable-project plan that can be developed.
The second ingredient having the right team: a great client, project management & requirements, a group of dedicated developers and designers aligned to the seeing this vision succeed. Executing on this plan through Agile software development & launching the beta software.
Sparc has done dozens of projects internally & with commercial partners. We know how to design & develop software. But does that make it successful?
The Success Phase.
We understand the “Idea” phase & we understand the “Build” phase very well. What we’re quickly learning more about is the “Success” phase.
This is the phase that happens after a software launch and has begun to receiving feedback from the marketplace. We came to realize quickly that if we don’t support our clients in being successful, no matter how good the idea or software is, the effort fails. When a client talks about his experience with SPARC, we want him to recollect a team looking to make him successful, not just robots who build software then blindly move on to the next project.
Part of the phase relies on our ability to help the client market their product. Our clients vary greatly in organizational size from established companies to start-ups. Some organizations have a degree of experience or people in marketing roles, but they all have the same post release challenges. We’ve invested heavily into understanding this process ourselves with our own products, so it makes sense to do the same with our clients. The design & marketing efforts we need internally is the same needs of our clients.
No one on our design team is a single role player. Every designer has strengths in building websites, collateral & advertising. Following the release of software, that same cross functional team of requirements, marketing & designers can continue to support the client’s marketing efforts. And it’s that alignment between our team and the client that help make the software successful.
I think part of being a good designer is to constantly look back and analyze your habits: where or from whom they came from. Think back to the art director who taught me to do one more iteration. Or when I learned to create one more design that makes you uncomfortable. Most often I trace many things I do well back to my first year of architecture studio and the design habits that I carried forward from there.
Always be ready to present.
One of the habit instilled early on was to always be ready to present. period. A teacher will walk by your desk after you’ve been up all night, and in a casual manner, ask you what you’re working on. easy right? Not always. Sometimes it hardest to explain what’s seems to work in your head, much less have the “work” in a state where you can show it to others. There is always a very messy series of iterations before the final design starts to emerge. Failures are great to learn from, even if you suddenly need to present your failures to others.
These days, our design team works in an Agile software development environment. It’s loud and chaotic. And priorities shift daily, sometimes hourly. Staying focused is hard. Being able to switch gears and talk about a design to co-workers or a client is essential. Sometimes it’s a keynote presentation, or PDF post to basecamp. More often then not it’s walking a client or developers through a raw illustrator artboard. The process & the failures & where the final work is starting to emerge. I’ve been able to observe in our junior designers: it’s these agile, micro presentations that get you comfortable talking about your ideas in any audience.
Encourage feedback through presenting.
Showing your work should always have a goal – some question you’re looking to have answered a little more complex than “do you like it”. A goal to present “something” by close of business with the client/team helps keep you accountable. We use basecamp a lot for this. It keeps the process of presenting work informal & conversational. It also gets the designer out of their heads-down mode and forces communication. Most often designers would be happier without feedback. The simple act of posting a design is huge for both parties: For the client, it adds transparency and let’s them participate in the design process. For the designer, if gives them pause to collect their thoughts; A chance to articulate thoughts & “finish” something, if only for the day.
In the end, it doesn’t matter the state of the project, the size of the audience or how you deliver your thoughts. As you design, you should always be ready to present.
Quick thought that should be incorporated into a bigger post someday. I came to “design” through an education in Architecture. Little unconventional, but there were several messages that were imprinted early on, and I still come back today.
3 rules for solving problems.
Something that stuck in my mind like glue from my first year of study was our professor Jay Stoeckel’s mantra: when you get stuck on a problem, change one of the variables. By changing either media, scale, or concern, you can often solve the problem that’s stopped you.
Change Media – getting away from the computer for the sketchbook? or charcoal instead of pen. Shaking it up a little will often open the problem up.
Change Scale – Get perspective on the problem, zoom out. or zoom in: is there a small detail in the design that starts to solve other parts of the whole?
Change Concern – this is probably the one I use most often: what is the concern of the problem resented to you? what does it seek to solve? And when you change that intent, or question it, or find a new goal, how does that shift your thinking. In software, we often have multiple user personas; look at it to a different persona’s concern.