IxD Work on Various Product Types

12 Feb 2008 - 8:53am
6 years ago
4 replies
422 reads
Lukeisha Carr
2007

Hi All,

It seems that although IxDers do not necessarily have their hands deep in technology in terms of the implementation of it, we still need to know the capabilities of the technology behind what we are designing, so as to not request impossible solutions. Working on different types of technical products (other than web technology) is one of my goals for the future.

Those of you who do not ONLY do IxD for websites/web applications, what product types did you begin your IxD experience? Then, how did you transition from one to another? For example, if you started out in the web, how did you move on to doing IxD for medical devices, hand-held non-web applications, desktop apps, etc.? For, I would assume that the technology behind such products as medical devices is so very different than what is used for the web. Do any of you shift product types depending on the project, or have you just shifted product types as a whole? What is the most difficult part of making such transitions?

Thanks in advance for your responses.

Lukeisha

____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Comments

12 Feb 2008 - 11:04am
Michael Micheletti
2006

On Feb 12, 2008 6:53 AM, Lukeisha Carr <lukeisha.carr at yahoo.com> wrote:

> Those of you who do not ONLY do IxD for websites/web applications, what
> product types did you begin your IxD experience? Then, how did you
> transition from one to another?
>

I may be closer to the technology side than is really healthy. My design
work began with VB, Tcl, and C++ applications at a desktop software company.
I did both design and development work. Then I migrated to the web, took
Java classes, built many-many web pages and forms, JSP pages, Java servlets.
About this same time I started doing design work on the side as a volunteer
on various web projects. Another couple of leaps and I landed in a small
design group in a larger company, filling a role as something of a design
technologist. I created script components and page templates that the other
designers and the engineering team could use, and also led design efforts on
internal systems.

Then a big strange sideways hop to where I am now: the right-brained design
guy on the engineering team of a small software company building truly geeky
communications products, technologies, and APIs. I needed to do a deep dive
into the technology just to swim with the other fishes, and can now track
the local discussions of multicasting, supernodes, and graph theory. Or at
least mimic a knowing look and nod every so often. I don't code much here;
there are too many written/graphical/conceptual design artifacts and
sessions needed. When I do drop to the tech layer, it's to stitch together a
graphical skin with the underlying app. Our stuff is variously created in
VB, Java, C++, or as a web application.

I consider all this technology work as a sort of domain knowledge; it's not
really my design craft, just how it is currently expressed. When I did
logistics systems, I learned about customs and container security. When I'm
working on network software, I learn about TCP/IP. But I keep studying
_design_ no matter where, because so much of the design craft applies no
matter what the practice domain.

It is useful as a designer to recognize differences and limitations between
development platforms though. Web applications really sweat to maintain any
sort of internal state, which can often be defeated with a single press of
the browser's Back button. Mobile applications make the poor underpowered
cell phone or PDA processors groan. Desktop applications involve a fragile
dance with the underlying operating system's services and code modules,
requiring long test cycles and the single nastiest job in the technology
industry: creating software setup packages.

Not sure if this is what you're after, hope it helps,

Michael Micheletti

12 Feb 2008 - 2:17pm
Ari
2006

On Feb 12, 2008 9:53 AM, Lukeisha Carr <lukeisha.carr at yahoo.com> wrote:

> Hi All,
>
> It seems that although IxDers do not necessarily have their hands deep in
> technology in terms of the implementation of it, we still need to know the
> capabilities of the technology behind what we are designing, so as to not
> request impossible solutions. Working on different types of technical
> products (other than web technology) is one of my goals for the future.
>
> Those of you who do not ONLY do IxD for websites/web applications, what
> product types did you begin your IxD experience?

don't know if this counts but i started as a hobbyist developing my own
programs back in the late 80s just as 16 bit home computers were coming out.
think 8mhz and 512KB of RAM.

many of the features of these operating systems laid the groundwork for how
so-called modern OSs work - for ex: using resource files for separating
languages and text-strings from apps, windows, dialogs, alert boxes,
background tasks in the form of desk accessories, device dependency,
bitmapped fonts, etc.

i wrote simple programs that ranged from utilities (front end shells, disk
formatters and copy programs) to games and learned by creating or
experimenting with interfaces. later, i got into low-end game development as
a game artist, designer and beta-tester and did still more UI work.

> Then, how did you transition from one to another? For example, if you
> started out in the web, how did you move on to doing IxD for medical
> devices, hand-held non-web applications, desktop apps, etc.?

given my early exposure with so-called ancient computers, transitioning for
me has been relatively easy as what's new now is actually really old!

for ex: web apps are now starting to look like desktop apps from 1990-1993.

ways of interacting with them haven't changed substantially because
technologies like Flash, Java and AJAX run sandboxed by the browser and
early 90s OSs were basically single-tasking.

the eye-candy has changed. latency has improved but aside from 3D
interfaces, it's nothing too outrageous.

cell phones and PDAs are on average, about as powerful as 8bit and 16bit
computers.

many of the same limitations that challenged developers in 1993 exist today.
the main difference is that users are actually less technical today than
they were then because i got into computer when they were in 8% of US homes.
now they're in 80% or more.

>
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

12 Feb 2008 - 8:09pm
gretchen anderson
2005

I started in Web and Desktop and now do pretty much everything. From a
technology perspective, don't assume everything is different. The
toolkits used to do UI development for devices (QT, Java, C, etc.) vary,
but you needn't know the details of how. If you use devices, you have an
idea of what's possible.

What IS different are things like the one below. And they are the hard
part to learn. But here's some things I've learned matter over the
years:
- input mechanisms; touchscreen, small buttons, wheels, etc. How will
someone tell the computer what they want? Obvious, but non-trivial issue
for you as the designer.

- output: voice, small screens, etc. How do they get info/value? What's
the resolution? What "fits" on screen? Ditto on the non-trivial part.

- processing power: often non-PC products have small processors, so you
need to work with developers on what that constrains. Typically it
constraints UI animations, data crunching, number of "apps" running and
the like. With UMPC's becoming prevalent, this becomes less of an issue
(depending on your market), but always good to ask about up front.

- memory size: this is less true lately, but devices can have limited
on-board memory. This most often affects things like the number of
languages you can support, the number of page "templates" you have, and
the number/type of fonts. But that's really only when you have sub-2GB
devices. Work with your engineers to map features to SW footprint.
Typically devices that "capture data" (photos, messages, etc.) will have
adequate memory, since a photo is more expensive size-wise than
software. But that's a HUGE generalization.

- COGS/BOM: you need to be aware of target cost in a way that you don't
for pure SW. Cheap medical devices don't get a lot of memory or
processor speed because that costs. Work with your engineers closely to
map features to HW needed.

- Medical: this is a special area unto itself and hard to generalize
about. But I'll at least tell you that small/cheap devices that people
don't pay for/pay much for will be highly constrained. The "special
sauce" that makes them tick needn't be large in size, nor something that
you understand technically. In fact, most of the time, the
medical/science part is and should be a black box/algorithm-thingy that
you are providing access to/from. If you have a client asking you to
design their glucose measuring algorithm, you are dealing with someone
that doesn't have a product and you should walk away. Medical companies
should have the science. They may not/often don't know how to make
consumer electronics, which is why they hire you.

Hope it helps,
Gretchen

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Lukeisha Carr
Sent: Tuesday, February 12, 2008 6:53 AM
To: IxDA
Subject: [IxDA Discuss] IxD Work on Various Product Types

Hi All,

It seems that although IxDers do not necessarily have their hands deep
in technology in terms of the implementation of it, we still need to
know the capabilities of the technology behind what we are designing, so
as to not request impossible solutions. Working on different types of
technical products (other than web technology) is one of my goals for
the future.

Those of you who do not ONLY do IxD for websites/web applications, what
product types did you begin your IxD experience? Then, how did you
transition from one to another? For example, if you started out in the
web, how did you move on to doing IxD for medical devices, hand-held
non-web applications, desktop apps, etc.? For, I would assume that the
technology behind such products as medical devices is so very different
than what is used for the web. Do any of you shift product types
depending on the project, or have you just shifted product types as a
whole? What is the most difficult part of making such transitions?

Thanks in advance for your responses.

Lukeisha

________________________________________________________________________
____________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

12 Feb 2008 - 9:23pm
Miek Dunbar
2008

My background has mostly been in working on web artifacts, but I come from a communication design background originally, so I bring a strong value for identity design. For me, designing experiences is all about designing aesthetics holistically. That it's not just about the visual, but in the case of digital artifacts, the temporal and spatial as well. It's all about how people are going to relate to objects, activities and their lives.

In designing web apps, a lot of my work is in working with the front end, which can be frustrating since a lot of software dev projects regard this as a case of applying some pretty graphics over the top. I'm interested in how communication design approaches like those for identity design can help shape the way we think about designing front-ends. A marrying%u2014if you will%u2014between the outside and the inside.

Recently I've been working on designing blue-sky mockups for ubiquitous touchscreen devices, and the same principles apply. What you're looking for is a solid, honest user experience, and for me, that's driven by an approach to aesthetics. Even working on just wireframes, and staying away from refined look-and-feel mockups for the interface for this device, the same conceptual foundations apply.

The biggest value in working across different technical domains is in how you communicate and collaborate with others. Careful use and negotiation using prototypes (I use this term in the broadest sense to include sketches, wireframes, videos, implementations), becuas eit allows people from different technical backgrounds to negotiate.

Syndicate content Get the feed