As a side note, I’ve had some interesting responses to the questions that follow. Feel free to leave a comment and I can pass some stories your way.

What is the budget for UX for your company?

Can you describe the role of executive champion at your company?

How does management care about and treat the design process at your company?

How many different teams design at your company?

How do different teams share and transfer knowledge with each other to create a unified presence?

How does the critique process happen on your teams?

How do you inspire your teams and other designers to keep performing at their best?

How does the company encourage professional growth and development?

Do teams participate in peer reviews or other ways to improve each other?

How does the company and the team define success?

How is design and user experience structured at the company?

Can you describe the design process at your company?

Can you describe a design meeting and the culture and attitudes of those who practice design?

How you see design growing for the team and the company?

As I come up with more questions as I talk to other professionals, I will elaborate on this post.

Investing more effort

The sketching process is all about creating as many ideas as possible before settling on an idea that will not only work well for people, but will also let the dev team know what they will be building. This helps to prevent any surprises in terms of expected behavior. Without sketching and planning, I have seen the design process take longer and more effort invested, as people will defend the initial idea without having the ability to show the alternatives as to why the chosen idea was worthwhile. In addition, I have also seen headaches about expected behaviors, and teams going back and forth to find shortcuts that will help to get something out the door.

Fewer concepts created

Without sketching and planning, the design process becomes an especially limited help to those one is going to design for. The sketching process allows one to be able to create ideas and bring them to the design community, even in times of celerity, to let everyone know what one is thinking and how the community can help to make the ideas even better. Sharing these ideas helps to bring a space of opportunity for the community to decide how to address problems and to add new terms to the design language.

Biased towards technology already

Without going through this process, a designer is left to only address technical issues and the technology that needs to be implemented. This immediately takes a designer away from their domain – thinking about people first and the technology second. Sketching for me has helped me to see what hurdles need to be tackled and who I need to talk to in order to get these problems resolved. Sketching immediately helps to slow down the panics that happen during crunch time and think about people and technology.

More cost effective if you do it in pencil first

One of the more practical sides of sketching is that it will help to save money. Whether the sketch is for a label, or a new form factor, the sketches will allow the designer to have an educated proposal to the business about what is needed and how much effort will be needed to get the job done. It will also help to avoid costly redesigns and architecting, as the sketch will help to uncover these issues earlier, and at a point where either invention or a new concept is needed.

High fidelity really more shows a committed idea

If a designer immediately jumps to higher fidelity forms of a design, it shows there’s a lot of confidence and commitment to an idea. Having these is not bad in and of itself, but problems can arise if that idea isn’t brought forth to everyone in the design community. It can also show that one has created an idea and there’s little that can be done to change the idea. I start to worry when I don’t see sketching or a low fidelity form of concept generation, as it shows that there are forces that are causing fewer ideas and conversations from happening.

Creating shiny causes more focus on shiny

Using powerful tools like Illustrator can help show a fully formed idea to those who need some help seeing how a concept will manifest itself with code. Unfortunately, when this process happens, it immediately then changes the scope of feedback regarding the idea from about how the idea will help to solve a design problem at hand to feedback about colors, fonts, and other visuals. This feedback is helpful, but not at a point in the design process where an idea hasn’t been fully fleshed out.

Easy to lose sight of what you’re trying to convey

For me, sketching is a process that inherently allows people to see what problems are trying to be solved, and proposals about how technology can be used to make people’s lives easier. When there isn’t any time devoted to sketching, I have found that the effort then becomes spent on trying to make something that looks decent out the door. This unveils a different problem – that there isn’t enough time dedicated to creating a great idea to advance the company and the design efforts of the team doing the design work. At this point, to meet the schedule and other needs, the design process becomes more focused on grinding out details using design tools. Anyone can pick up these tools, but it truly takes a designer to understand how to invest their time on paper first before dedicating time to creating something “shiny”.

Understanding what is interactable

Visual design is a lot more than just shiny. The visual designer helps to create components and visuals that users will immediately see and take away with them after interacting with your design. A good visual design will help to speak to users about what is interactable. Making sure that a visual design is implemented well will help to alleviate some immediate usability problems.

Understanding how to use gestures

In this world of touch, we as designers need to provide a language and visual cues that certain elements on the screen can be touched and gestured with. It is up to both the interaction designer and the visual designer to find a means to speak to users about how they can use their hands to do things to an interface that may or may not necessarily jump out. They can help show the difference between something that can be zoomed and something that can be tapped.

Professional look and feel to the product

Another thing people take away from looking at a product is how it looks, and how it interacts. The visual designer knows the language of a company or of a client, and it is up to them to create that image that will not only put the company in the best light, but will also look like it came from a respectable company that creates impressive software that meets real needs. If something doesn’t look like it contains the right polish, then either the visual design wasn’t implemented well or that the visual designer wasn’t included in the process.

Understanding proper grid layouts

One aspect of the design process that I’ve learned working with seasoned visual designers is the concept of the grid. This concept is about the idea that a screen can be divided in equal units, and that people understand what is important by how much visual weight and space is given to each unit. This knowledge has helped me to give better designs to them, not only to show that I’m listening and value their input, but it shows that I’m sensitive to that their work is much more than just a glance.

Can help to get people engaged and into experience

Visual design can help people immediately engage with an experience. Whether there is something attractive, well done, appealing, or anything else that people find desirable, the visual designer is there to establish those feelings. Akin to proper gridding, a well executed visual design can get people to start interacting and talking about what they find value in a product. And it isn’t just about the shiny – the visual design can provide the right cues to get people through possible hurdles in a product, in addition to finding value in owning the product.

Designers of infographics

Information is around us everywhere. Nowadays, we are trying to find better and more clever means to show a vast amount of information in a condensed and visual form for people to take in, understand, and act upon. Visual design can help augment the power of this information into a clever infographic. Not only is this a more modern way of showing large amounts of information, but they also contain humor and contextual information that is enhanced by the created visuals of a visual designer. From these graphics, a visual designer can turn a dry table into a meaningful and full of life infographic that people can directly take and do something with.

Help drive consistency and ecology of apps in a system

In working with a large company, there are many software applications that are made. It is up to the visual designer to help drive a consistent look and feel to each product. It is also up to them to monitor the use of their graphics and components to ensure they are used in the same way as they are intended. If a visual designer is not involved, components and graphics can be used wildly for any purpose, creating a design ecology that shows users that anything can mean anything. And this state of things doesn’t help users to understand what they are doing, or understand why software works the way it does.

Below are reasons why I personally like to prototype and find it worthwhile in the design process:

Turn ideas into reality

Sometimes, an image or a sketch is not enough to understand intricate behaviors of how a design will work. When there are many details that depend on each other, this is where a prototype can help out. When an idea has never been implemented or thought of before, this is where a prototype can help out. Where there is some uncertainty of how the technology will play with the design, this is where a prototype can help out. Being able to transform a picture into a codified artifact is a vital learning step that can not only benefit the designer, but the dev teams as well.

Prove whether or not an idea is feasible

The statement pretty much sums up what the biggest benefit of creating a prototype – it proves the feasibility of the idea proposed. This artifact can then be used as a discussion point for user testing and improvements from a technical perspective to see if anything can be improved or if the approach needs to be altered.

Demonstrate respect to stakeholders

For me, the design process is a matter of showing respect to everyone who has their hands involved in trying to make something. The prototype is a means to show one’s stakeholders the responsiveness of the team; it also serves as a first means of understanding if an approach is suitable for those who have a great bearing upon the project. These people can get their hands on a prototype and use as a means of understanding those who will be using the final artifact and those who are financially backing the artifact. If I was putting money into a project, I would love to get my hands on prototypes in order to see that money was being spent well.

Enjoyable learning experience

I like to learn about technology and what are the different things it can do for me as a designer, and for me as a person who is trying to understand and solve problems. Sometimes it can be frustrating, and other times it can be real simple – but in all, this effort in creating a technical artifact is worthwhile. The process allows me to learn about technology, but what are the implications for the design, and for those who will be building the final artifact. That knowledge is vital when things don’t go as expected, or when a design needs to be rethought when the prototype shows that an approach isn’t worthwhile.

Another discussion point for the team

I also enjoy the prototyping process because it creates another discussion checkpoint. The prototype allows people from different backgrounds to come together and see a live proposal and then discuss issues from there. I’ve found that this helps to get the team to start thinking about what they are doing and how it will ultimately impact the project and the people who will be using the final artifact of the teams efforts. There have been many times where I’ve seen people that don’t communicate about important topics, and I’ve found that making the prototype is a great way to create that essential opportunity for communication. This artifact is worthwhile in India’s way, but also for the business community as well, as they can see where their money is going to be spent and how well they will see their returns.

Here’s some other valuable takeaways that I’ve found over the past couple of years that sketching has given me:

It is a low cost means of trying to propose solutions

Being able to draw out multiple solutions in the ideation process allows a designer to show to the business the different considerations and different experiences created from trying to solve the problem at hand. Each sketch doesn’t cost much time or money, and it also allows people involved in the process the ability to talk and sync up before code gets implemented and possibly changed multiple times.

Easily changeable and throw away

Since each sketch is purely pencil and paper, a designer can instantly change and adjust a design based on feedback and team critique. When things don’t go well, a designer can toss the paper away, rather than having to destroy months of coding effort. The intended nature of the sketch is fleeting – if it was anything more, designers wouldn’t be as likely to choose this means of problem solving as a primary means of moving forward.

Great for conversation starter

Another innate ability the sketch has is that it is your conversation starter, not a conversation ender or a final means to solving a problem. I’ve personally found that people are eager to start talking about design issues at this level of effort, and less as much when one has put the effort into creating a high-fidelity image or prototype. Much more valuable business has been completed when I’ve shown sketches than final images in the work I’ve done – that’s why I love this process so much more than using technology.

Ambiguity is power

Most sketches are quite ambiguous – a series of lines, boxes, and arrows, sometimes accompanied by text. This notation is great for the person who created it, as that notation allows for more time to be spent on problem solving than “prettiness”. When shown in front of a larger group, these lines could mean anything to the overall group, which usually prompts for questions. This a powerful moment in the design process, as it allows for the group to come together on an idea and iterate on what is suggested by the ideas shown.

Evaluate ideas before implementing

The sketch is also valuable for another reason – it opens up a means for those who have vast technical knowledge to comment on the feasibility of a solution. Possible technical hiccups – translations, truncating text, network delays, missing components – can be addressed by talking about how that will affect the sketched image shown on the whiteboard. This can help prevent the team from making an ad-hoc decision without having to get the chance to think about all the implications that could arise from a solution decided in seconds.

No technology needed

The sketching process, for me, is a means of equalizing the playing field in the world of design. All a person needs to do to contribute in the process is the ability to write. There isn’t a burden of having to have technical knowledge or the ability to have used certain types of programs before in order to contribute to the discussion at hand. This allows for a greater flow of ideas to come onto the floor for everyone to discuss before coming to a consensus. I’ve seen in my work that sketching also allows for those not involved in the project to be able to comment, critique, and strengthen the design rationale, as they can see it is an evolving idea that is open to interpretation. In addition, without having technology, more sketching can be done in the same time that it would take to do the equivalent level of problem solving using a computer – time is money, and as such, sketching is the way to save on both.

I think sketching is an essential tool to keep in the designer toolkit – if you want to know more, grab Buxton’s book and you’ll be able to see even more reasons why it is awesome.

Fun aspects

Good character design

I thoroughly enjoyed the characters, their costumes, demeanor, and struggles to save the world. The characters grew on me, and had witty banter with each other, which helped me to keep playing the game. They also made me smile, which is another great part of the total experience.

Amazing music, sound design, and environments

The music and sound design were executed technically well. This also included the environments. Even though this is a 6 year old game, these aspects helped me to stay glued into the world and Felt’s cause to help save the world. It also helped that the music and sounds weren’t annoying, especially through all of the grinding that occurs in most RPGs.

Easy to pick up

This game inherited many of the typical RPG elements, like leveling, magic, and armor, which helped me to focus on the story and the game itself, without having to try to balance learning a new type of RPG while trying to understand how my actions fit into the world. It also helped that the controls were very similar to other games I’ve played – I didn’t have to fumble through battles trying to understand how to be awesome.

Fun and easy to pick up battle system

Every game has its own battle system. In Atelier Iris 2, a player can be able to see the turn order of every person who is going to act, including elemental hazards or DOT effects. This certainly made my life easier in tougher battles, allowing me to plan ahead and heal when necessary or get ready to defend an onslaught. In addition, a player can position characters to maximize their use in each battle. Also, all characters gain experience from each fight, even if they didn’t take part. This helped me to not have to spend so much time grinding for hours just to survive a boss fight. Overall, battles were not a chore, and the game even told the player when the random fights in the overworld would be coming.

Overall whimsical charm

Easy controls, an evolving story that spans two different universes, a battle system that made the game fun to play, and an overall execution that took itself seriously when it needed to, culminated in a whimsical charm that still stays with me (I’m playing the first one now and I can remember all of these fun parts of the game), even a year later. This game may all be done in a traditional 2D and sprite style, but it is way better than many other 3D games I have played in a while.

Improvement points

Going back and forth between the two different worlds

One of the things I didn’t enjoy too much was that I had to go back and forth between the two different worlds to be able to use alchemy and create healing items. It took a little time to be able to switch between the two worlds, along I didn’t always remember what to do in order to make the switch happen – sometimes it was story driven, and other times I had to traverse menus in order to do that. If this were to be done again, I would hope that this part could be done without the delays.

Sometimes not knowing where to go next

For me, I usually say this for all RPGs – most of the time I can figure out where to o to get the next event to occur, but I had some trouble tying to find critical points in he story to find the main items. I also had the same observation when trying to grab the bonus items and quests. This game I had to break open the gamefaqs site to figure out a couple of the areas I wasn’t sure on how to complete or find.

No subtitles in cutscenes

I personally like to hear the original Japanese voices with my anime and games, but I also like to turn on the subtitles so I can understand what is being communicated. In his game, there were no subtitles in the cutscenes, so I had to keep the dubbed voices on the whole time. Not too much of a downer, but the experience would have been a little better if I could hear the original voices all the time (with subtitles of course).

Well-done aspects

Bulletstorm performed well as an action game. There was always something to shoot or evade. There were many different guns that a player can pick up and experiment with to eliminate enemies. A player can choose to specialize their weapons and skills, similar to an RPG game. A player is rewarded with more points to upgrade by using different weapons and environmental obstacles.

The introduction of the leash weapon, a futuristic grappling hook a player can throw at enemies to bring them closer to shoot or kick them, allowed for many laughs (enemies in this game had many different screams when they were thrown). The game also was very well rendered and the sound design in this game was very well down.

Not-as-well-done aspects

For me as a player, the characters and their progression throughout the game reminded me of a bad B-rated movie. The dialogue and predictable growth of the characters made me sit and wait for animated sequences to be over, not happy to see the characters talk (I prefer to learn and empathize with characters in games).

The levels and environments did not engage me as a player. Each level was very linear, and didn’t allow me to enjoy the futuristic space world and the riots that were supposedly happening. It wasn’t too bad that the levels were linear, it was just that each level did not gauge my interest while trying to understand the other aspects of the game. I would have preferring being able to examine everything and find appealing parts of this world than shrapnel everywhere. I have seen this way too many times before.

As a first person shooter game, there were many different weapons to choose from. Each one itself was fun, but a player could not be able to access them all without having to use hotkeys. A player could only cycle through two weapons at any one time, which is much different than any other game I’ve played, made each fight much more cumbersome than it should be. It was not fun getting into large encounters that needed a large explosive gun and not being able to press the standard rotation button to get to them. It also didn’t help that I could never remember what any of the hotkeys were – that would have made battles more engaging.

Improvement points

Overall, the controls were reminiscent of many other shooter games, which allowed me to pick up the game rather quickly. The part that made the overall experience cumbersome was the introduction of the leash and sliding, which I hit the wrong buttons most of the time.

The overall story, writing, and dialogue of the game was not very well done. The idea of military guys and girls just running around shooting and cursing everything might have been done well as a script, but the execution of said story made me feel bored and generally annoyed while playing the game. I would be more inclined to enjoy the game more if I could relate more to the soldiers and the shocking plot that was supposedly set up against them.

The biggest improvement point to this game would be the action itself. It didn’t take too much more than just holding down the shoot button, and then leash and kick enemies while reloading. If you can master this one style of play, you pretty much don’t need to learn or do anything else.

Ultimately, the game is a decent action and shooter game, but I didn’t find it to be worth the money I used to buy the game. I recommend picking it up used or through GameFly.

The following is how I’ve learned to adapt my process, with the help of some seasoned designers to give guidance. I’ve found the below tips to lead to a better environment with the dev teams and the product owner, which makes life better for everyone.

Attending planning meetings

This is the one meeting that is crucial for the designer to attend, as this is where a team receives their requirements for the iteration. This is also the time for the designer to ask questions and prepare to tease out unwritten requirements. This will help to make for better documentation and a better estimate from the dev team on how long it will take to complete a particular requirement. This meeting will also help the designer see what needs to be supported from the previous iteration, the current iteration, and how to get ready for the next iteration. This meeting is the best time to ensure that design is at least one iteration ahead of the dev team, which helps to ensure the smallest amount of rework for the team.

User stories

These are the smallest units of requirements for each piece of work a dev team has to complete in an iteration. When written well, they will paint a picture of what is expected of a user, and how this functionality will integrate into the entire product. Sometimes there will even be more details about what criteria the product owner wants and cares about in this unit of work. It is then up to the designer to make sure he/she understands all the details and can integrate them into the design and documentation for the dev team. When these stories aren’t written with much detail, it’s up to the designer to ask many, many questions to figure out what effort is really needed and help work with the product owner to capture these details, and then work with the dev team to execute on those details.

Tasking

This is where the designer can let the dev team know what he/she will be working on for the iteration. It is also important to write down how long one expects to take, as it will help show how long it will take to deliver a quality product to the product owner.

Agile specing

Specing, documenting, providing design support – whatever flavor of terminology one wants to use in providing a translation from design to code, a designer will have to change their process to get stories delivered on time and with quality. What I’ve found to be effective is to work with the product owner to give the design team documentation stories to give lead time for the product. This lead time gives a designer the ability to start creating the proper design language needed for the design to flourish, as well as finding technical details that will need to be prototyped before given to the dev team. If a designer cannot get the lead time to do a proper level of documentation, I’ve found that the best way is to keep documentation to wireframes and a small paragraph or two. This would be in addition to working side by side with the developer. Above all, do what makes sense for the dev team and where one works, and things should go well – keep in mind, though, that this is a process change that will take time to iron out issues and find something that makes everybody happy.

Review tasks

A designer should put in review tasks to make sure that the product is functioning as designed. This can be as something as simple as having the dev team walk through the end o the iteration’s build, or something as formal as taking an hour or two and looking at every detail for yourself. The important thing is to not get surprised when the dev team shows something or doesn’t show something to the designer – take that as an opportunity to forge a relationship with the team, as you’ll be helping to make their lives easier. They’ll thank you for minimizing their rework.

Closing stories and reporting defects

There will come times at the end of the iteration where the design and the build don’t match up. This is where a designer can log a change request or a defect (whatever flavor of terminology one’s team works with) to let the product owner and the business know there’s an issue. At that point, it’s up to the product owner to determine how that issue will impact their product – whether it gets fixed or doesn’t is their call, and not the designer’s. If everything matches up well, then the designer can mark everything as complete and the user story can be closed.

How to fit in user research

This is the hardest part to be able to work within the agile environment. It would be nice to not have anything starts until a designer can get a grasp of the problems at hand and the design situation, but the real world, and agile, very rarely will allow for that. Some of the ways that I’ve found on how to incorporate user research is to: put in stories into the product backlog for user research and testing, put research into the stories for the current iteration, put research into the tasks that one is working on, find time to talk with other design teams to see if they have info that can help, or set up a plan to get little pieces of information as the product is being built. The same goes for user testing – ideally this can be done at the end of each iteration, but if it can be done through the use of user stories or tasks, that should suffice. The important thing is that verification and gaining a solid foundation by talking and working with the people one is designing for happens – the time and effort makes for better design, and makes for happier dev teams.

I’m still learning every day on how to work UX and agile together, but please leave a comment if you have any other tips that can help our community become better and use agile as an opportunity to create human-centered designs.

Context is important

As with any design, the context is very important. Subtle design points, like who will be using the app, the location of the app, whether or not the use case is shared or for a single person, and what the goals are for people are all crucial details that are shared between these two different environments. Successful designs in both environments leverage these aspects of the real world to the most.

Design with technical constraints in mind

Printers and mobile devices are not the powerhouses of computing as the standard desktop computer is. As such, waiting time, processing time, and advanced logic and behaviors are all vital points of communication to end users. Always thinking that the best technical environment will be available is a misassumption, and design should be able to be in stride with the development community to find these points of communication and account for them.

Each screen has a prime focus

With printers and mobile devices having small touchscreen, this places more onus on the designer to convey a stronger meaning to each screen, along with the overall workflow. The more that we try to place on the screen, the more opportunities that we open for people to get lost in a sea of options and not complete their objectives.

Incorporate native paradigms as much as possible

Apps for printers and mobile devices exist in an ecology with the native device they are placed on, along with other apps that have been created now, and in the future. As such, people learn about how to interact with the device from the other apps, and the native interactions of the device. To help increase the overall usability of the entire ecology of the device, designers should learn more about the native device, and then transfer that knowledge to their apps. This will also help people to become more productive, as there will be less confusion in how an interaction works from one app to the next. In addition, incorporating as much of the visual design and sensory cues from the native device can also empower the apps to communicate the same information as in the native device, tightening the experience between app and device, and also blurring the distinction between the different software and teams that built them.

Normal path is very important

One observation that I want to share from my experience is learning how to restrict the core of the app to one main purpose. Users should be able to reach all of the functionality from the core of the app, but the normal path should be extremely solid and well designed. Without a normal path in any of these types of path, the user won’t be able to grasp an idea about what is being asked of them, because their world is left open and without direction. A solid normal path will be able to naturally show everything the user needs to do, and provide optional choices as they may want them.

First time experience can help

With printer apps and mobile apps, generally people are in a mindset that is in the need for efficiency and quickness. As such, a well-designed first time experience can help lead people into the app, and showing the user the things that the design teams take for granted. An empowering first time experience will also help the user set up any settings or configurations that will allow the user to be more productive later on. Without helping to lead the user the first time an app is launched, the likelihood of stumbling around in an app and not enjoying the app is increased, leading to users voicing frustration with the design, and in the worst case, uninstalling the app and telling their friends and coworkers.

Fun aspects

• When the player is in shooting mode, there’s a lot of action and shooting to keep one happy
• There are many different guns
• Players can level up guns
• The game is very well rendered and animated
• The sound design was also well done and executed

Aspects that need work

• The characters were rather flat; I could really care less about their situation
• The levels were mostly linear; sometimes I had to look up on gamefaqs where to go from some poor cueing
• The story didn’t pull me in and make me want to continue playing – madmen and stereotypes of Russia can only go so far
• I was still fumbling with the controls, even many hours into the game (especially controlling the TMD)
• The game was short, and even when complete, didn’t leave me wanting any more

Aspects that definitely break the experience

• The pacing has sharp peaks and valleys
• The designers place random box puzzles (that really don’t add anything but sheer annoyance) in an attempt to make things interesting
• There is very little variety, other than shooting, running, and listening
• A player really only needs two of the many guns offered to beat the game
• A player can only carry two guns, rather than having the ability to let the player carry multiple and let the situation help factor what guns should be used
• The graphics used to represent the clip are a little small and not unique to each gun

Want to add some of your thoughts to the discussion? Feel free to add a comment and let’s get the conversation going.