Parse error: in /home/surtees/ : runtime-created function(1) : eval()'d code on line 1

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home/surtees/ : runtime-created function(1) : eval()'d code:1) in /home/surtees/ on line 16

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/surtees/ : runtime-created function(1) : eval()'d code:1) in /home/surtees/ on line 16
Design in the abstract | DesignNotes by Michael Surtees
Screen Shot 2015-03-17 at 1.27.16 PM

Design in the abstract

From the outside looking in, design (and for this focus — product design) seems pretty black and white. A design now exists where before there was none. There’s an app on a person’s phone that wasn’t there before. A person interacts with a desktop application to get info that was once not available. Where there wan’t a helpful product before, there is one now.

For those working on the inside whether they are developers or designers know it’s not simply a flipping of the switch or following a number of predefined steps to create something that wasn’t there previously. A lot of the focus and activities for a designer are an exploration and connection of elements for a certain purpose. The catch is that a lot of the design is an abstraction of the final delivery that a person will interact with. One one side of the spectrum are the challenges of live data whether it’s info people are sharing online, geo related info or combinations of other api’s. On the other end of the spectrum are how people will want to interact and view the information based on their experience of what is laid out in front of them.

Over time as technologies come online, information is displayed and understanding of how a user reacts dictates the action. When talking about design in the abstraction, it is important to be clear about where in the process this happens to be. It’s possible that someone that is hearing about “design in the abstract” is thinking about the final product at their fingertip while I’m refering to it as a starting point before things go live.

Of course even “final product” is a bit of an abstract term. Products should be inherently improving over time.

If there isn’t a focus of evolving over to be one step ahead the product runs the risk of decaying. Steps need to be taken to understand how people are using the product. There needs to design benchmarks to measure if the experience is getting better through addition, subtraction and updates of features. Along with understanding how people are currently using the product, hypothesis need to consider how they will be better served in the future.

As new elements are added (or removed), older functionality, displays and interactions should be reconsidered. Simple questions about their usefulness need be asked and proper action should be taken if the answer is no. While the elimination of certain features that aren’t as useful, it’s not necessarily another black and white issue.

Features and elements that aren’t helping enhance the overall experience shouldn’t always be removed immediately. Having those elements in front of a developer sometimes motivates them to improve their service faster than if the element is taken offline and placed in a ticketing system such as Jira. Those decisions are case by case.

With all that said — displaying sub par experiences to a person using the product is never respectful of their time.

There’s a lot of different approaches to getting to the product’s promised land of perfection and efficiency for the person that will eventually use the product. Instead of laying out and comparing the strengths and weaknesses of some of those approaches, it might be worth asking a couple questions. How to manage time during a release? How to make the most of the team at hand? How does the person interact at all stages of the experience (first time, after a couple days of usage, and growing with the person using the product as they move from novice to expert). How do these things change when considered for an entirely new product, new feature or improvement of a current feature? These all present unique challenges and approaches depending on all of the above.


Working backwards through those questions, what’s the product type? Starting from the ground up let’s suggest a new product in the raw that is just bare-bones should take a couple months to get usable and testable. Working within the idea of units as weeks, 12 units seems to be reasonable set to build an atomic unit, settings and mild interactions. That’s roughly three months. New features to build off of could be 6 units (weeks) while an improvement of a feature 3 units (weeks). The idea is that over the period of a year there’s there’s three significant upgrades to the product. Again this is an abstraction of reality which might not be the fit for another group of people building.

So what is happening during those units of time? Looking from the top down, there’s an equal balance of development, design and testing running in parallel and together. Whether it’s a new product or iteration, the differences are time and information that is known vs blindspots where hypothesis are made. Connecting the unknowns to the knowns with both design and development within the units of time drive the abstraction into something real.

As users start to engage with the product, another level of design and development is introduced. How does the product work for a person using it for the first time? How does the novice person get comfortable over time, and what are the steps for the product to evolve and grow as the person becomes a power user?

A lot could be said with an onboard that isn’t overwhelming to new person having never used the product. Even more important is making it understandable about the product will make them better than if they didn’t start using it. If those things are done successfully the product has shot at being used a second time.

As challenging as it is to convey why the product is important there needs to be enough reason to come back again to use, and use again over time.

As a product matures the challenge becomes twofold. How to keep the product useful as technology evolves while staying understandable to people using the product for the first time. Products tend to get more and more complex as the core group of users mature with the product. Unfortunately for people experiencing the product later in the cycle for the first time time it can be overwhelming. One strategy is giving the expert user more control of editing what they see and how. What is difficult to do is to give these controls at the right time and not become a barrier for someone that is just learning about what they can do, not in the abstract but in their current moment.

Blog Widget by LinkWithin
  • Copycat Printing and Stationer

    Well actually its very hard to market abstract designs to public specially to those who doesn’t have artistic sides. But what other designers doing is they mix it up just to fulfill their passion as an artist and to satisfy their customers.