Posts Tagged ‘ux’

16
Apr
2013

How can we nurture a great designer at tech start ups?

by Sari Griffiths

How can we attract talented graduate designers? Can we be a serious contender in the design industry?

The traditional (or conventional) wisdom says the best place for graduates to learn their trades is at successful creative agencies or consultancies. But is it possible for tech start-ups to nurture design talent too?

I took a (very subjective and personal) look at pros and cons of options from a graduate’s point of view to see if joining the start-ups can be a viable option for them.

Pros and cons of established medium to large design agency or consultancy

Pros:

  • There are many peers you can learn from – a team or teams of designers who compete and inspire each other (in theory, at least)

  • There is a variety of work going on, giving you wider insight.

  • Higher possibility of doing projects for large, well-known brands

  • Longer term projects allow you deeper understanding of brands

  • Design is at the heart of the company

  • Large alumni network can help you in the future. Or add some kudos in your CV.

Cons:

  • Smaller part / say / influence in a project (you will probably have to be very assertive to be noticed) to begin with

  • Pay is often linked to a job title – okay for the first few years but it will become increasingly painful as you reach senior positions

  • More office politics (just because there are more people…)

  • Tendency to design for the peers and awards

  • Less disruptive in general

Other characteristics:

  • Many processes and templates to follow

  • The projects tend to be longer

Pros and cons of tech start-ups for designers

Pros:

  • Greater responsibility, influence and contribution as there are generally less people

  • Early exposure to clients

  • Get to see the end results quickly

  • Multi disciplinary team environment for insights and inspiration

  • Emphasis on great user experience

  • Likes to be disruptive

Cons:

  • As it tends to be small you have less peers to learn from. The worst case scenario is you could just get thrown into the deep end without any support.

  • The projects tend to be for smaller clients. (Having said that, more and more large enterprise are seeking out start-ups for innovative solution as you can see from our client list)

  • The projects tend to be shorter with less time for crafting design

  • Less emphasis on design

Other characteristics:

  • It’s usually small

  • The projects tend to be shorter 

So, what can tech start-ups do?

1. Invest on support

You will need good senior designers who are willing to help others to begin with. If you do, then the small setting is actually a positive thing as graduates can get more personal, hands on attention.

Make sure training is provided and appropriate tools are available. There might not be many peers inside the company, but there are millions out there in some form of on- and offline communities. Join up.

2. Promote user experience

While visual design might not be at the heart of the company, the user experience should definitely be, alongside technology.

Visual design (including branding) is basically the physical manifestation of user experience. It can’t be ignored. Even if the technology works well, if it fails to communicate and be usable, no one will use it or identify with it. It’s not just about making things look pretty. It’s vital that you get the design right.

You also need to understand that design is something constantly evolving and improving. Let’s try not to call that jpeg “FINAL”…!*

*Dear graduate readers: You will soon encounter a filename that ends with “FINAL FINAL FINAL” or “NEW NEW NEW” when you start working. Someone has obviously been very optimistic.

3. Be disruptive and cutting edge (and fun)

This is the biggest advantage start-ups have over bigger, more established firms. You are more agile and flexible, and you can be more disruptive.

Any designers can make difference, create something new from day one. Surely that is very motivating.

Fun and creative and nurturing

4. Inspire

Working within a multidisciplinary team can inspire designers in a different way from a team of designers. It is not about designs for designs sake. It’s the art of looking sideways in a sense.

In the bigger firms, especially those that operate with a waterfall methodology, sometimes you don’t even get a single opportunity to talk to a developer during a project.

Start-ups should create an environment that encourages all the team members to communicate – if you are running in agile that incorporates UX and design properly (If you’re interested in how to do this, here is my previous blog: Agile Survival Guide for Designers), then that should happen naturally.

Are you a graduate?

There is a lot happening with design in tech start-ups right now. It feels a lot like 1960s was for graphic design. There are opportunities to innovate and experiment. While I agree that there are loads you can learn from being surrounded by designers, surrounded by developers and other disciplines enables you to achieve something equally exciting, and potentially new and groundbreaking.

Maybe you need a bit of entrepreneurial spirit and drive to improve. And a love of creating something you can be proud of. It’s more about what you create and do, rather than what other people think you do.

I am not saying all the tech start-ups are great place for a budding designer. But as long as they hit the four points I listed above, I think they can be a great place to be. Maybe more than what the traditional wisdom says. If you are a graduate / budding designer and interested in working with us, please give us a shout at hello@red-badger.com.

(If you’re interested in seeing the Lego plant pot being made, here is the stop motion animation I made while building it. And it’s inspired by Being Geek Chic blog.)

14
Feb
2013

Agile Survival Guide for Designers

by Sari Griffiths

Are you a designer about to work in agile teams? Or are you a scrum master and don’t know how to handle your ever so grumpy creatives?

Red Badger works with agile methodology and I really like the way we work here. Surprised to hear a designer liking an agile team? I would like to share some tips that designers and scrum masters can follow to make designer’s life in agile somewhat enjoyable.

Things are getting better

My favourite horror story was along the line of “I turned up on a new project and they asked me to design up a login button. I don’t even know what site we are making!!”. Fortunately I‘ve never had this before, but I can imagine that could easily happen in more tech driven teams.

Designers are used to working in waterfall and it suits them very well. The fundamental premise of agile methodology doesn’t sit very well with the design ideal. The difference between agile’s ‘Do just enough to make it work’ and designers’ ‘Keep pushing until it’s brilliant’ mentality are quite hard to compensate. On top of that, visual design is such a subjective art. You can’t say ‘It works’ like you can with coding. So how do you know when visual design is ‘just enough’? No wonder designers find the agile process painful.

But. Things are getting better.

These days, people are more aware of importance of good user experience including visual design – it is becoming an integral part of Minimum Viable Product. (Interesting read about it here on Startup Blender: Minimum Viable Product vs. Minimum Delightful Product). Advances in CSS and HTML allows us to be more ambitious in terms of visual expressions = there are greater expectation on presentation standards. There is a willingness to accommodate user experience process into an agile one. Let’s take advantage of that.

Minimum Delightful © Red Badger

Tip 1: Phase 1 for user experience and backlog creation

This is optional, but I highly recommend having a separate phase for user experience and developing Look & Feel. Especially when whatever you’re making has no brand to work from and/or the brief is loose.

It’s not Sprint 0 – This is a phase BEFORE Sprint 0. At the beginning of Sprint 0, the team should have a good idea of what they are making, and Phase 1 is there to make this ‘idea’ good.

It’s a time to look at the concept in wider context. It’s a time to create Look & Feel, stress test the ideas to create focused backlog, and run it by users.

And it’s not a waterfall in disguise. You’re not solving all the problems, but it’s your chance to have a broader approach developed and agreed. Sprint 0 is there to refine what to be developed during Sprint 1. And you have all the rest of sprints to get things right*.

*Scrum masters and project managers – you may need to think about keeping designers involved a little longer…

Tip 2: Be part of Sprint 0

It’s probably very obvious but it’s crucial for Design and UX to be a part of Sprint 0 to make sure some core visuals are designed up for the Sprint 1. Designers and UX need to stay ahead of development to minimise UI changes later on.

Tip 3: Design not ready? Use Bootstrap.

UI devs don’t need to have the ‘button designed’ on day one these days. There is Bootstrap (or something equivalent)! It looks decent and a quick way to start seeing and testing functionality without the final design applied. So don’t bother with half-baked-hastily-put-together designs. Ask them to use Bootstrap in the meantime.

It’s still important to have Look & Feel developed in Phase 1 though as this will inform the layout and construction of the page, so when you finally get around to do the design, there is a minimum pain for UI devs.

Tip 4: Things are agile for everyone

Sometimes there is a bit of unfair expectation by other team members that when you hand over any design, it should be FINAL and should not change. I agree that’s probably the case if you’re working in waterfall as you have chance to design up all the pages in details, look for inconsistency etc. But if you’re working in agile, designers should be allowed to improve things in later sprints as much as devs are.

Mind you, I’m not saying you can put off ‘getting it right’. You should try that all the time anyway. But if the design needs improving, it needs improving. Insist on it.

Tip 5: Talk to scrum master and project manager

Before any project starts, it’s good to talk to the scrum master and/or project manager over the project plan. Do raise an alarm if they are planning to make you start at the same time as UI devs. You need to explain and convince them why you need some time upfront.

Here is one example. Imagine that you’re putting new tiles up in your bathroom. What would you do first? Measure the walls? Decide on colour schemes? Choose the tiles? But I bet you won’t just pick one tile of certain design and slap it in the middle of the wall before thinking about all these things.

Designers need to think about wider context. How much wider depends on the project, but you will definitely need some time upfront to make sure that you are not creating Frankenstein with plasters all over. Remember putting plasters on Frankenstein takes time – a lot more than making something good in the first place.

Tip 6: Talk to UX

Always, always start sketching with UX. Don’t wait till you get a wireframe because you won’t like it anyway and they won’t like you for changing it so much. It’s much quicker to sit with UX and sketch it out together, so you’re all on the same page. Then you can split from the UX to do what you’re better at based on agreed approach.

Tip 7: Talk to UI devs

It’s good to talk to UI devs about design issues from an early stage too. After all they have to code it. I always ask opinions and suggestions from UI devs (and everyone else for that matter). They know an awful lot more about techs than you do and some – especially the ones I work with here – have a really good eye for design & UX.

By involving them in the design early on, it becomes much easier to improve things over sprints as the benefits and aims of doing so are clear to them.

Tip 8: Talk to everyone

I know it’s obvious, but it’s worth noting. The well working agile team talk to each other. We’re all trying to solve the same problem. You’re not tossing your work over the fence. Be pragmatic, and don’t be too precious – good designs are good whoever designed it.

And remember that you’re the champion of good visual design. Make a noise and be heard.

And well done, you made it work

There is definitely a stronger sense of contributions to the final product in agile team. Probably because you remain part of the team until very nearly the end of development.

Also it’s a rewarding experience seeing your design turned into reality right in front of you. It’s your chance to refine your design as it’s being built. So try it. You never know, you may even like it.

 

15
Jun
2012

Return of Swiss Typography – Metro

by Sari Griffiths

It’s been a month already (where has my month gone?) since  I attended a workshop for Windows Phone Design Clinic on Thursday 10 May at Soho, London, organised by Microsoft and Nokia.

Can’t believe it’s Microsoft

I was 10 mins late coming in and as I walked in, I was greeted by a presentation showing classic Swiss Typography. This the kind of stuff I learned about at art school and the kind of stuff I’ve got a quite a few books about at home. Examples include beautiful urban transport signs from around the world and the famous grid system.

Here are some posters by Josef Müller-Brockmann – typical Swiss Typography.

The audience was about half developers and half designers, so I’m not sure how the developer folks took to this presentation, but my honest first opinion was: this is a lovely design – can’t believe it’s Microsoft. (Sorry!)

I have seen their Metro design templates prior to the workshop, so I knew it was pretty ambitious. But hearing from Dave Crawford first-hand how it came about and what it was all about, it really hit home. This was really happening and it was very well thought through.

When iPhone changed the smart phone market, it was revolutionary. But its iOS design relied heavily on real life metaphors of buttoned machines. I suppose this was to  provide some clues to how a crazy device with no buttons works.

That’s a while ago. These days, users are happily swiping and pinching their devices away – they know how these button-less things work now. It is the perfect time to rethink interfaces for touch devices.

It was surprising that it came from Microsoft.

Let’s face it, they were not really known for good graphic design (Some old fun: Microsoft repackage iPod video). Their brand was more of ‘you can do anything as long as you know what you’re doing’ and it’s about performance, not the look’.  Whereas Apple was more about ‘user experience’ and ‘our way is the right way’.

Lately, I think there is a shift in this positioning. Apple is still criticised for not making iOS open enough etc, but as long as their user experience is concerned, it’s anything goes. They are not doing much about their slipping standards of user experience and slick graphics, that they were once famous for.

Android provides an alternative to iOS, but it is an alternative. The interaction models aren’t very different. It basically has a few more physical buttons than the iPhone. Having said that, it is a jolly good alternative with lots more freedom for developers.

And now with Metro, Microsoft is providing a new approach, rethinking the interaction model for touch screen devices.

Two points stand out for me.

1. Panorama interaction: the edge of screen isn’t the edge of screen.

The screen they call ‘panorama’ is a wide page with a few columns. You have to swipe to see it all, but it’s pretty intuitive to use. It really brings the horizontal direction into play, not just vertical.

2. Back means back.

Metro doesn’t encourage apps to have a ‘home’ button. Sometimes it’s unavoidable, but if you can get away with it, it’s better for it not to be there. Having this principle really challenges you to think about interaction and user experience, and not to default on the standard website model that you see a lot on iOS.

Respect your device

In one of Dave’s slides, he told us to respect a few rules. “Respect your device” was the most memorable one.

There were a few comments from the audience about some clients asking for the apps across mobile devices to be identical because they want consistency. Between iOS and Android, their similarity allows these apps to seem pretty identical, but not in Metro.

I thought the question for this situation will be “what ‘consistency’ means in this context?” It is unlikely that someone is holding two devices side by side, using the apps and saying “oh, they’re not the same”. It’s more likely the user feels they are the same. If your back button didn’t go back as you expected it to do, you feel it’s wrong, even if that’s what happens with other devices. Consistency can only come from how well the app operates on the particular device you’re using.

Having worked on an app for iOS and Android, for both to have the same feel, I know that they can’t be identical either. There are subtle differences due to the existence of the back and menu buttons, forcing architecture to be different. However their visual styles could be very similar, giving the illusion that they are identical.

Okay, I admit that recreating an iOS app for Metro requires a much harder rethink than doing the same for Android. Several speakers at the workshop recommended going back to the drawing board rather than trying to translate. And actually, your app could work much better in Metro than in iOS as a result of it by digging deep into the concept of the app and the brand.

So would I use it?

Yes is the simple answer.

I am a long-term iPhone user but I really wanted to try this out. It’s great having someone challenging the way we interact with devices. It’s a beautiful system to use and look at. I’ve asked for my company phone to be a Windows Phone 7.

I am also looking forward to doing some work on Metro. Although it’s really well thought through, it is not an easy task to design for one. You still need a good design to make it work. But it’s really exciting to see where it’s heading UX-wise. Now, what I’m not so sure about, is what it’s like for devs…?

For further reading about designing for Metro: http://ux.artu.tv/

 

21
Feb
2012

UX for every one – UX developers are here.

by Sari Griffiths

I always had a problem with the term ‘User Experience (UX)’ being used to describe a particular discipline – not that I don’t agree with the fact that’s what they are predominantly concerned with. I just don’t like that it seems to imply that other disciplines are NOT about user experience.

I am a graphic designer, and it is definitely (should be) about user experience. But that’s probably very obvious – so I didn’t complain.

And there are developers.

I recently read an excellent blog about the UX developer by Leisa. She makes a point that some front end developers are so in tune with the idea of user experience, they can be called UX developers for their contributions. 

I cannot agree more. But I also agree with one of the comments the article has – “UX dev is just a good front end dev”. Because of front end development’s closeness to users, in the same way as the visual design and site architecture, it has to take user experience into consideration to do a great job.

What about the back end devs?

You might think, well, it’s not important that they understand UX – after all they are not creating direct touch points to user journeys. 

I am lucky enough to have worked with some back end devs (i.e. Stuart and David) with strong UX understanding, and oh my, it REALLY makes a difference.

There would be no ‘you can’t do that because it’s not built / structured / stored in the right way’, because they understand the importance and WHY you’re asking certain things to happen. They would be coming up with alternatives to achieve your goal, or find the way around it. They could suggest you a new way of doing things which you thought technically not possible (or plainly not thought of), because they understand the user journey and user experience principle. It’s the same in any disciplines – you can solve problems so much better / quicker when you know WHY something needs to happen rather than just WHAT needs to happen.

So my conclusion is – UX devs definitely exist and it includes ALL devs. If in doubt, try working with one. It’s so good, you don’t want to work without them ever again. :-)